AI solutions / Developer productivity
Across 22,000 developers, AI raised tasks completed per developer by 33.7% and median pull request review time by 441%. The constraint moved from writing code to reviewing it, so organisational delivery stayed flat while incidents rose. DILR.ai widens the code review stage, which is the part that converts individual speed into shipped software.
Two independent sources say the same thing. Faros AI's engineering telemetry covers 22,000 developers across more than 4,000 teams. Google's DORA 2025 State of DevOps report surveyed around 5,000. Both find AI adoption raising throughput and damaging stability at the same time, in the same teams.
DORA's own framing is the useful one: AI does not fix a team, it amplifies whatever capability the team already has. A team with fast, automated review gets faster. A team whose review is a queue of humans gets a longer queue.
| Measure | 2025 | 2026 |
|---|---|---|
| Tasks completed per developer | +21% | +33.7% |
| Pull requests merged per developer | +98% | +16.2% |
| Median pull request review time | +91% | +441% |
| Pull request size | +154% | +51.3% |
| Bugs per developer | +9% | +54% |
| Incidents per pull request | — | +242.7% |
Generating more code against an unchanged review stage makes the queue longer, not the delivery faster. Four things move the constraint, and they are the work of the Execution Office stage of DATS.
Style, obvious defects, test coverage and convention drift are gates, not judgement calls. Every one of those a machine catches is reviewer attention returned to design and correctness.
The same harness engineering that makes an agent reliable makes a pipeline reliable: a suite that says whether this change made the system better or worse, running on every change.
Faros measured pull request size rising 154% in 2025 and 51.3% in 2026. A large pull request is reviewed worse and slower than two small ones, so the size limit is a throughput control, not bureaucracy.
Individual output rose in every study here and delivery did not. If your dashboard reports commits and pull requests, it will show a win that your customers never receive. Measure at the DORA level instead.
Quick answers
Direct answers on AI developer productivity, the code review bottleneck and what the DORA data actually says. Every figure names its source and sample size.
Individually, yes, measurably. Faros AI telemetry across 22,000 developers found tasks completed per developer up 33.7%. Organisationally, often not: the same dataset shows median pull request review time up 441% and incidents per pull request up 242.7%, so the gain is absorbed before it reaches a customer. Google's DORA 2025 report found the same split across about 5,000 developers.
When AI accelerates code generation without accelerating review, unreviewed pull requests accumulate and absorb the productivity gain. Faros measured median review time up 441% and 31% more pull requests merging with no review at all, which trades a delivery problem for a quality one.
That AI adoption correlates positively with software delivery throughput and negatively with stability, at the same time. Its central conclusion is that AI amplifies existing capability rather than supplying it: strong teams get stronger, struggling teams surface their weaknesses faster.
Move work off the human reviewer, gate the merge with an evaluation harness, cap pull request size, and measure delivery at the team level rather than per developer. That is the Execution Office engagement, and where AI belongs in your specific pipeline is what the Placement Diagnostic settles first.
30 minutes, no deck. We look at where your changes queue and what it is costing, whether or not you work with us.
From the blog