AI coding tools are everywhere right now, and if you've been using them, they probably feel like they're working. Code ships fast, and your team looks more productive on paper. That's not necessarily wrong, the early gains are real, and the data backs it up.
The problem isn't the start, but what it's building up to.
The Speed Gains Are Real.. and That's Part of the Problem
In July 2025, METR (a non-profit research organization focused on AI evaluation) published what is probably the most rigorous study done on AI coding productivity to date. They ran a randomized controlled trial with 16 experienced open-source developers (people who had an average of five years on their own codebases) completing 246 real tasks with and without AI tools.
The result was not what we, or anyone for that matter, expected. Developers using AI tools took 19% longer to complete their tasks than developers working without them. Before the study, those same developers predicted AI would make them 24% faster. After experiencing the slowdown firsthand, they still believed AI had sped them up by 20%. The gap between what they felt and what was actually happening was 39 percent!
That's the part worth sitting with. The tools weren't failing, but the problem was compounding quietly in the background - in the form of code nobody fully understood, patterns that didn't fit the existing architecture, and fixes on fixes on fixes that added up to a codebase that was getting harder to work in.
The Observed Pattern
Based on aggregated observations from teams using AI coding tools at scale, the trajectory tends to go like this:
Months 1 to 3 - Velocity feels genuinely good. Boilerplate gets written fast and demos look sharp. Leadership notices, and more teams adopt.
Months 4 to 9 - The plateau. Integration gets complicated - features that touch legacy code take longer than expected. Teams start noticing they're spending time cleaning up suggestions. The speedup feels smaller but the adoption is already committed.
Months 10 to 15 - Decline starts. New features now require debugging code from six months ago that nobody properly understood when it was merged. Review cycles get longer. The "AI generated" sections of the codebase start getting a reputation.
Months 16 to 18 (The Wall) - Delivery stalls. Teams can no longer make straightforward changes without unexpected breakage. The codebase has grown larger but the team's understanding of it has shrunk. By this point, unmanaged AI generated code can push maintenance costs to four times traditional levels as the debt compounds.
What's Building Up Underneath
The term being used more and more for this is comprehension debt - the gap between how much code exists in your system and how much anyone on your team genuinely understands.
GitClear's 2026 Maintainability Gap report (which analyzed 623 million code changes from 2023 to 2026) put numbers to what a lot of teams are feeling.
- Refactoring line moves are down 70%.
- Long-term legacy maintenance is down 74% compared to 2022.
- Cross-file function calls, a reliable indicator of code reuse and intentional architecture, are down 35%.
- Copy/paste patterns are up 41%.
- Code block duplication is up 81%.
The code volume is going up and the quality signals are going in the opposite direction.
The Stack Overflow 2025 Developer Survey put the human side of this in perspective - the single biggest frustration developers reported with AI tools was solutions that are 'almost right, but not quite' - cited by 66% of respondents. 'Almost right' is the dangerous part - it passes review, tests, gets merged, and then six months later it's someone's problem.
43% of It Breaks in Production, Anyway
Lightrun's 2026 State of AI-Powered Engineering Report surveyed 200 senior DevOps and SRE leaders at large enterprises and found that 43% of AI-generated code changes require manual debugging in production after passing QA and staging. Not a single respondent said their organization could verify an AI suggested fix with a single redeploy cycle, while 88% needed two to three cycles. 0% of engineering leaders described themselves as 'very confident' that AI generated code would behave correctly once deployed.
Teams who don't hit the wall understand that you need to start treating AI generated code as a first draft that still needs a human to review it.
Using AI Tools on a Production Codebase?
The early benefits exist - the governance gaps usually aren't obvious until month 12 or later. If you want a straight conversation about structuring AI assisted development without that risk, we're easy to reach.
What Separates the Teams That Don't Hit the Wall
The pattern isn't inevitable - some teams are genuinely getting sustained gains from AI tooling. It's all a matter of how they treat the output.
- They set a comprehension requirement before merging. Can the reviewer explain what this code does and why? If the answer is no, it goes back regardless of whether it looks clean.
- They track code churn. Lines of code written per week is a vanity metric when AI is involved. Code revised within two weeks of being written is what tells you whether you're accumulating debt or not.
- They haven't stopped refactoring. Refactoring is the thing that AI most aggressively displaces. it's slower, less visible, and harder to demo. Teams that protect time for it are the ones whose codebases stay workable at month 18 and beyond.
- AI generates.. while humans architect. This distinction is important. Generating a function is different from deciding how that function fits into the system, what it should own, what it shouldn't touch, and how it will behave under conditions that weren't in the prompt. It needs more attention than normal.
Our Take?
We've been watching this pattern play out closely, because it has a direct impact on how we approach builds. There is an appeal to AI tooling, of course. The risk, however, is that speed becomes the only metric, and comprehension gets treated as optional overhead. It isn't. Code nobody understands is a liability that compounds with every sprint on your team.
For teams considering AI assisted development on a serious project, ask yourself - 'what's our governance model for the code that gets generated?'. Without an answer to that, the speed gains in month 3 have a way of showing up as very expensive problems in month 15.
If you're evaluating how AI fits into a custom development project and want a straight conversation about the tradeoffs, our previous piece on AI agents in the development workflow covers the tooling side of this, and we're always happy to talk through the architecture side directly.
