I had hired 3 junior/mid lvl devs and paid them to do nothing but study to improve their skills, it was my investment in their future, I had a big project on the horizon that I needed help with. After 6 months I let them go, the improvement was far too slow. Books that should have taken a week to get through were taking 6 weeks. Since then LLM have completely surpassed them. I think it’s reasonable to think that some day, maybe soon, LLMs will surpass me. Like everyone else, I have to the best I can while I can.
But this is an issue of worker you're hiring. I've worked with senior engineers who a) did nothing (as - really not write any thing within the sprint, nor do any other work) b) worked on things they wanted to work on c) did ONLY things that they were assigned in the sprint (= if there were 10 tickets in the sprint and they were assigned 1 of these tickets then they would finish that ticket and not pick up anything else, staying quiet) d) worked only on tickets that have requirements explicitly stated step by step (open file a, change line 89 to be `checkBar` instead of `checkFoo`... - having to write this would take longer than doing the changes yourself as I was really writing in Jira ticket what I wanted the engineer to code, otherwise they would come back with "not enough spec, can't proceed"). All of these cases - senior people!
Sure - LLMs will do what they're told (to a specific value of "do" and "what they're told")
Sure there is a wide spectrum of skills, having worked in FANG and top tier research I have a pretty good idea of the capability at the top of the spectrum. I know I wasn't hiring at that level. I was paying 2x the local market rate (non-US) and pulling from the functional programming talent pool. These were not the top 1% but I think they were easily top 10% and probably in the top 5%.
I use LLMs to build isolated components and I do the work needed to specialize them for my tasks and integrate them together. The LLMs take fewer instructions to do this and handle ambiguity far better. Additionally because of the immediate feedback look on the specs I can try first with a minimally defined spec and interactively refine as needed. It takes me far less work to write specs for LLMs than it does for other devs.
You're (unwittingly?) making an argument for using an LLM: you know what you're going to get. It does not take six months to evaluate one; six minutes suffice.
The argument I'm trying to make is that hiring a real person or using LLMs has upsides and downsides. People have their own agendas, can leave, can affect your business in many ways, unrelated to code etc, but also can learn, can be creative and address problems that you've not even surfaced. LLM will not and will not be capable of that.
With LLMs you know what you're going to get to a certain value. Will it not listen to you? No. Will it not follow your instructions? Maybe. Will it produce unmaintainable garbage? Most certainly. Does that matter for nondevs? Sometimes
And even if their progress had been faster, now they are a capable developer who can command higher compensation that statistically your company won’t give them and they are going to jump ship anyway.
One didn't even wait, they immediately tried to sub-contract the work out to a third party and make a transition from a consultant to a consultancy company. I had to be clear that they are hired as named person and I very much do care about who does the work.While not FANG comp it was ~2x the market rates, statistically I think they'd have a hard time matching that somewhere else. I think in part because I was offering these rates they got rather excited about the perceived opportunity in being a consultancy company, i.e. the appetite grows with the eating. I'm not sure if it's something that could be solved with more money, I guess in theory with FANG money but it's not like those companies are without their dysfunctions. With LLMs I can solve the same problem with far less money.
Claude gets better as Claude's managers explain concepts to it. It doesn't learn the way a human does. AI is not human. The benefit is that when Claude learns something, it doesn't need to run a MOOC to teach the same things to millions of individuals. Every copy of Claude instantly knows.
Maybe see it less as a junior and replacement for humans. See it more as a tool for you! A tool so you can do stuff you used to delegate/dump to a junior, do now yourself.
Actually it does, if you put those concepts in documentation in your repository…
Those concepts will be in your repository long after that junior dev jumps ship because your company refused to pay him at market rates as he improved so he had to jump ship to make more money - “salary compression” is real and often out of your manager’s control.
You need to hit that thumbs down with the explanation so the model is trained with the penalty applied. Otherwise your explanations are not in the training corpus
Handholding the human pays off in the long run more than hand holding the llm, which requires more hand holding anyway.
Claude doesn't get better as I explain concepts to it the same way a jr engineer does.