Velocity nobody can maintain is a loan, not a gain
The team shipped a lot, fast. Six months later they were the ones stuck maintaining code that had been generated faster than it could be made maintainable.
Velocity nobody can maintain is a loan, not a gain
A director of engineering at a SaaS company told me about a fast period that they were still paying for half a year later. During a push, the team had used AI tools to ship a large amount of functionality quickly, and at the time it felt like pure gain. The features worked, the customers were happy, the roadmap moved. The bill arrived slowly. The code had been generated fast, and fast generation had produced code that was inconsistent, sprawling, and full of patterns nobody on the team had chosen deliberately. When the team needed to maintain it, extend it, and fix it over the following months, they found it was much harder to work with than code they would have written themselves. The velocity had been real, and it had been borrowed, and now they were repaying it in maintenance.
Not all velocity is worth the same
Velocity gets treated as a single good thing, more of it is better. This is only true when the velocity is sustainable, when the code you ship fast is also code you can live with. Fast shipping of maintainable code is a genuine gain. Fast shipping of unmaintainable code is a loan against your future, and the two look identical in the sprint where they happen, because both close tickets and ship features.
AI tools make it easy to generate the second kind without noticing. They can produce a large volume of code quickly, and volume and speed do not imply maintainability. Generated code can be inconsistent across the codebase, structured in ways nobody chose on purpose, and full of local decisions that made sense to the model in the moment and add up to a mess. It works, so it ships, and it feels like velocity. But maintainability is what determines the cost of every future change, and unmaintainable code makes every future change slower. So the fast sprint quietly raises the cost of all the sprints after it. The velocity was pulled forward from the future, and the future pays it back with interest, in the form of a codebase that fights every change.
The reason this is easy to miss is timing. The gain is immediate and visible, the features shipped. The cost is delayed and diffuse, spread across months of harder maintenance that nobody attributes to the fast sprint that caused it. So the team books the velocity as a win and never connects the later drag to it, which means they are likely to do it again.
Keep the velocity sustainable
The lesson is that velocity is only worth having if you can maintain what you shipped, and AI tools make it easy to generate code faster than you can make it maintainable. The discipline is to keep the speed and the maintainability together, so today’s velocity does not become tomorrow’s drag.
What keeps AI-boosted velocity sustainable.
- Hold generated code to the codebase’s standards, so it is consistent with everything around it rather than a foreign patch.
- Keep changes small and shaped deliberately, rather than accepting large generated diffs whose structure nobody chose.
- Refactor generated code into the team’s patterns before it ships, so it is code the team can live with.
- Treat maintainability as part of done, so fast code that is hard to maintain does not count as finished.
- Watch maintenance cost over time, since a rising cost of change is how borrowed velocity shows up later.
The aim is velocity you can sustain, where the code you ship fast is code you can still change fast in six months. The other kind of velocity is just a loan you have not been billed for yet.
How we approach it at Density Labs
The fast sprint that turns into months of maintenance drag is a common and under-recognized cost of AI tools, precisely because the gain and the cost are separated in time. The team ships fast, books the win, and pays for it later in a codebase that resists every change, without ever connecting the two. The velocity was real. It was also borrowed, and unmaintainable code is an expensive loan.
When we help a team use AI tools well, we keep maintainability tied to the velocity, so the speed is sustainable rather than pulled forward from the future. Shipping fast is only a gain if you can still work with what you shipped once the sprint is over.
Velocity you cannot maintain is not velocity. It is a loan against every future change, and the interest is steep.