Tech debt is being written faster

‍

Engineering teams have a bit of the codebase that everyone avoids. Until recently, that bit was always the legacy system nobody wanted to modernise, or the integration that still works but nobody quite remembers why. Increasingly, though, the bit of the codebase everyone avoids is not the legacy system at all. It is the code that was shipped in the last twelve months.

‍

AI-assisted development has changed the shape of tech debt without changing its economics. More code is being produced, at a higher speed, than most teams can actively own. In many teams, the engineering discipline around it has not caught up...

‍

For senior technology leaders and for the PE operating partners underwriting AI-driven value creation plans, this is worth paying attention to now rather than at exit. The velocity story that made the case for the AI investment is already producing a maintenance cost that wasn’t priced into the business case.

‍

The velocity of shipping has decoupled from the velocity of understanding

‍

In plenty of teams, a pull request now gets approved after a shallower review than it would have had two years ago, because the reviewer is trusting the pattern rather than checking the specifics. Code gets merged that the reviewer couldn't confidently rewrite from scratch if asked to.

‍

The consequences of this appear slowly. Six months later, when the pricing logic needs to change, or a new market needs a new authorisation flow. The team opens the code and finds itself in unfamiliar territory. What should be a two-day change becomes a two-week investigation. Nobody quite knows why it was built the way it was, because nobody wrote it in the way that would have made the reasoning obvious.

‍

This is not a criticism of the tools. It is what happens when velocity is optimised without a matching investment in comprehension.

‍

We see this most of the time when we take over an engineering function that's been shipping fast. We've inherited platforms where release practices varied from team to team, and nobody could say with confidence who owned a given decision.

‍

The commercial cost appears on a longer timeline

‍

Inside engineering, the first sign is usually maintenance costs rising without an obvious cause. Feature delivery starts to slow even though the team is the same size, bugs take longer to diagnose than they used to, and new joiners need more time to become productive than they did a year and a half ago, without anyone being entirely sure why. In one recent engagement, migrating a service that had been extended by several different hands over eighteen months took longer than the original build because nobody was confident enough in it to touch it without a rewrite.

‍

At CTO level, the story looks broader. The engineering function is producing more code than it can sustain, and the technical debt that has historically accumulated over years is now accumulating over quarters. The velocity metrics on the dashboards still look strong, but the leaders closest to the work know something has shifted, and they are having a harder time explaining what.

‍

The picture at exit is where this becomes most visible in commercial terms. Technical due diligence has evolved to look at exactly this pattern as buyers are no longer only asking what the codebase does. They are asking who understands it well enough to evolve it and how much of it was shipped in a burst that outpaced the team's ability to own it.

‍

A codebase where large parts cannot be confidently explained by anyone still on the team is a codebase the buyer will discount or refuse to absorb. This means that what was described as AI capability at deal close is being repriced as maintenance liability at exit.

‍

What the teams doing that are getting this right?

‍

The strongest engineering teams have adjusted to the new production tools in a way that most have not. They still use the tools heavily but apply a level of discipline to the work around the tools that keeps ownership and velocity moving together.

‍

The most visible sign is how they review AI-generated code. In the strongest teams, the review standard has not been relaxed to accommodate the volume of code being produced. If anything, it has been tightened. There viewer is expected to be able to explain the implementation as if they had written it themselves, and that expectation shapes how the code was written in the first place. The engineer producing the code knows that shallow prompting will not survive review and adjusts accordingly.

‍

Alongside that, the strongest teams have quietly changed how they use the tools day to day. Prompts are used to explore approaches and produce first drafts. The team member then rewrites and restructures the output until it reflects a design that they would have written themselves. The AI accelerates the thinking, but the engineer still owns the delivery.

‍

Finally, refactoring is not indefinitely deferred because velocity is high, documentation is treated as part of the work rather than a nice-to-have, and architectural review is scheduled and honoured rather than pushed to the following quarter.

‍

It is a very old set of practices applied to a new production tool. The uncomfortable truth is that the cost of skipping them compounds much faster than it used to, and by the time the compounding is visible on the dashboards, some of the damage is already done.

‍

What should senior leaders be doing about this?

‍

If you are running an engineering function inside a PE-backed or enterprise business, the questions worth putting on the agenda are less about the tools and more about what the last twelve months have produced.

‍

The first is a question of ownership. Of the code shipped in the last year, how much of it could the current team confidently rewrite from scratch? The gap between what has been shipped and what the team owns is where the current tech debt is sitting.

‍

The second is a question of review discipline. If the answer to "what is the review standard around AI-assisted code" is "the same as any other code," the process should be tested against reality rather than trusted on paper. Reviewers under time pressure make different judgments than reviewers with time to think, and the volume of AI-produced code has increased the time pressure, whether the process acknowledges it or not.

‍

The third is a question about the roadmap. The initiatives that make up your commercial thesis for the next twelve months, how much of them depends on code that nobody on the current team has tested? The gap between the roadmap and the code that can support it is where the real delivery risk sits.

‍

The teams that come through this well are asking these questions now rather than at exit. The ones that don't are usually who bring us in to work. Both are better addressed before the compounding shows up on the dashboards.

‍