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.

Not unless agent increases in capability faster than it compiles debt in the codebase!

There has to be some kind of theorem in here, since agent actions (including debt generating ones), are training data for future agents.

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.