Welcome to the latest issue of Engineering Enablement, a weekly newsletter sharing research and perspectives on developer productivity.
Today, we published our Q3 State of AI Impact in Engineering Report, with new data on how AI coding tools continue to shift the role of software engineers.
This is the first time I have felt closer to answering a nagging question: If AI is making engineers more productive, where does that earned time go?
Our data suggests that the answer largely is on maintenance and fixes, yet satisfaction with code maintainability tasks only improved by 0.6% this quarter. Which brings me to another question: why? Is it because the AI tools we have today are uniquely suited to these tasks, or is that just where most of us decided to point them first?
To dig into that question, and a few others, I’ll hand over to Grace Fu, the report’s author, to talk you through some of those key findings.
Grace: In my experience, the adoption of digital tools follows a familiar arc. Initial excitement leads to significant early gains, followed by a flattening of value recognition as bottlenecks appear elsewhere. Looking at our Q3 State of AI in Engineering report, I was fully anticipating some kind of plateau.
The data surprised me. Median weekly TrueThroughput, our complexity-weighted PR throughput metric, is still climbing, up 75.5% over the last four quarters. Velocity isn’t showing any signs of slowing down. What is struggling to keep up is the rest of the SDLC – the review, testing, and verification that turn code into something a team can trust.
Review capacity is a confirmed bottleneck
In Q3 2026, organizations reporting the highest AI code volume waited 105% longer for a first review than those with the lowest.
PR size seems to be a big part of the picture. Median PR size is up 122% year over year, so there’s simply more code to reviewWhat our data can’t tell us is whether something else is going on, and our team has two theories.
The first is that AI-generated changesets take more effort to review, which ties up reviewers and pushes everything else back in the queue. The second is that reviewers hesitate to pick up large, unfamiliar, or AI-generated diffs because of the cognitive friction and the fear of missing a non-obvious bug, which delays the first review directly.
Individual relief versus systemic friction
Developers are telling us that AI is making parts of their work meaningfully better. Our data tells us where the relief is concentrated. We measure this through the Developer Experience Index (DXI), and the figures below are quarter-over-quarter changes in the factors that make it up.
While all factors saw increases from last quarter, these comparisons capture a small point in time, and small shifts at this granularity can look more meaningful than they are. These gains should be read as directional rather than as evidence of a sustained trend until they hold across additional quarters.
Satisfaction with isolated, diagnostic tasks has risen – production debugging is up 13.3% and documentation is up 10.4%. These tasks have clear inputs, verifiable outputs, and short feedback loops, tasks that AI tools typically perform well on.
The smallest gains are in the tasks that require holding a whole system in view. Code maintainability (+0.6%), clear project direction (+2.0%), and the end-to-end experience of moving code safely into production, measured as perceived ease of delivery, improved by only 3%. AI is seeming to help developers navigate existing points of friction faster, but not able to remove more complex systemic friction.
The innovation plateau
Despite reported time savings, the share of time spent on new features has barely moved. Innovation ratio has increased by only one percentage point, a statistically significant (p = 0.002) but small gain.
We previously hypothesized that time saved from AI is going toward addressing existing backlogs, and new telemetry from our AI Code Insights daemon appears to validate this.
About 33% of sessions go to maintenance and 23.3% to fixes, against only 11% on new capability. Code review is among the smallest use cases. That fits the flat ratio, and it’s the clearest direct evidence we have that AI usage is concentrated in keeping existing systems running, not towards innovation.
A framework for context quality
This quarter’s report also reframes many of these friction points using our newly released CAFE(S) framework, which can be used to evaluate the quality of the context supplied to AI systems across five dimensions: Clarity, Actionability, Fidelity, Efficiency, and Security.
Our working hypothesis is that many of these friction areas are being amplified by context constraints, not model capabilities. When agents operate without sufficient architectural intent or clear boundaries, the resulting code is functional but costly to verify, and that cost surfaces downstream, in review queues and delivery friction.
In our report, we link these industry trends to CAFE(S) diagnoses and provide some recommendations for how to address growing bottlenecks. Some of my top recommendations are:
Make intent explicit and machine-readable. Unstated rationale, constraints, and goals are invisible while humans do the work but extremely costly once agents do. Put architectural constraints, ownership boundaries, and acceptance criteria in repos and in a form a model can load.
Re-plan around delivery capacity, not generation capacity. Consistent throughput growth is promising, but it’s arriving alongside longer review waits and bigger PRs. Plan roadmap commitments against the full friction picture, and treat review and verification investment as what makes continued growth safe, not as overhead.
To read more about the trends we’re uncovering and recommendations for engineering leaders moving forward, download the full report here.
That’s it for this week. Thanks for reading.
-Scott
Your second theory matches what we see. A reviewer hesitates on a big agent diff partly because there is nothing to judge it against except the diff itself. On our last build we tried your first recommendation in its strongest form: the intent, constraints and acceptance criteria were written and reviewed before any code. That review was the slow part, sixteen rounds on the specs. After it, code review found little: one of seven task reviews failed, and that one was a test that proved less than the spec asked for. Does the report show whether teams that write intent down first also wait less for a first review, or is that still too early to see?