| > Often I find myself cursing at the LLM for not understanding what I mean... Me too. But in all these cases, sooner or later, I realized I made a mistake not giving enough context and not building up the discussion carefully enough. And I was just rushing to the solution. In the agile world, one could say I gave the LLM not a well-defined story, but a one-liner. Who is to blame here? I still remember training a junior hire who started off with: “Sorry, I spent five days on this ticket. I thought it would only take two. Also, who’s going to do the QA?” After 6 months or so, the same person was saying: “I finished the project in three weeks. I estimated four. QA is done. Ready to go live.” At that point, he was confident enough to own his work end-to-end, even shipping to production without someone else reviewing it. Interestingly, this colleague left two years ago, and I had to take over his codebase. It’s still running fine today, and I’ve spent maybe a single day maintaining it in the last two years. Recently, I was talking with my manager about this. We agreed that building confidence and self-checking in a junior dev is very similar to how you need to work with LLMs. Personally, whenever I generate code with an LLM, I check every line before committing. I still don’t trust it as much as the people I trained. |
That is not really relevant, is it? The LLM is not a human.
The question is whether it is still af efficient to use LLMs after spending huge amounts of time giving the context - or if it is just as efficient to write the code yourself.
> I still remember training a junior hire who started off with
Working with LLMs is not training junior developers - treating it as such is yet another resource sink.