The Pitch Sounds Great Until You Do the Math
Every AI coding tool on the market makes the same promise: more code, faster. And they deliver - at least on that specific metric. GitHub reports that Copilot users complete tasks 55% faster. Your team ships pull requests at 2x the previous rate. The velocity charts look incredible in your next board update.
But velocity charts measure output, not progress. And a growing body of research suggests that for experienced teams working on production systems, AI-assisted coding may be creating a maintenance trap that erases the productivity gains within months.
The Maintenance Cost Math
James Shore, an Agile consultant who has spent decades helping late-stage startups recover from accumulated technical debt, published a model this week that makes the economics uncomfortably clear:
You write code twice as quick now? Better hope you've halved your maintenance costs. Three times as productive? One third the maintenance costs. Otherwise, you're screwed. You're trading a temporary speed boost for permanent indenture.
Here's why. Every line of code you ship has ongoing maintenance costs: bug fixes, dependency upgrades, refactoring, documentation. Shore's model shows that a team typically crosses the 50% maintenance threshold - where more than half their time goes to upkeep rather than new features - after about 2.5 years.
Now introduce an AI coding agent that doubles output. If the generated code is even slightly harder to maintain than human-written code (more complex, less idiomatic, more assumptions baked in), the math compounds fast:
- 2x output + same maintenance cost per line = you hit the 50% threshold in ~1.5 years instead of 2.5
- 2x output + 2x maintenance cost per line = your next month's maintenance costs quadruple. You're back to baseline productivity in ~5 months, then worse off than if you'd never used the tool.
The kicker: when you stop using the AI to save on subscription costs, the code it already wrote doesn't go away. The maintenance burden is permanent. The speed boost was temporary.
The Research Backs This Up
Shore's model isn't theoretical hand-waving. It's supported by empirical research from multiple independent teams:
Tilburg University (arXiv 2510.10165): Researchers analyzed developer activity across Microsoft-owned open-source projects after GitHub Copilot's introduction. They found that while total productivity increased, the gains came almost entirely from less-experienced contributors. Core developers - the experienced maintainers - saw a 19% drop in their original code productivity because they were drowning in review work. PR rework increased by 2.4%, indicating accumulating technical debt.
METR Randomized Controlled Trial: In a paid experiment, experienced open-source developers using AI tools took 19% longer to complete tasks in their own codebases - despite believing they were 20% faster. The tools helped write code quickly but added overhead in context-switching, review, and integration that more than consumed the time saved.
METR's February 2026 follow-up acknowledged that newer tools may be faster, but couldn't measure it cleanly because developers now refuse to work without AI - they've become dependent on the speed even if total throughput hasn't improved.
What This Means for Your Business
If you're a founder or operator evaluating whether to arm your team with AI coding tools - or whether to hire a team that uses them heavily - here's the practical implication:
The question isn't "does AI make developers faster at writing code?" The answer is obviously yes.
The question is "does AI make your codebase cheaper to own over 3 years?" And for most teams today, the honest answer is: we don't know, and the early evidence is concerning.
The Trap Looks Like This
- Month 1-3: Velocity doubles. Everyone's excited. Sprint demos are packed.
- Month 4-6: Bug reports start climbing. Code reviews take longer. Senior devs are frustrated but can't articulate why.
- Month 7-12: You're adding headcount to handle maintenance. The AI-generated code is functional but poorly integrated - it works, but nobody fully understands why it works in the context of your system.
- Month 13+: You're spending more on engineering than before you adopted the tools, with a codebase that's harder to modify.
How to Avoid It
AI coding tools aren't inherently bad. But they require specific guardrails to avoid the maintenance trap:
1. Constrain AI output with specifications. Don't let agents write whatever they want and then review the output. Define what they should build first. Spec-driven development - where requirements, interface contracts, and architectural constraints are written before the AI touches code - prevents the "10-30 unstated assumptions per feature" problem that compounds at AI speed.
2. Measure maintenance cost, not just velocity. Track time-to-fix for bugs, PR review duration, and rework rate. If these are climbing while velocity stays flat or rises, you're accumulating debt faster than you're shipping value.
3. Keep experienced developers writing code, not just reviewing it. The Tilburg study's most alarming finding wasn't the overall productivity number - it was that experienced developers stopped producing original work to become full-time reviewers. That's a death spiral for institutional knowledge.
4. Treat AI-generated code with the same (or more) scrutiny as junior developer code. Because that's what it is - code from a fast, confident contributor who doesn't understand your system's history or invariants.
5. Budget for refactoring from day one. If you're using AI to accelerate a build, allocate 20-30% of your sprint capacity to refactoring AI output into idiomatic, well-integrated code. This is the cost of the speed boost.
The Apptitude Perspective
At Apptitude, we use AI coding tools daily. We also review every line they produce against system architecture, and we spec work before generation - not after. The tools accelerate us because we treat their output as a first draft, not a final product.
When clients come to us after a rapid AI-assisted build that's become unmaintainable, the pattern is always the same: the initial build was fast and cheap, but nobody planned for the code to be owned by humans long-term.
Our approach:
- We define specifications and architectural boundaries before AI generates code
- We measure total cost of ownership, not just time-to-deploy
- We build with maintenance in mind from sprint one, because we know the math
If you're planning an AI-assisted build and want to avoid trading speed for long-term indenture, talk to us. We'll show you how the math works for your specific project.
Sources:
- James Shore, "You Need AI That Reduces Maintenance Costs" (May 10, 2026)
- Xu et al., "AI-Assisted Programming Decreases the Productivity of Experienced Developers" (arXiv 2510.10165, revised Jan 2026)
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (Jul 2025)
- METR, "We are Changing our Developer Productivity Experiment Design" (Feb 2026)