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.
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.
Sure - LLMs will do what they're told (to a specific value of "do" and "what they're told")
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.
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
The bit that's missing from this story is the "why" the improvement was far too slow. Was it primarily a failure to hire the right people, a failure to teach them what you wanted them to learn, a failure to understand what you needed to teach, or a deliberate lie on the part of all three of them to steal from you?
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.