Bo Frese
AI coding tools don't create technical debt. They amplify what's already there.
If your codebase has quality problems today, and most do, AI will make them worse, and faster. Usually not through dramatic failures, but through a quiet build-up of code that looks fine on the surface, with just enough inconsistency, duplication and architectural drift that every future change takes longer than it should.
Most organisations have already learned to live with this. They hire more people as development gets less efficient, build more support capacity to handle the bugs, and accept that new features take longer than they should. AI won't change that dynamic. It will speed it up.
What I've seen first-hand
For the past year I've been building products from scratch with AI, on my own and end to end. The productivity gains are real. I built things in that time that I couldn't have built alone.
But several times I had to stop and start over. Not refactor, rewrite. AI had helped me build something that worked on the surface but had so much structural inconsistency that cleaning it up would have been slower than starting again. I could do that because it was my own project on my own timeline.
Most teams can't.
Why it builds up faster than you expect
The debt doesn't arrive all at once. It builds up through patterns that are easy to miss, because the code looks reasonable.
AI tends towards the statistically average rather than the excellent, because that's what its training data reflects. It also tends to agree with you. Ask it to review the architecture it just helped you build, and it will mostly find it sound, not because the architecture is good, but because it's trained to be helpful and agreeable. And it starts every session with no memory of what your team decided last month, so each session quietly reinvents what the last one established, and the inconsistencies add up across the codebase.
What makes these patterns so hard to catch is that AI-generated code feels foreign, even to the people who asked for it. Developers don't recognise the problem patterns the way they would in code they wrote themselves. The code passes review and meets the definition of done, and it still slowly weakens the foundation.
Why this is an organisational problem
The technical debt is the symptom. The cause is how most engineering organisations reward software development.
Teams are mainly measured on velocity and feature delivery. Quality matters in principle but gets squeezed in practice, and reducing technical debt is always the thing that moves to the next sprint.
When AI lets a team show working features several times faster, the pressure to put short-term delivery before long-term quality becomes very hard to resist. The debt doesn't announce itself. It builds up quietly, until the thing that was supposed to make you faster is the thing slowing you down.
Organisations that already struggle with technical debt will see it grow faster than anything they've experienced before.
What needs to change
The fix isn't a policy for AI tools. It's the quality culture that makes this dynamic possible in the first place.
That means making technical debt visible in planning, as part of every feature conversation, and not as a separate "tech debt sprint" that gets cancelled under pressure. It means involving the engineers who work in the codebase every day in decisions about technical priorities. And it means treating code quality as a leadership responsibility, not just an engineering concern.
It also means taking documentation seriously, as the context that makes AI useful and not as bureaucracy. Architecture decisions, coding guidelines and the reasoning behind key choices need to live in your repository, versioned with your code. Without them, AI makes decisions without the full picture, in every single session.
There's a nice side effect. The documentation that makes AI useful is the documentation your team has always meant to write. The context AI needs to follow your patterns is the same context a new developer needs on day one, and AI gives you a good daily reason to finally write it down.
The questions to ask now
Before your organisation goes further with AI coding tools, ask yourself honestly:
- Do your teams have the time and the authority to deal with technical debt as they go?
- Are code quality and architectural consistency part of how you measure progress?
- Does your codebase have enough documented context for AI to follow your patterns, instead of inventing new ones?
If the answer to most of these is no, go carefully. The teams that get the most from AI aren't the ones that move fastest at first. They're the ones with a quality foundation that lets speed build on itself instead of decaying.
However much of it AI writes, the code your team ships carries your organisation's signature. Someone on your team still has to own it.