AI Adoption Statistics: What the Data Shows About Engineering Productivity

TL;DR: Published AI adoption statistics from GitHub and McKinsey mostly measure usage or self-reported sentiment. McKinsey's 2026 survey shows the gap: 80 percent of respondents say AI improved their individual productivity, while 37 percent report an AI contribution to earnings before interest and taxes (EBIT). Pull requests merged, the figure many teams still treat as return on investment (ROI) evidence, proves code output rose without showing whether that code delivered value. minware regresses roadmap value delivery, on-time delivery rate, and overhead cost against token spend, reading ROI off each slope with each team's trend over time as the supporting check. Bug rate and cycle time act as guardrails.

Engineering leaders preparing for a board review face a specific problem: the AI adoption dashboard shows usage climbing, but roadmap value delivery and cycle time have not moved in a direction they can defend. The gap shows up at the worst possible moment, when the board or CFO asks what the spend bought.

This article synthesizes what published research shows, names where the gap appears, and lays out the regression methodology that closes it.

Reading the headline AI adoption statistics

Adoption statistics measure tool presence on your teams, while delivery data measures the outcomes that presence produces. The numbers coming out of 2025 and 2026 surveys make the gap impossible to ignore.

Interpreting GitHub's Copilot survey data

GitHub's own Copilot research reports high satisfaction, with 90 percent of developers in its Accenture study saying they felt more fulfilled in their jobs. What it does not measure is delivery. GitHub's Copilot usage metrics now reach as far as pull request lifecycle metrics, including merge counts and median time to merge. GitHub's impact dashboard even includes a potential return on investment section that sets cost against pull request output. None of those fields shows whether the merged code delivered roadmap value.

GitHub's dashboard measures tool engagement and code output, while your ROI case requires measuring delivery impact. Those are different questions, and no count of merged pull requests will answer the second one.

Evaluating McKinsey's AI productivity claims

McKinsey's research is widely cited in AI ROI decks, and it deserves scrutiny. Early McKinsey work from 2023 showed developers completing coding tasks up to twice as fast with generative AI. McKinsey's 2026 State of AI survey found that 80 percent of respondents say AI has improved their individual productivity, while only 37 percent report that AI has contributed positively to their organization's EBIT, about the same share as in 2025.

McKinsey's own software development research adds context: top performers achieve 16 to 30 percent improvements in productivity and time to market, with 31 to 45 percent gains in software quality. McKinsey ties those gains to redesigning the whole development lifecycle around AI, which exposes the workflow-change dependency. The 43-point gap between individual productivity and EBIT impact is the adoption trap in one statistic. Task speed and organizational delivery are different measurements. Published AI productivity research keeps proving the first while the second lags.

Decoding the limits of published AI coding data

Three limitations run through nearly all published AI coding adoption data:

• Engagement framing: Vendor dashboards center on active users, suggestions, and acceptance events. Where they reach pull requests, they count merges and time to merge, which still stops short of roadmap value.

• Self-reporting bias: Survey-based research measures how developers feel about their productivity, which can run well ahead of measured results. In METR's early-2025 trial, developers believed AI had sped them up by 20 percent when it had slowed them by 19 percent. METR has since marked that result out of date, and its early-2026 update still calls developers' self-reported speedups "quite unreliable."

• Missing denominator: Usage statistics rarely connect to what shipped, so the figures most leaders quote have no delivery outcome attached.

The result is an industry dataset that is excellent at proving AI tools are open and poor at proving they are working. Recognizing which limitation applies to which source is the first step toward citing this data credibly.

Reconciling AI tool usage with engineering output

Reconciling usage with output starts with a harder look at the headline numbers. Several of the most cited recent statistics appear to contradict each other. The contradictions resolve once you separate usage claims from delivery claims.

Interpreting firm-level adoption data

Broad survey data shows how far adoption has outpaced workflow change. The U.S. Census Bureau's Business Trends and Outlook Survey found that 19.8 percent of U.S. businesses had used AI in a business function in the prior two weeks, as of data collection ending May 3, 2026. In Deloitte's 2026 AI pulse survey, 48 percent of respondents said their organization introduced AI without redesigning the workflows or roles it sits within. Only 12 percent reported redesign at scale.

Adoption without workflow change produces exactly the pattern engineering leaders see in their own data: usage climbs while delivery stays flat. Usage counts inside a team carry the same limit. GitHub's own documentation notes that a flat active-user count treats someone who occasionally accepts a code completion the same as someone who runs agent-driven workflows throughout the day.

Comparing the MIT, Bain, and McKinsey figures

The claim-versus-evidence problem sharpens with two widely cited figures that are easy to misread. MIT NANDA's GenAI Divide report found that about 95 percent of enterprise generative AI pilots delivered little to no measurable impact on profit and loss. Bain's Technology Report 2025 found that some companies report 25 to 30 percent productivity boosts by pairing generative AI with end-to-end process redesign, well above the roughly 10 percent gains from basic code assistants.

Both numbers are real, and both get misquoted as verdicts on coding tools alone. MIT's figure covers enterprise AI pilots across business functions, while Bain's covers software development with end-to-end workflow redesign. McKinsey's AI-native development research adds a third reference point, noting that AI-assisted coding has often delivered 20 to 50 percent improvements across development tasks in early enterprise adoption. None of these figures measured token spend against delivery outcomes, which is the gap a regression fills.

Spotting what averages hide in adoption data

Even where AI adoption data shows gains, the averages hide large differences between workers. Brynjolfsson, Li, and Raymond found that a generative AI assistant raised customer support productivity by 14 percent on average, with a 34 percent improvement for novice, low-skilled workers but minimal impact on the most experienced, highly skilled workers. Effects that vary this much by worker mean an average gain can hide very different results across a team.

Selection bias compounds the problem inside your own org. When you see an AI-versus-non-AI comparison, expect selection effects: engineers reach for AI where it is likely to help, and early adopters are often already the strongest performers. Both effects grow as adoption spreads, because the non-AI group that remains shrinks and self-selects.

Comparing what teams report with what delivery data shows

Team-reported AI experience and measured delivery outcomes diverge for structural reasons that have nothing to do with anyone misreporting. Understanding the mechanisms behind the divergence keeps your internal reporting honest.

Explaining why team sentiment and delivery data diverge

A UC Berkeley Haas study offers one of the sharpest recent findings on this. Researchers Xingqi Maggie Ye and Aruna Ranganathan spent eight months inside a roughly 200-person technology company, conducting more than 40 interviews across functional groups. They found that generative AI didn't free up time. Work intensified instead, as task scope widened and multiple AI-assisted workflows ran in parallel. Individual speed gains can be real while the organization absorbs them into broader scope.

DORA's 2025 research gives the delivery-side picture: 90 percent of technology professionals now use AI at work. Higher AI adoption is associated with increases in both software delivery throughput and software delivery instability. DORA's earlier generative AI report found that a 25 percent increase in AI adoption was associated with a 7.5 percent increase in documentation quality and a 3.4 percent increase in code quality. Delivery instability rose at the same time. DORA measures instability through change failure rate and deployment rework rate. More code arriving faster with worse stability is a throughput pattern with a quality cost attached.

Separating AI hype from delivery data

The contradiction table below is a reference for your next internal debate. Each figure is real, sourced, and explains its own discrepancy.

Claim	Source year	What it shows	Why it does not prove delivery ROI
About 95% of generative AI pilots delivered little to no profit impact	2025 (MIT)	Enterprise AI pilots across business functions	Measures pilot profit and loss impact
25-30% productivity gains	2025 (Bain)	End-to-end lifecycle redesign in software development	Gains depend on workflow change
About 20% firm adoption, 12% workflow redesign	2026 (Census, Deloitte)	Adoption outpaces structural change	Usage metrics ignore whether work changed

Each figure measures a different thing, so quoting any of them as evidence about delivery outcomes is where internal credibility erodes. The synthesis is that AI productivity research shows gains where workflows changed and flat results where only tools changed. Your measurement strategy needs to see the difference, which means tracking the change in delivery per additional dollar of spend.

Proving AI value through concrete delivery metrics

Proving value requires metrics from the delivery side of the software development lifecycle (SDLC), paired with guardrails that catch quality and efficiency regressions.

Measuring AI impact on value delivery

Delivery impact measurement starts with value delivery metrics: roadmap value delivery, which defaults to story points completed on non-bug tickets with a parent epic when no explicit value field is configured, and on-time delivery rate. These are the outcomes a board recognizes, because they map to commitments and roadmap progress.

Efficiency and quality metrics follow as supporting signals. Ticket cycle time and PR lead time show whether work moves faster through the pipeline. Bug rate shows whether quality holds as AI-generated code volume rises. DORA's finding that AI adoption is associated with higher delivery instability makes the quality guardrail mandatory: when adoption rises while stability falls, the efficiency numbers flatter the real picture.

Pinpointing measurable AI productivity gains

The specific trends worth reporting, in order of defensibility:

1. Roadmap value delivery trend: The expected value of completed work per team per time period, defaulting to story points completed, tracked as AI maturity increases.

2. On-time delivery rate trend: Estimated roadmap item duration divided by actual duration, capped at 100 percent per item, over the same window.

3. Ticket cycle time trend: Time from in progress to done, as the efficiency check.

4. Bug rate trend: Bugs created divided by pull requests merged, as the quality check.

Each is a trend for the same team over time, which controls for the between-team differences that distort cohort comparisons. The ordering matters: lead with the value metrics, then let efficiency and quality explain why the trend is moving.

Mapping AI spend to delivery outcomes

The primary methodology is a linear regression of a delivery metric against token spend, fit per team per time period. The slope is the ROI figure: the change in the outcome per additional dollar of spend. The R-squared value tells you how much of the outcome's variation the spend explains, which is the number to cite when a claim leans on the correlation.

One framing to reject is total outcomes divided by total spend. That ratio attributes all delivery to AI spend, including everything your team would have shipped anyway, and it is undefined at zero spend. The slope measures the marginal return, which is the honest figure and the one that survives a CFO's follow-up question about what the next dollar bought.

Balancing AI speed against code quality

DORA's instability finding and a longitudinal study of Cursor adoption in open-source GitHub projects both show quality costs that follow early AI speed gains. That study found the only significant gain in development speed came in the first two months after adoption. Static analysis warnings rose about 30 percent and code complexity rose about 41 percent. Both increases persisted.

When delivery outcomes stall, bug rate and cycle time are where you look for the reason. A single snapshot misses this entirely: a team measured at month two looks like a success story, while the same team measured at month eight looks like a maintenance problem. The trend over time for the same team is what separates durable improvement from a novelty effect.

Replacing adoption metrics with delivery metrics

Moving past adoption and output counts means replacing each one with the metric that answers the delivery question.

Connecting AI activity to delivery outcomes

Vendor APIs and OpenTelemetry integrations now expose token-level usage data across the major tools, so the raw material for outcome analysis exists. The connection work starts with data normalization, which canonicalizes each vendor's format into one model. Entity resolution follows, matching a developer's identity across systems, then recovering the relationships between agent sessions, commits, pull requests, and tickets that carry no structured link.

minware's AI impact reports automate this connection work. The patented hypercube data model recovers those hidden associations, so an agent session that produced no commits still connects to the ticket it belongs to through time-based linking. Identity matching is the easier half of entity resolution. Relationship recovery is the hard half, and it is what makes a spend-to-outcome regression possible.

Questioning acceptance rate as ROI evidence

Acceptance rate is legitimately reportable for suggest-and-accept tools like GitHub Copilot, where it shows how often developers keep what the assistant proposes. It stops at the editor, though, so it can't show whether accepted code was delivered. GitHub's own model team warns against leaning on it. Its engineers found that being hyper-focused on acceptance rate can produce experiences that look good on paper without making developers happier, so they also optimized for accepted and retained characters.

Claude Code reports a suggestion accept rate across its Edit, Write, and NotebookEdit tools, so the metric exists for agents as well as coding assistants. Accepting a suggestion is a different event from delivering value, and that gap is the whole argument. A completion that gets accepted and reverted in the next commit still counts in the vendor's numerator.

Defining token spend as the regression input

Token spend means the dollar cost of AI usage. One qualifier matters for your analysis. Vendor APIs and OpenTelemetry integrations typically expose usage at the token or request level. Cost figures are generally derived by applying published list prices to that usage, so reported spend may differ from actual paid amounts on flat-rate plans such as Claude Pro. Where a customer has significant discounts, minware can multiply reported token costs by the total bill divided by total reported spend to reflect the average discount.

With that caveat, token spend level is the durable variable. In minware's methodology, non-AI work sits at zero spend, so a single continuous regression can include it without a binary split. That answers the CFO's actual question directly: is higher spend buying more delivery, or just a bigger bill? Agent sessions, the unit of real coding agent usage, are an activity metric. They show whether the tool runs, without touching whether delivery changed.

The replacement table is the takeaway for your next reporting cycle:

Replace this	With this	Why
Agent session counts	Token spend	Spend level varies continuously, so it can sit on a regression's x-axis
Pull requests merged	Roadmap value delivery	Merged PRs count code output, while roadmap value delivery counts completed work with expected value
Lines of code	On-time delivery rate	Commitment reliability is what a board reads as delivery

The left column measures activity and output, while the right column measures whether that output delivered value. Bug rate stays alongside every row as the quality guardrail.

Correlating token spend with business outcomes

The regression methodology below connects spend to the outcomes that throughput metrics such as pull requests merged only gesture at.

Running the three-outcome regression

minware's Lean AI Framework regresses three outcomes separately against token spend: roadmap value delivery, on-time delivery rate, and overhead cost. Each regression fits one outcome metric against spend, so three outcomes means three regressions. Regressions default to grouping by team and time period. Each data point is normalized to per-person-day by dividing spend and the outcome by active contributor work days, so team-size differences do not distort the slope.

This is observational analysis, so the confounders need naming. Task-level selection means engineers reach for AI on work where it is likely to help and skip it elsewhere. Person-level selection means early adopters are often already the strongest performers. Covariates like code base age and code quality matter too. The slope answers the spend question while these biases shape how much credit the tool deserves.

The complete readout is three regressions, two guardrails, and one trend per team. The slope on roadmap value delivery tells you whether spend is buying delivery. The bug rate trend tells you what it costs in quality, while the cycle time trend tells you whether the pipeline is absorbing the extra volume. Anything shorter is a claim without evidence.

Tracking delivery shifts for single teams

Alongside the regression, the supporting check is each outcome's trend over time for the same team as AI maturity increases.

One AI-focused analytics vendor now publishes an effectiveness scorecard that evaluates agent sessions. minware connects spend data to roadmap value delivery, on-time delivery rate, and overhead cost, so the trend line answers a different question than a session-level scorecard does. The same drill-down path that powers the trend also surfaces the individual tickets, pull requests, and agent sessions behind any movement, which turns a flat line into a specific to-do list.

Preventing quality decay in AI workflows

Quality decay is the silent failure mode. In the Cursor study, code complexity kept accumulating after early speed gains faded, and DORA's instability finding shows the pattern is not isolated. Bug rate and cycle time both need active tracking here, because each catches a different failure mode.

The prevention pattern is pairing. Every throughput or value claim carries bug rate as its quality counterpart, because bugs created divided by pull requests merged catches defects per unit of output. Cycle time is the efficiency counterpart, because a pipeline slowing under extra volume shows up in ticket cycle time and PR lead time before it shows up in a missed commitment. When either diverges from the value trend, the failing items behind it are where a manager starts. Hygiene metrics like branch-to-ticket linking and ticket estimation keep those associations clean enough to act on.

Closing the gap between adoption and delivery

Published AI adoption statistics show the tools are running, but they say little about whether the spend paid off. Engineering leaders who present pull requests merged as ROI evidence face the same follow-up question every time: what did the extra code deliver? A linear regression of roadmap value delivery, on-time delivery rate, and overhead cost against token spend answers it with a slope for each outcome. Bug rate catches the quality cost that DORA and longitudinal research both document, with cycle time as the efficiency check. The method holds up in an executive review because it names its confounders and reads ROI at the margin.

Start a 14-day free trial at minware.com, no credit card required. Connect your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps. Then connect your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, along with your AI tool's telemetry. The pre-built AI impact reports run on your connected data once the first backfill completes. Historical backfill on first connection can take hours depending on repository size, so connect before your next reporting cycle. Org-specific adjustments typically turn around in a single call, with customer success handling configuration within about 24 hours.

FAQs

What do AI adoption statistics actually measure?

They measure tool usage: seats deployed, active users, suggestions accepted, and agent sessions run. The Census Bureau's figure of 19.8 percent counts businesses using AI, while vendor dashboards count engagement events. None of these numbers connects to what shipped.

Which AI adoption statistics can I cite in a board review?

Cite statistics that name their population and what they measure, such as DORA's 90 percent of technology professionals using AI at work or the Census Bureau's 19.8 percent of businesses. Pair each with a delivery metric from your own data, such as roadmap value delivery, so the board sees usage and outcome together.

How can I tell if AI tools are working for my team?

Regress roadmap value delivery, on-time delivery rate, and overhead cost against token spend per team per time period, then read the slopes. Check bug rate and cycle time trends for the same teams to confirm quality holds as spend rises. minware's AI impact reports run these regressions on connected data.

What does research show about AI coding assistant ROI?

Engineering-specific research points to gains that depend on workflow change. McKinsey reports top performers achieving 16 to 30 percent improvements in productivity and time to market, while DORA's 2025 research links AI adoption to higher delivery throughput alongside higher instability. The widely quoted MIT figure covers enterprise AI pilots across business functions, so it says little about coding tools specifically. Bain's Technology Report 2025 found 25 to 30 percent gains at companies that paired AI with end-to-end process redesign.

Should I compare AI users to non-AI users on my team?

No. As adoption spreads, non-AI comparison groups shrink, and the ones that remain are prone to selection bias because engineers skip AI where it is unlikely to help. Track each outcome's trend over time for the same team instead, with token spend level as the continuous variable.

Key terms glossary

Acceptance rate: The share of AI-generated suggestions a developer accepts, reported by coding assistants and agents including Claude Code. GitHub's own engineers caution that focusing on it alone can produce experiences that look good on paper without making developers happier.

Adoption metrics: Counts of tool usage such as seats deployed, active users, and acceptance events. They answer whether AI is running on your teams, without touching whether it changed delivery.

Bug rate: A quality metric measuring the number of bugs created divided by the number of code changes, by default the number of pull requests merged into a main branch.

Business outcomes: The metrics that boards use to judge AI's impact. Value covers roadmap value delivery and on-time delivery rate. Cost covers roadmap delivery cost and overhead cost.

Cohort comparison: Splitting a population into groups, such as AI users versus non-users, and comparing outcomes. For AI impact analysis it is losing validity because non-AI groups are shrinking and selection-biased.

Cycle time: The workflow guardrail covering ticket cycle time, from in progress to done, and PR lead time, from a pull request's first commit to deployment. Both are efficiency metrics that explain delivery trends without proving delivery value on their own.

On-time delivery rate: The estimated roadmap item duration divided by the actual roadmap item duration, capped at 100 percent per roadmap item.

Overhead cost: Personnel cost and AI token spend that goes toward work not counted in roadmap value delivery, such as cost not traceable to any ticket or traceable to a bug ticket.

Pull requests merged: The total number of pull requests merged, to or from any branch. A throughput metric that measures code output volume.

Roadmap value delivery: The expected value of completed work items. When no explicit value field is configured, it defaults to story points completed on tickets that are not bugs and have a parent epic.

Token spend: The dollar cost of AI tool usage as reported by vendor APIs and OpenTelemetry integrations, generally calculated at list price. Reported spend may differ from amounts paid on flat-rate plans such as Claude Pro.