For now, LLMs are still bad at it, but they're already at "competitive with humans" tier of bad. I expect them to get better.
For now, LLMs are still bad at it, but they're already at "competitive with humans" tier of bad. I expect them to get better.
They already are better than most humans at writing code for sure but even the best SOTA model is worse than your average intern at memorization.
Someone with "memory" should be able to do the same faster, but having that memory should not be a requirement.
Whether that "someone" is a freshly onboarded mid-level SWE or a mid-tier coding LLM is largely irrelevant.
And that difference is in the memory. The LLM can work during 5 years on the codebase and still will be as good as a newcomer.
You can somewhat partially compensate for this bad memory by writing tons of guardrails and tons of extra LLM focused documentation, but it doesn't do everything.
Essentially, it's like talking to somebody who has a permanent memory damage.
An LLM can just re-ingest the entire codebase every time it wants to make a change - open it up, find the relevant parts, derive how a well structured, maintainable change should look like from them, then make that change. The way a compiler can just re-ingest the entire codebase every time it wants to make a binary.
The intermediates are a cache - a resource optimization, not an outcome optimization. Is it wasteful not to have a cache? Maybe. Can you get away with not having it? Yes.
And, the more maintainable a codebase is, the easier it is for an LLM to "re-ingest" it from scratch. Or for a human to get onboarded. There's some overlap there.