DX Q2 2026: More Code, Less Confidence (Category #AI4SDLC)

I have been working through DX's new report, The State of AI Impact in Engineering: Q2 2026, based on data from more than 500 engineering organizations. Its most important result is not that AI has finally “proven productivity.” The more interesting finding is the tension that has emerged: code volume and spending are rising, while confidence in changes, developer experience, and the share of time devoted to innovation are failing to keep pace.

DX says AI penetration has already passed 90%, making it almost impossible to compare users with a control group that does not use AI. Instead, the authors examine four quarters of data through DX Core 4—speed, effectiveness, quality, and impact, a framework covered in a previous Research Insights episode—and through the company's own AI measurement framework of adoption, impact, and cost, which I also covered in another Research Insights series.

The report highlights several contradictions.

1️⃣ The gap between code volume and delivery flow DX estimates that AI-generated code accounted for 52% in the second quarter. In a separate methodology note, however, the company clarifies that this is a developer self-report. It should be read as the share of coding workload delegated to AI, not as literally measured lines in a repository. Telemetry provides a more concrete signal. Median TrueThroughput increased by 37% over four quarters, from 1.42 to 1.94 pull requests per engineer per week. At the same time, median PR size grew from 44 to 72 lines, an increase of about 64%. The expected result followed: more changes are moving through the pipeline, and each change is larger on average.

Then the system begins to resist. DX reports deterioration in review time, local iteration speed, and incremental-delivery practices. The average Developer Experience Index fell from 67 to 65. Output increased, but the engineering flow did not become proportionally easier.

2️⃣ The gap between code clarity and confidence in changes Since the first quarter, Code Maintainability has improved by 3.8%, while Change Confidence has fallen by 6.1%. At first this looks strange: the codebase has become easier to understand, yet developers are less confident that a change will not break production. I think this reveals AI's new role clearly. It can explain code, suggest refactorings, and help with documentation. But understanding a particular diff does not yet provide evidence that it is correct. Between “I have read the change” and “I trust it in production” lie tests, review, architectural context, observability, and ownership.

3️⃣ The gap between time saved and value created DX estimates that AI users save four to six hours per week. Yet the innovation ratio—the share of time spent on new product capabilities rather than maintenance and overhead—has remained almost unchanged. The released hours did not become a noticeably larger share of innovative work. Meanwhile, organizations' median quarterly AI spending rose over the year from roughly $1,500 to $44,000. Spending is already scaling; demonstrated downstream impact is not. The saved time appears to be absorbed by old queues: approvals, review, CI/CD, maintenance, technical debt, and organizational fragmentation.

This aligns with other studies I have discussed in Book Cube. - In the GitLab AI Accountability Report, 79% of respondents agreed that individual productivity had improved, while end-to-end delivery accelerated much less; 85% saw the bottleneck move from writing code to review and verification. - The METR experiment offered an even less comfortable counterexample: 16 experienced open-source developers working in familiar repositories completed tasks 19% more slowly with early-2025 AI tools. It is an unusual experiment and is cited often, although I do not place much confidence in it. - This year's DORA ROI, by contrast, offers a vocabulary for explaining the pattern: verification tax, instability, the adoption J-curve, and released engineering capacity that still has to be reinvested effectively.

These results should not be averaged: they were designed and conducted differently, with different audiences and contexts. Their broad themes nevertheless converge. For the DX study, the useful move is to measure AI around the process that matters, not around the tools. A provisional chain could be: adoption → throughput → change size and review → deployment → quality and incidents → product outcome → cost Developer experience, rework, and the distribution of time should sit alongside it. More AI-generated code is a signal of adoption. Higher throughput is a signal of local acceleration. Only stable releases, preserved confidence, and more time for valuable work show that the entire engineering system has become stronger.

#AI #AI4SDLC #Engineering #Management #Metrics #DevEx