What engineering teams owe for the AI speed boost

The productivity gains were real. Worth saying that upfront, because a lot of the conversation right now sounds like revisionism – like the people who moved fast were somehow naive, and the people who stayed cautious were wise. That's not what happened. Teams shipped faster. Backlogs shrank. A mid-level engineer with decent prompting skills could scaffold a new service in an afternoon that would have taken a senior dev most of a week. Stakeholders loved it, of course they did.

The problem isn't that organisations moved fast. The problem is that some of them stopped there.

Here's what didn't show up in the velocity charts: code that nobody fully understood. Not "bad" code, necessarily – plausible-looking code, code that passed review, code that worked fine in staging. But when the 2am production incident happened, or the security review came around, the engineer who "wrote" it couldn't walk you through it. That's a different kind of risk than the ones most teams were tracking.

Review culture took a quiet hit too. PR turnaround times dropped, which looked like efficiency, and sometimes it was. But the second pair of eyes – the one that catches the auth bug, the injection vector, the edge case that only shows up under load – that pair of eyes started skimming. You can't really blame people. The volume went up, the review expectations didn't change, something had to give.

And then there's the dependency problem. AI-generated code reaches for libraries. Not always the right ones, not always maintained ones, not always the ones already in your stack. Over twelve months of moving fast, a lot of codebases got significantly wider and harder to reason about. Nobody planned for it. Nobody really noticed until they tried to upgrade something.

The architectural decisions are the most concerning. Using AI to generate a utility function is fine. Using it to design your data model or your service boundaries is a different proposition – one that requires understanding tradeoffs and consequences that LLMs don't reliably have. "It worked in the prototype" is doing a lot of heavy lifting in some engineering orgs right now.

None of this is a mystery in hindsight. You give people a powerful new tool and tell them to go faster, and they go faster. The debt accumulates quietly until it doesn't. Security incidents are often the first sign – not always dramatic ones, sometimes it's credentials in a repo, an open endpoint, an unvalidated input that sat there for months before someone noticed. Maintenance slows down. Engineers are slower in codebases they didn't really build, full of patterns that don't match the team's conventions. Abstractions that seemed clean in isolation that don't compose well.

There's also a talent problem that nobody wants to say out loud: junior engineers who spent the last year prompting rather than building are missing some foundational mental models. The ones that let you catch what the model gets wrong. That's not a gap you can hire your way out of quickly, and it's not really their fault – it's the environment they were put in.

So what now? There's no clean undo.

The teams I've seen handle this well aren't doing anything heroic. They're auditing their codebases without turning it into a blame exercise. They're asking which AI-assisted code hasn't had a real senior review, where the test coverage gaps are, what's in the dependency tree that shouldn't be there. They're reinvesting in review – not as a slowdown, but as a recognition that speed without it is just faster debt accumulation. They're being deliberate about the line between AI for implementation (good) and AI for architecture (milage may vary). And they're having the cross-functional conversation — engineering, security, and product in the same room, looking at the same numbers, instead of each optimising for their own metrics.

This is all easy to say in hindsight, the last twelve months weren't a mistake. The speed was real, the competitive pressure was real, and organisations that didn't move lost ground to ones that did. But there's a difference between "we moved fast" and "we're done." The bill for the speed is arriving now – not as punishment, just as the completely predictable consequence of how complex systems work. The organisations that come out of this well are the ones honest enough to look at what they actually built.

If any of this sounds familiar and you find yourself needing a little extra help let's talk.