Comment by jameshart
11 hours ago
This is true, but we also don’t know the long term architectural tradeoffs that are right for an LLM-maintained codebase.
For human-maintained code you manage duplication and locality of changes in the codebase because you want concepts to fit inside a human’s working memory. Keeping method bodies short is so they fit in one code window on the screen.
LLMs’ working memory works in very different ways; they see codebases not as windows of code but as blips of grep results. It might be that it’s easier for an LLM to just ensure five pieces of code are all modified in sync with one another than to safely implement a DRY refactoring.
It also differes between human-maintained codebases, too.
For some greenfield project I'm developing, 99% of the time, fixing architecture and going as far upstream as possible is the right choice.
For the codebase I'm working on professionally, doing the hacky thing is the right choice most of the time, because there's enough people changing it frequently enough, with little coordination, that architecture is fluid, and hacks only survive if they work well enough (otherwise someone will come around and fix it).
That was true pre-LLM, too, and is simply a function of scale. And ironically, it's not laziness but pragmatism - at this scale, you just can't assume code you worked on last month will look today like anything you remember. Code review process + extensive linting and testing and AI-assisted analysis filters out most of the junior-style mistakes and flag ugly hacks, so you get a moment to pause and double-check, but if it's good enough, you merge it in and go do another useful thing.
This is how you end up with a big ball of mud [1]. If the argument is that LLMs are just as capable as humans at building big balls of mud, then I'm not sure it's much of an endorsement of their use.
[1] https://www.laputan.org/mud/
I've thought about that and I agree. One thing I'm wondering though is, are we really ready to go all-in on making a codebase that is effectively unmaintainable by humans?
> It might be that it’s easier for an LLM to just ensure five pieces of code are all modified in sync with one another than to safely implement a DRY refactoring.
One thing they are definitely not doing is making decisions based on how easily and quickly they will be able to maintain those decisions in the future, or considering that duplicating code rather than creating abstractions will be easier for them to keep track of because of their "very different working memories."
They're just doing a bad job. It's not some sophisticated work avoidance/efficiency in defiance of feeble human abilities to maintain what they have written. 1) LLMs are not lazy, and 2) if writing maintainable code is part of the remit, they're consistently failing. You can't convince me simultaneously that LLMs can handle everything, and also that they can't figure out how to factor their code in a way that would be a pleasure to review.
It simply doesn't make sense. If they're so good, they can make it easy to read and well-factored. If they can't make it easy to read and well-factored, they ain't so good. Saying that they're so good that the code has to be this bad is a very weird rationalization. One that apparently involves speculating about their internal states in a strange way that sounds a lot like the projection of fantasies.