[realusername]

I don't think they ever will on the "maintainable" part until their absolutely atrocious memory gets improved at least tenfold. (and no, the tricks we deployed until now aren't enough)

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.

[ACCount37]

That's the entire point of the "maintainable" part: someone with no "memory" of what was written where and why should be able to walk into the codebase, understand how it works, and be able to make a sensible change to it without setting things on fire.

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.

[realusername]

Depends what you mean by your comment then, if you want to say that you can direct LLMs to write maintainable code yes sure you can through very strict guardrails, if they can do it themselves, no they can't and need help because of their bad memory.

[ACCount37]

Why would "memory" be relevant to that? I honestly don't see it be much more relevant to "write maintainable code" than it is to "play chess".

[realusername]

Have you even onboarded somebody at work? There's a big difference between the newcomer and the dev who's been there for 5 years, even at the same seniority level on paper.

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.

[ACCount37]

That's how it works for humans. And, sure, LLMs are severely human-adjacent. But they aren't human.

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.