A developer finishes a change sooner with an AI assistant. The pull request then waits for review, grows larger than expected, needs corrections, and joins a queue of other work. The local task got faster. The delivery system did not necessarily get faster with it.
That gap is becoming harder to dismiss as a few isolated complaints. Atlassian's 2026 State of Developer Experience report says 87% of surveyed developers believe AI helps them ship work faster, but only 28% say they experience noticeably less friction in their day-to-day workflow than before AI. In a separate Q3 2026 analysis, DX reports that median weekly pull requests per developer rose 75.5% over four quarters, while perceived ease of delivery improved by only 3%.
Those figures do not prove that AI caused a review bottleneck, nor do they establish that every engineering organization is shipping more valuable software. The two reports use different methods and populations. But together they point to a useful management question: when code creation gets cheaper, where does the saved time go next?
Disclosure: This is a source-based analysis of published survey and engineering-workflow data, not a report from a measured deployment. Atlassian and DX have commercial interests in developer-experience and productivity tools. Treat their findings as signals to investigate in your own context, not universal benchmarks.
The apparent contradiction is the story
Atlassian surveyed more than 1,500 software practitioners for its 2026 report. Its headline findings are positive at the individual-task level: 87% of developers say AI helps them ship work faster, and 80% say it helps them deliver more without working longer hours. Yet just 28% report noticeably less workflow friction than before AI. Atlassian also says 49% spend four or more hours a week reviewing AI output, correcting prompts, and doing related work.
DX's Q3 2026 report looks at a different slice of evidence across more than 500 organizations. It says median weekly TrueThroughput, its measure of pull requests per developer, increased from 1.43 to 2.51 over four quarters, a 75.5% rise. The Q3 increase was 19%, below the roughly 20% pace of the prior year. DX says perceived ease of delivery improved by only 3%. In organizations where at least 80% of code is AI-authored, its report gives a median first-review wait of 82 minutes and says median pull-request size rose 122% year over year.
These are not directly comparable measurements. Atlassian reports practitioner perceptions across a survey. DX combines engineering workflow measures with AI-use data from its customers and uses its own named metric. The percentages do not share a denominator, and one study's 3% should not be subtracted from another study's 87%.
Still, the shape is consistent: people can feel faster at producing or completing a unit of work while the overall experience of getting a change through a software delivery system stays difficult. A fast first draft does not automatically create spare reviewer capacity, reduce coordination, clarify ownership, or make the change smaller and safer to release.
Faster output can move the queue, not remove it
Software delivery is a chain of constrained steps. A change may need implementation, tests, review, security checks, product decisions, deployment coordination, and follow-up. If implementation time falls but the next constrained step stays fixed, work can accumulate before that step.
That is a queueing problem, not a verdict on AI. More output entering a constrained review queue can increase waiting time even if each individual authoring task takes less time. Larger changes can make that worse: reviewers need more context, more lines deserve attention, and a single defect may require another round trip. The reports do not establish that this is happening in every organization, but DX's reported combination of larger pull requests and longer first-review waits in its high AI-authorship cohort makes the mechanism worth checking.
There is another possibility: AI may be helping teams complete work that was already waiting, including maintenance, fixes, and documentation, rather than producing only new features. DX reports that about 33% of observed AI sessions went to maintenance, 23.3% to fixes, and 11% to building new capabilities. More throughput can mean useful debt reduction or reliability work, not just a larger feature count. A dashboard that labels every non-feature task as low value would miss that.
The distinction between speed and value matters. A pull request count can reveal movement, but not whether the work improved reliability, reduced customer pain, met a compliance need, or created future maintenance. Counting more output alone can reward splitting trivial changes or making changes faster than the organization can review them.
Why AI adoption is not the same as an operating model
Tool access can spread one developer at a time. The work around it is shared: code review, testing policy, security boundaries, incident response, documentation, and expectations about acceptable change size. If those practices are unchanged, the newly faster step may simply expose the old constraint more clearly.
Atlassian's report highlights a gap in organizational direction. Only 17% of developers and 23% of leaders said their organization had a clearly communicated and actively implemented AI strategy across the software development lifecycle. It also reports that 75% of developers have more responsibility for validating the quality and safety of AI-generated output. This suggests teams may be adding output and validation obligations at different speeds.
That interpretation is not a causal finding. A survey cannot tell a team which specific process caused its delay, and self-reported expectations may not match measured behavior. Nor does a broadly announced AI policy guarantee a good workflow. The useful point is narrower: if people are asked to use AI but nobody has agreed how review, testing, risk ownership, and measurement should adapt, local speed gains can arrive without a shared system for absorbing them.
A productivity target based on AI usage makes the mismatch worse. Atlassian reports that 64% of leaders see greater AI usage as correlated with better outcomes, while 41% of developers say they use AI more than necessary because they feel expected to. Correlation is not proof of impact, and token volume is not a meaningful definition of engineering value. Pressure to demonstrate usage can encourage activity that looks measurable while leaving the actual delivery constraint untouched.
What an engineering team can measure instead
The answer is not to replace one vanity metric with a larger dashboard. Start with a small set of measurements tied to the bottleneck the team is trying to understand. Use a baseline, compare like with like, and segment carefully. A team adopting AI for maintenance is not automatically comparable to one adopting it for greenfield features.
Track the whole path, not just the typing step. Measure time from work starting to a change being available to users, alongside time spent waiting for review, validation, and deployment. A faster coding phase is useful information, but it is not the outcome by itself.
Watch queue age and review capacity. Look at how long pull requests wait for a first review, how long they remain open, and how many reviews are already in progress per reviewer. If the queue grows while implementation time falls, the constraint may have moved downstream. Ask reviewers whether the work is understandable and appropriately sized, rather than assuming delay is a matter of effort.
Keep change size visible. Track pull-request size and the number of review cycles, but do not make smaller PRs an unexamined quota. Some changes cannot be split cleanly. The question is whether the organization can explain the size and provide enough testing and review for the risk involved.
Pair throughput with quality and outcomes. Follow escaped defects, rollbacks, incidents, rework, and customer-facing outcomes alongside delivery volume. No single measure proves quality. Trends across several indicators are more informative than a claim that more generated code means more productivity.
Separate AI-assisted from non-AI work cautiously. If you collect this data, explain why, minimize personal surveillance, and avoid ranking individual developers by tool usage. Use aggregate comparisons to test workflow changes, not to infer individual performance from a noisy label. AI use is often difficult to classify consistently, and the work itself may differ between groups.
Ask developers where the saved time went. A short, recurring question can reveal whether AI reduced repetitive work, shifted effort into review, enabled previously deferred maintenance, or created new verification tasks. Pair that feedback with system data; neither perception nor telemetry is complete alone.
A practical response to the bottleneck
If the team finds that review is now the longest wait, the first response should not be “make reviewers approve faster.” Review protects the product and the people who depend on it. Instead, inspect why review is expensive: oversized changes, unclear intent, weak tests, missing ownership, or too many unrelated changes arriving together.
Try one small intervention at a time. For example, define a pull-request template that asks for purpose, risk, test evidence, and AI-generated areas requiring extra verification. Keep the template short enough that people will use it. Or set a team norm for splitting work when a change can be reviewed independently without hiding important context. Then check whether review wait, rework, and defects move in the intended direction.
If the real bottleneck is test feedback, review the slowest pipeline stages and flaky tests before adding more parallel work. If the queue is driven by unclear priorities, faster implementation may only increase work in progress. If developers are spending hours checking generated output, identify recurring error types and improve instructions, tests, or task boundaries. Do not assume every verification task can be eliminated; some of it is the necessary cost of trusting a system that produces plausible but fallible changes.
A team should also distinguish a temporary adoption dip from a structural constraint. New tools require learning, and a new workflow can initially add work. Establish a baseline and a review period, then make a decision based on several weeks of comparable data rather than a launch-week impression. Publish the purpose of measurement and what decisions it will and will not inform. That is especially important when the people being measured are also the people expected to trust the results.
What the reports cannot tell us
The headline numbers are useful prompts, not a universal law. Atlassian's sample is a practitioner survey and its claims are self-reported. DX's dataset is broader in organization count but comes from its own customer and product ecosystem; its metric definitions and cohorts matter. Neither summary establishes a randomized comparison showing AI caused a particular delivery outcome. Different codebases, review norms, team sizes, and task mixes can produce very different results.
There are also risks in focusing on pull-request throughput. Teams can increase PR counts by splitting changes, while review load or integration risk rises. Conversely, a team that spends time simplifying architecture or preventing an incident may ship fewer PRs and still create substantial value. Use the measures to locate friction, then check the work's purpose and quality with people who understand it.
The most defensible reading is modest: AI can make parts of software work feel faster, while organization-wide friction remains. Some measured throughput is increasing, but the evidence does not say that every team has converted that increase into better customer outcomes. That is not an argument against AI adoption. It is an argument to treat adoption as a workflow change, not a seat-count project.
The question to take into your next planning meeting
Ask: If AI gave us more implementation capacity this quarter, what is the limiting step between a finished change and a useful result for a user? Then choose one measure that would show whether that step is getting better, and one quality measure that would catch a harmful shortcut.
That question is more valuable than asking how many prompts the team sent. It keeps the focus on delivery, not the appearance of adoption.
I write about practical software engineering, AI tooling, and the systems around them. Subscribe for future source-based analysis and buildable guides. Have you seen AI shorten implementation while review or coordination stayed the same? What did your team measure to find out?
Top comments (0)