This ties into something I have been saying for months: LLMs are great at finishing tasks, but bad at aesthetics and taste.
There are two kinds of work: One is goal-driven work, where we have a goal to achieve, and we care very little about how we get there. Security is a perfect example; if you want to exploit a system, you rarely care about how beautiful the exploit is, all you want is access to those super secret nuclear plans. Research is also like this; "research-quality" code was famously terrible, even before the age of AI.
The other kind of work is taste-driven work. People think that, when they're adding a feature to a large codebase, their goal is to add that feature, but that is often not the case. Keeping the codebase amenable to future changes is often far, far more important than this specific feature, and that requires taste. Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
> Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.
Many orgs are quickly moving to a world where code quality and maintainability are not a priority, at all. If claude is just going to write the code, does it matter "maintainable" or "quality" it is? No. It just matters if it works, and if its fast, is how the perspective goes.
The irony is that coding agents are, if anything, more affected by technical debt than human maintainers (who at least occasionally have the taste to rise above the level of the current codebase they're working in). The impact on productivity may be initially delayed, but it's going to compound faster.
I think we have to wait and see if long term maintainability will be any different from human coded software. Every single long surviving human written codebase I have worked with, has significant amounts of tech debt and large pieces had to be rewritten from time to time. This is of course anecdotal and I'm sure clean and elegant old codebases exist somewhere.
The worse designed the code, the more frequently it has to be re-factored. I've worked on long running projects which required essentially no refactoring when implementing new features and I've also worked on projects which had to be re-written multiple times to accommodate requirement changes.
In most half-decent codebases, including LLM generated ones, adding new features almost never requires a refactoring in my experience. It is almost always when you are fixing bugs, improving performance or changing core behavior.
Maintainability is just the inverse of the expected cost to make a future change. Future changes matter, so maintainability matters.
It is, however, true that we don't yet know how to achieve maintainability in the age of LLMs, and whether it keeps being synonymous with aesthetics and code quality as time goes on.
There are two kinds of work: One is goal-driven work, where we have a goal to achieve, and we care very little about how we get there. Security is a perfect example; if you want to exploit a system, you rarely care about how beautiful the exploit is, all you want is access to those super secret nuclear plans. Research is also like this; "research-quality" code was famously terrible, even before the age of AI.
The other kind of work is taste-driven work. People think that, when they're adding a feature to a large codebase, their goal is to add that feature, but that is often not the case. Keeping the codebase amenable to future changes is often far, far more important than this specific feature, and that requires taste. Note that maintainability and code quality aren't synonymous, code quality is just a means to an end, and that end is maintainability.