If you've been watching the AI coding tools market, the productivity narrative has been consistent for the last two years: developers write code faster with AI assistance. GitHub Copilot studies showed it, internal productivity reports from large engineering organisations showed it, and developers' own experience confirmed it. The question that's been harder to answer is whether writing code faster translates to shipping software faster.
GitLab's 2026 AI Accountability Report provides some of the most direct evidence yet on that question, and the answer is complicated. The report surveyed approximately 5,000 software developers and engineering leaders across a range of company sizes and geographies. It found that AI coding tools are delivering the productivity gains at the individual level that vendors promised. It also found that those gains are largely not reaching the bottom line of software delivery speed.
What the Data Actually Shows
The headline finding is the 78% figure: 78% of surveyed developers report that AI tools help them write code faster. That's a substantial majority, and it aligns with what other studies have found. Individual developer velocity is genuinely up.
The more telling finding is the bottleneck data. 85% of respondents say AI tools have shifted their primary bottleneck from writing code to reviewing code. When a developer can generate a feature in a fraction of the time it used to take, the constraint on their team's throughput moves to whatever comes after the code is written. In most software teams, that's review, testing, and integration.
“AI tools have shifted the bottleneck from writing code to reviewing code for 85% of developers surveyed.”
The review bottleneck is compounded by a quality concern that 82% of respondents flagged: AI-generated code risks introducing new technical debt. This isn't an abstract worry — developers are seeing it in their daily work. Code that looks syntactically correct and passes automated checks can carry subtle problems: logic errors that only surface in production, patterns that conflict with the codebase's established architecture, dependencies that create upgrade liabilities. Reviewing AI-generated code well takes time and attention that the speed gain on the generation side doesn't automatically free up.
The Tool Proliferation Problem
One finding that deserves more attention than it usually gets: 91% of organisations in the survey have two or more AI coding tools active simultaneously. That's not 91% using AI tools — that's 91% running multiple overlapping tools.
This matters because tool proliferation has its own overhead. Developers context-switching between tools with different UX models, different integration points, and different quality characteristics add friction that partially offsets the productivity gains. Engineering managers coordinating costs, licences, and usage policies across multiple tools add administrative load. And the data quality of AI suggestions varies between tools in ways that aren't always predictable, which means developers have to develop intuitions about when to trust which tool — a cognitive tax that doesn't show up in individual productivity metrics.
The tool proliferation numbers
91% of organisations run 2+ AI coding tools simultaneously. Managing multiple tools creates its own overhead: context switching, cost coordination, and variable suggestion quality across tools. The productivity gain per tool may be real while the aggregate effect on team efficiency is diluted.
Why Delivery Speed Hasn't Caught Up
The gap between individual coding velocity and team delivery speed is a systems problem. Software delivery is a pipeline, and the speed of the pipeline is determined by its slowest stage. AI tools accelerated one stage — code generation — without proportionally accelerating the adjacent stages of review, testing, and deployment.
Review is harder to accelerate than generation for structural reasons. Good code review requires understanding the intention behind a change, its implications for the broader system, and its alignment with architectural decisions that may not be explicitly documented anywhere. These are tasks that resist automation in the same way that generation doesn't — they require contextual judgment that current AI systems struggle with.
Testing presents a similar dynamic. AI tools can generate test cases, but the test suite still needs to run, failures need to be investigated, and the team needs confidence that coverage is meaningful rather than just numerically adequate. If more code is being generated per unit time, more tests need to be written and verified per unit time, and the test infrastructure needs to keep pace.
The result is a pattern that shows up in the GitLab data and in anecdotal reports from engineering leaders: teams that adopted AI coding tools saw their developers' individual output metrics improve while their sprint completion rates and release cadences stayed flat or improved only modestly. The work moved through the system faster at the generation stage and backed up at the review and integration stages.
What Actually Helps
The GitLab report doesn't just identify the problem — it points toward what's working for teams that have gotten closer to translating individual productivity gains into delivery improvements. The pattern that emerges is investment in the downstream stages, not just the generation stage.
Teams that have seen delivery speed improvements alongside coding velocity improvements tend to have made deliberate investments in review tooling — AI-assisted code review that helps reviewers surface issues faster, not just AI that generates code faster. They've also invested in automated quality checks that run before human review, filtering out the class of issues that AI generation is most prone to introducing.
The teams that struggled tend to be the ones that treated AI coding tools as a plug-in productivity upgrade rather than a reason to re-examine how the whole pipeline works. If you add a faster code generation layer without adjusting the downstream stages to handle the increased volume, you've moved the bottleneck. You haven't removed it.
The Honest Takeaway
The 78% coding faster headline is real, and it matters. Individual developers are producing more in less time, and that has genuine value — it reduces the cognitive cost of implementation, allows more design iterations, and lets developers spend time on higher-level problems rather than mechanical translation of logic into code.
But the delivery speed problem is also real, and it's a systems problem that individual tool adoption doesn't solve by itself. If your team's goal is to ship software faster, the question isn't whether to adopt AI coding tools — you probably already have. The question is whether you've designed the rest of the pipeline to take advantage of the generation speed-up, or whether you've just moved where the work queues up.
The GitLab data suggests most teams are still in the latter category. The next wave of productivity work in engineering isn't about writing code faster. It's about reviewing, testing, and integrating it faster — without sacrificing the quality bar that makes speed sustainable.