By Arjun Mehta
Your team switched to AI coding assistants two quarters ago. Velocity is up 20%. Everyone's pumped. Your CTO is talking about raising the velocity targets for next year.
Then you look at the incident data. Incidents are up 23%. Test coverage is down 15%. Refactoring work has doubled.
You're not actually faster. You're masking slowness with busywork.
The Paradox Explained
AI coding tools optimize for code generation speed, not code quality. They ship more code, faster. But faster code has more bugs.
When incidents go up, engineers spend time fighting fires instead of building features. That time is invisible on the velocity chart. It's just "unplanned work."
So velocity looks great while actual throughput (features shipped and staying stable) is getting worse.
The Real Cost
Metrics from teams using AI coding tools aggressively:
Before AI coding tools:
- Velocity: 100 story points/sprint
- Incidents/month: 4
- Time spent on incidents: 20 hours/month
- Test coverage: 82%
After AI coding tools:
- Velocity: 120 story points/sprint (+20%)
- Incidents/month: 5 (+25%)
- Time spent on incidents: 32 hours/month (+60%)
- Test coverage: 70% (-15%)
The velocity gain is real. But the actual productivity loss is bigger.
Those 20 additional story points are being generated. But 60 hours per month are being spent on firefighting instead of building. That's the cost of lower quality.
Why This Happens
AI generates code faster than tests are written. The ratio breaks. 20 new features generated, but only 4 have comprehensive tests. Coverage drops.
Code reviews become performance bottlenecks. Engineers want to ship fast. AI generates more code. Reviewers get overwhelmed. They skip checks. Bugs slip through.
Less thinking before coding. Normally, you think about a feature, design it, then code it. With Copilot, you jump straight to coding. Less design time = more rework = more bugs.
Architectural violations pile up. AI doesn't know your patterns. After 3 months of AI coding, you have 6 different ways to do the same thing. Systems become harder to understand, modify, and scale.
How to Measure This
You need to track both velocity AND quality:
Velocity: Story points shipped (good) Incidents: Bugs reaching production (bad) Refactoring: Hours spent fixing mistakes (bad) Test coverage: % of code tested (good) Onboarding time: Time to new engineer productivity (bad if increasing)
Plot these together. If velocity is up but incidents are up and coverage is down, you have a problem.
How to Fix It
Don't just use AI for generation. Use it for testing too. AI can generate tests. The best teams have AI write both code and tests.
Enforce coverage gates. PRs with <80% coverage don't merge. This forces test writing, which forces thinking.
Review AI code more carefully. Have your most experienced engineers review code generated by AI. They'll catch architectural violations.
Limit AI use to specific code types. Boilerplate, tests, documentation: go fast. Core business logic, payment processing, authentication: review carefully.
Measure actual productivity, not story points. Track bugs, customer issues, time spent in incident response. These are better proxies for real productivity.
The Real Problem
The real problem is that teams optimize for the wrong metric. Velocity looks great. So managers are happy. But the team is working harder, breaking more things, and less satisfied.
The right metric is: "How much valuable stuff did we ship that stayed stable?"
Not "How many story points did we generate?"
These are different things. And measuring the first one actually takes thinking.
Frequently Asked Questions
Q: Should we stop using AI coding tools?
No. Use them, but with guardrails. Measure quality metrics. If they're degrading, adjust how you use AI.
Q: What's a healthy velocity-to-incident ratio?
Varies, but use it as a trend indicator. If velocity is up 20% but incidents are up 25%, something's wrong. If velocity is up 20% and incidents are flat, you're doing well.