Code Board reports that AI tools now generate 41% of code globally. But more AI-generated code doesn’t automatically mean better engineering performance. Leaders need metrics that show whether higher output survives review, reaches production, and creates value.
DORA metrics can be useful for tracking software delivery health. They show changes in deployment frequency, lead time, change failure rate, and recovery time. But they don’t show how much work AI produced, whether AI caused the change, or whether rework offset the speed gain.
That gap matters because AI can increase engineering activity faster than it improves performance. DX found AI usage increased 65% while median pull request throughput grew about 8%. Most organizations saw gains between 5% and 15%, far below the 3x or 10x improvements vendor marketing can imply.
Those results aren’t a failure. A 10% throughput gain across a large engineering organization can create substantial value. The problem is using PR volume or tool adoption as proof that the entire engineering system has improved.
The real question is whether the team is shipping valuable, durable work faster. That requires a broader set of AI developer productivity metrics.
DORA’s 2025 research describes AI as an amplifier that magnifies an organization’s existing strengths and weaknesses. Faster code generation can move the constraint into review, testing, security, deployment, or incident response.
A team may merge more PRs without improving end-to-end delivery because downstream systems can’t absorb the added volume. AI coding tools often move the engineering bottleneck rather than remove it.
GitClear found that heavy AI users generated four to 10 times more durable code than non-users. Those same developers also generated nine times more code churn.
That combination is exactly why volume can be misleading. High-performing engineers may use AI more effectively and produce substantially more lasting work, while still creating much more code that gets revised or removed. Leaders need to measure durable output and rework together rather than treating either number as the full story.
DX found that quality results varied widely after AI adoption. Some organizations improved, while others saw defect rates rise by almost two percentage points. Against an industry benchmark of about 4%, that meant they were shipping roughly 50% more defects than before.
A throughput dashboard won’t reveal that tradeoff. Engineering leaders need to track change failure rate, maintainability, review outcomes, and incident data alongside output metrics.
Vendor studies often measure narrow coding tasks under controlled conditions. Engineering leaders then compare those results with organization-wide delivery, where legacy systems, review capacity, security requirements, and cross-team dependencies shape performance.
A realistic team-level gain can look disappointing when the benchmark is a best-case demo. The better comparison is the same team’s pre-AI baseline, adjusted for the complexity and quality of the work.
No single metric can show whether AI coding tools are working. Engineering leaders need five connected views:
Larridin’s AI developer productivity platform connects to GitHub, Jira, and the broader development stack to measure what AI-augmented engineers actually ship. It combines velocity, quality, complexity, and cost so engineering leaders can see where AI creates leverage and where the gains disappear.
AI coding tools can quickly become a substantial budget line quickly. If leaders evaluate that spend through license utilization, commit counts, or self-reported time savings, a busy dashboard can look like a successful rollout even when quality and delivery haven’t improved.
A defensible ROI case needs a before-and-after baseline at the team or workflow level. It should account for changes in throughput, complexity, quality, and rework, then compare those gains with the full cost of the tools.
The strongest approach tracks the same engineers over time rather than comparing different teams. That helps reduce the effect of tenure, team composition, and other variables that can make AI productivity comparisons look cleaner than they are. Our guide to measuring AI coding tool ROI walks through the calculation.
DORA metrics show software delivery performance, which is important. But they don’t attribute changes to AI, measure AI code share, or show whether faster generation increased rework. Engineering leaders should keep DORA metrics and add AI-specific measures for attribution, complexity, quality, and cost.
Start with AI adoption, AI code share, complexity-adjusted throughput, code churn, code turnover, defects, review time, change failure rate, and total tool cost. The metrics need to work together. High throughput with rising rework tells a different story than high throughput with stable quality.
Compare the value of measurable throughput and quality improvements with the full cost of licenses, token usage, implementation, training, and rework. Use team-level baselines rather than vendor benchmarks or self-reported time savings alone.
Code churn shows how much code is being revised or removed. Rising churn after AI adoption can signal rework, but it needs context because teams producing more durable code may also generate more churn. Pair it with code turnover, defects, incidents, and complexity-adjusted throughput before drawing conclusions.
Larridin measures what AI-augmented engineers ship and how that output performs. Connect engineering activity with complexity-adjusted throughput, quality, rework, and ROI.
Book a discovery call to see where your AI coding tools are creating value and where the gains are getting lost.