> When I say maintainability, I mean the specific thing where it becomes really, really hard to change one part of the codebase without breaking another part.
The corollary of agents being bad at maintainability but good at coding is that you can vibecode all the parts where maintainability doesn't matter.
So if you build a (domain-specific) modular architecture for your software first you can then just let your software factories loose on building the modules.
Until you inevitably need a cross cutting concern.
“Oh just this one time”
Then an agent sees the pattern and assumes it’s a best practice. Then your beautiful architecture is ruined.
“Just this once” indeed.
this is 100% right. you have to guard the codebase patterns with your life. because the codebase is part of the prompt.
Except that there is typically a feedback loop between the implementation and the module interfaces. While implementing, you discover aspect that makes you adjust, and sometimes completely alter, the interfaces and module boundaries. And that’s not just for an initial implementation, it continues to happen as new requirements come in over the lifetime of the software. Ostensible implementation details continue to inform the architecture.
yeah this is along the lines of what some friends of mine call "core vs. pragmatic modules" or even s/modules/codebase zones/
the idea that if you have a solid core and decoupled modules, you can have "zones" in your codebase where you allow the model to run wild and do a little slop, because you know the blast radius is contained