Earlier quoted context omitted.
LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of un…
> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large cod…
Because as the OP of this thread and LLM users are rediscovering, that understanding is the most critical part of software development
>I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.
I suspect a lot of people haven't worked on a system with engineers who've been there for 20 years working on it. There's simply no substitute for that kind of deep institutional knowledge, and it'll take you 5-10 years to be as productive as them simply because of that level of extreme knowledge about a codebase. It isn't as sexy as swapping jobs every 2 years though, so you have to go outside of the big tech bubble