Your AI Adoption Number Is Lying to You

Ask most engineering leaders how AI adoption is going, and you'll likely get a number: percentage of developers with a Copilot or Claude Code seat, percentage of the org that's "used AI this month," maybe a slide with a big satisfied looking 87% on it. That number feels like progress. It's also nearly meaningless on its own.

Adoption tells you how many people picked up the tool. It tells you nothing about whether the tool is making your software delivery system faster, safer, or more expensive to run. Those are different questions, and in 2026 the data on all three is finally rich enough to ask them properly.

What follows are the metrics a VP of Engineering or a CTO needs to know whether AI investment is translating into real performance, or just into more code sitting in a review queue.

Why "Adoption" Alone Doesn't Cut It

DORA's own research illustrates the problem directly. Their 2025 State of AI-Assisted Software Development report found that AI amplifies whatever engineering conditions already exist, strengths and dysfunction alike. Increased AI adoption correlated with increased delivery instability even while it improved individual effectiveness and code quality, largely because the volume of code being generated started outpacing the review and deployment infrastructure built to absorb it. DORA researchers describe this as the early phase of a J-curve, and you only know you're in one if you're tracking more than the adoption number.

Sonar's 2026 State of Code Developer Survey adds the sharpest possible illustration. AI now accounts for 42% of committed code industry-wide, expected to climb to 65% by 2027, and 72% of developers who've tried AI tools use them daily. That's about as strong an adoption signal as you'll find anywhere. And yet 96% of those same developers don't fully trust the code AI hands them, and only 48% say they always verify it before committing. High adoption. Low trust. Inconsistent verification. That combination is exactly what a delivery-system dashboard needs to catch, and exactly what a pure adoption metric will never show you.

Four Layers of Metrics That Show Whether AI Is Working

1. Adoption & Penetration

The right adoption metrics measure how much AI is touching your delivery pipeline.

• % of committed code that is AI-assisted or generated. The real denominator for everything else on this list. It shows how much of your output needs AI-specific scrutiny, which seat counts never will.
• Sanctioned vs. shadow usage gap. Sonar found that 35% of developers use AI coding tools through personal accounts, and MIT's Project NANDA found over 90% of employees use personal AI tools for work. The gap between your official adoption number and this one is a governance and security blind spot.
• Agent-initiated vs. human-initiated PR share. How much of your pipeline's volume originates from an autonomous agent acting without a human opening the PR first. Most organizations don't track this yet. That's itself worth noting on a dashboard. No industry-wide figure exists for this yet, which is itself a signal of how new the practice is.

2. Delivery Performance Impact

This is where the DORA metrics live. DORA's research has tracked five metrics since 2024, when Deployment Rework Rate joined the original four, and Mean Time to Recovery is now called Failed Deployment Recovery Time. The five show what is happening but not why, and they can't tell you whether a person or a model wrote the change. That's a real attribution gap.

• Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time, and Deployment Rework Rate. Same five metrics, more important than ever. Once AI writes 30% to 70% of committed code, Deployment Frequency and Lead Time for Changes on their own turn misleading. Pair them with AI attribution and complexity-adjusted throughput.
• Throughput by percentile, not average. Push for this on any leadership dashboard. CircleCI's 2026 report, drawn from more than 28 million CI workflows, found throughput up 59% on average. But the top 5% of teams nearly doubled, the median team improved 4%, and the bottom 25% saw no measurable gain.

3. Verification Cost

This is where the friction that used to live in writing code went, and it's the layer most dashboards skip entirely.

• Merge Efficiency Ratio (MER). CircleCI introduced this metric in its 2026 Q2 Pulse report to track how many validation cycles it takes to ship a single change. Code volume without a matching measure of validation effort is a false signal of progress.
• PR review time and no-review-merge rate, segmented by author type. Faros AI's 2026 telemetry across 22,000 developers found median PR review time up 441%  between low and high AI-adoption periods, alongside a 31% rise in PRs merging with no review at all. The second number is the worrying one: rising review time means someone is looking, while a rising no-review rate means the safety net is being skipped.
• Cost per shipped change. Elite organizations in CircleCI's Q2 report grew main-branch throughput 72% in a year while cutting cost per shipped change 31%. More throughput and lower cost per change is the proof AI is paying for itself.

4. Trust, Reliability & ROI

The last layer answers the question underneath all the others: is any of this translating into something the business can point to?

• AI-attributed Change Failure Rate vs. overall CFR. If AI-attributed failures run meaningfully above your human-authored baseline, it's a governance signal to tighten review discipline before scaling usage. 
• Incidents per PR. Faros's 2026 data found incidents per PR up 242.7% between low- and high-AI-adoption periods, so the odds of a production incident per merged change more than tripled. Paired with the no-review-merge rate, it's the clearest sign that speed and safety have decoupled. 
• Perceived vs. measured productivity gap. The best available proof that self-reported sentiment is not a delivery metric. METR's randomized controlled trial found experienced developers were 19% slower on real tasks, despite forecasting a 24% speedup and estimating afterward that they'd been 20% faster. METR's later follow-up pointed toward a speedup, but METR itself calls the data unreliable. Treat these as snapshots, not verdicts. A periodic blinded comparison of what your team believes against what your delivery data shows is worth building into a review cadence. 
• Pilot-to-production conversion rate. MIT NANDA's GenAI Divide research found that despite $30-40 billion in enterprise generative AI investment, 95% of organizations saw no measurable financial return. The report has its critics and was preliminary rather than peer-reviewed, so treat the exact percentage with skepticism. Your own pilot-to-production ratio still shows which side of the divide you're on.

The Scorecard

It's important to note before moving forward that the baselines mentioned below for each of these metrics are just that: a baseline. You need to know where you and your organization currently stand on each of these before arbitrarily placing these on your engineering teams.

Measuring AI in software engineering

What follows are nine metrics across the above four areas, what each one tells you, and where the industry stands today. Note: two metrics currently do not have a published baseline, but are important to start tracking for yourselves.

Establish your own baseline before setting targets and revisit it as your organization's AI fluency grows. 

The Point of All This

None of these numbers are good or bad sitting by themselves. A team with 65% AI-authored code and a flat change failure rate is winning. A team with the same adoption number and a climbing one is amplifying dysfunction faster than they used to, just like DORA's amplifier framing predicts.

That's really the whole argument. Adoption is easy to measure and easy to celebrate. Whether it's working is a different, harder question, and it's the one your delivery data can answer if you're willing to look past the number that makes the slide look good.