AI Made Engineers Faster. It Didn't Make Delivery Faster.

DX just published its Q2 2026 State of AI Impact in Engineering report, drawing on more than 500 organizations. It is the most rigorous industry data available on what AI adoption actually does to software teams, and the headline finding is uncomfortable for anyone who assumed adoption alone was the win. Read the full DX report.

AI utilization is now above 90% industry-wide. The question has shifted from "are we using AI?" to "is it paying off?" The data suggests the honest answer, for most companies, is not yet.

Output is up. Delivery doesn't feel faster.

Median weekly throughput per engineer rose 37% over four quarters. Deployment frequency is up double digits across most segments. By every raw output measure, AI is working.

But developers' perceived rate of delivery has been flat for a full year, holding steady at roughly 67-70%. Pipeline acceleration and how fast work actually feels to the people doing it have decoupled. Code is moving through the system faster. It is not reaching users any faster, and it does not feel faster to the team shipping it.

This is not a contradiction in the data. It is a diagnosis. When one part of a system speeds up and the rest does not, the slack has to go somewhere. In this case, it is going into review queues, approval chains, and the parts of delivery that were never the bottleneck AI was built to solve.

The Developer Experience Index fell, and one number explains why it matters

DX's Developer Experience Index, a composite measure of the conditions that make engineering work sustainable, dropped from 67 to 65 this quarter. That sounds small. DX's own data says a single point of DXI decline costs roughly 10 hours a year per engineer, lost to friction, toil, and bottlenecks. A two-point drop across a 50-person engineering team is 1,000 hours a year quietly disappearing.

The breakdown is specific. Documentation quality, code maintainability, and production debugging all improved, genuine, uncontested wins where AI is clearly pulling its weight. Incremental delivery, local iteration speed, and review turnaround all declined. Median PR size nearly doubled over the same period.

That last number is the tell. Larger, less incremental pull requests take longer to review, are harder to test in isolation, and are more dangerous to revert when something goes wrong. AI did not create the discipline problem of oversized changes. It removed the friction that used to force smaller ones.

Code is easier to read. It is harder to trust.

Code maintainability improved 3.8% this quarter. Change confidence, whether developers trust that their changes won't break something, fell 6.1% in the same period. These two metrics have historically moved together. They are now moving in opposite directions.

One GitHub researcher quoted in the report put it plainly: engineers feel deeply accountable for what ships, and when something is high-risk or hard to undo, they instinctively pull back on how much they lean on AI-generated velocity. That is not irrational. It is a rational response to a system that can now produce code faster than a team can build justified trust in it.

Change failure rate volatility is also up, with some organizations now swinging plus or minus 3 percentage points against a 4% industry benchmark. AI did not invent this volatility. It amplified it.

The counterintuitive quality finding

The report's most striking result: the segments leading on speed are not the segments reporting the highest software quality. Traditional industries report higher perceived quality than tech companies in every single quarter measured, despite tech's clear lead in throughput. Financial services, the slowest-moving vertical in the dataset, posts the highest perceived quality. Healthcare, this quarter's speed leader, sits near the bottom of the quality range.

Speed and quality are not the same curve, and leaders who assume high AI adoption will automatically deliver both are working from a false premise. The traditional industries scoring well on quality tend to be the ones running narrower, more structured AI rollouts rather than broad, fast ones. Discipline appears to matter more than velocity.

Spend is climbing far faster than any proof of return

Median quarterly AI spend rose from roughly $1,500 to nearly $44,000 in a year. In the tech sector specifically, that is closer to a 28x increase. Over the same period, the innovation ratio, the share of engineering time spent building new capability rather than maintaining what already exists, moved from 57% to just 58%. Essentially flat.

This is the sentence worth sitting with: the hours AI is saving are not reliably converting into new value at the organizational level. Time savings are real, now averaging over 6 hours a week for heavy users. But saved hours only matter if they get reinvested into something. Right now, for most companies, they appear to be getting reabsorbed into the same overhead they were supposed to eliminate.

There is one genuine surprise in the cost data. Smaller organizations, those with fewer than 100 engineers, pay a higher premium per AI seat than large enterprises, who negotiate volume discounts. And yet the smaller organizations are extracting more throughput per dollar spent. Bigger AI budgets do not appear to guarantee better returns. In some cases, they come with worse ones.

What this means for teams that haven't scaled AI spend yet

For any organization still early in AI adoption, meaning most companies outside the largest tech firms, this report is a genuine gift. It shows exactly where the industry's leading spenders are struggling, before you repeat their mistakes.

The pattern worth copying is not "spend more." It is what smaller, higher-performing organizations appear to be doing differently: narrower rollouts, tighter quality gates, and treating AI as one part of a system rather than a replacement for engineering discipline. The pattern worth avoiding is the one 90% of the industry has already fallen into: adopting the tool everywhere at once and hoping the surrounding process keeps up.

It will not, on its own. Review capacity, CI pipeline speed, and testing discipline do not scale automatically just because code generation did. An organization that pairs AI adoption with real investment in the parts of the SDLC that were never AI's job, architecture discipline, review standards, testing infrastructure, is the one that actually converts saved hours into shipped value. An organization that only buys the tool is the one that shows up in next year's version of this report still asking why the spend didn't pay off.

That is the argument for treating AI adoption as an engineering decision, not a procurement decision. The tool is the easy part. The system it sits inside is what determines whether the investment ever shows up on the other side.

If you want help thinking through how to build that system properly, get in touch at hello@leptiscode.com.