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 3 days ago | parent [-]

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 3 days ago | parent [-]

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 3 days ago \| parent [-]
		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.