How Much Faster Can AI Coding Assistants Really Make Software Delivery?

SECTION 1

Speed, Productivity, and Coding Assistants: What Are We Actually Measuring?

The metric that dominates discussions about the impact of coding assistants on software delivery teams is speed. People often say productivity, but what they really mean in most cases is "how fast are we moving?" The expected answer is usually a simple percentage. Yet the debate has swung like a pendulum: it started with marketing hype at 50% gains, then tipped to the opposite extreme, studies measuring no gains at all, or even slowdowns. METR's 2025 study of experienced open-source developers even documented participants who were 19% slower with AI while believing they were faster; cross-analyses from DORA and other research groups place reality somewhere between +26% and -19% depending on context.

The equation between productivity and speed is certainly debatable, but we won't explore it here. We focus on one precise question: how much does a coding assistant actually improve speed? In the context of software delivery, the best proxy variable we have is the work cycle. To estimate the possible improvements, we have been using a heuristic, a structured hypothesis about team gains, for more than two years, continuously testing it against the data and feedback from our teams and clients.

SECTION 2

A Simple Heuristic for Estimating Time Saved with an AI Assistant

The heuristic rests on three quantified assumptions, here in their "optimistic" version: the share of a team's work cycle spent on coding is 40%; the portion of that coding genuinely supported by the tool is 60%; and when the team uses the assistant, it is 55% faster on that portion.

### Three assumptions, a 13% ceiling

Multiplying these three factors yields a maximum work-cycle reduction of about 13%, and that is with very favorable assumptions. This mathematical ceiling alone explains why the promises of 50% overall gains were untenable: even a perfect assistant only accelerates the fraction of the work that is assisted coding. Results then vary by team, experience level, tech stack, and the nature of the tasks, a poorly documented legacy codebase does not respond like a well-partitioned microservice.

SECTION 3

Case Study: 150 Tickets Tracked with GitHub Copilot

Let's test the heuristic against the field. At one of our client organizations, the teams documented their use of GitHub Copilot across 150 tickets: task type, whether the assistant was used, and the estimated time saved. A few representative examples: a business-code generation ticket with 30% time saved; a known bug fix so simple that the assistant wasn't used; code and test-data generation with a 40% gain; shell scripts generated with a 50% gain; and an exploratory research spike with no measurable gain at all.

### How usage broke down over the period

Over the study period, the teams used Copilot for about 50% of their tickets. Usage broke down as follows: business-code generation 41%, test generation 23%, code understanding 23%, and script generation 13%. The estimated improvement when the assistant was used hovered around 30%, with peaks of 39% on scripts and a floor of 22% on code understanding.

### A work-cycle improvement of roughly 8%

With development work accounting for about 55% of the team's total time, combining these figures yields a work-cycle improvement of roughly 8% in this particular case, well below the heuristic's optimistic scenario, but perfectly consistent with it. It is one data point among many: in other organizations, without such detailed tracking, we observe estimated impact levels between 5 and 15% on team speed.

SECTION 4

Where Coding Assistants Genuinely Save Time

Most of the examples where teams judged the assistant particularly useful involved repetitive or boilerplate code: generating API contracts, adding fields to request bodies, writing script functions. On these tasks, estimated savings regularly reached 30 to 50%. Business-code generation can also be 10 to 40% faster, but the AI's usefulness there is constrained by context: the likelihood of having to rework generated code is high, and what is hard for the developer is also hard for the assistant. Clearly defining business functions, breaking tasks into subtasks, and providing precise instructions remains the best quality lever.

### Test generation and assisted TDD

Generating unit tests and test data produced savings of 15 to 50%. The team even structured an assisted TDD workflow: generating initially failing tests for new functions, then requesting suggestions for additional tests to cover edge cases and exception handling. Looking at a test first makes it possible to systematically validate that the generated code does what is expected of it, a discipline that mitigates the risks inherent to AI-produced code.

### Understanding code you didn't write

Code explanation and analysis proved useful, with more modest gains of 10 to 40%. For deciphering an unfamiliar module or summarizing deployment scripts, the assistant provides a good starting point; some teams even reuse these explanations in requirements-analysis meetings to share business context.

@cite:cas-de-tests-generes-par-ia-a-partir-de-user-stories

SECTION 5

Incidents, Security, Business Logic: When Developers Set the AI Aside

Clear patterns also emerge on the side of tasks where developers deliberately chose not to use the assistant, or found it ineffective, most often exploratory tasks, or ones demanding a fine-grained understanding of context.

Incident response tops the list: on legacy projects, a considerable share of time is spent on call, checking logs and runtime environments across multiple systems, real-time diagnostic work beyond the reach of a completion assistant. Next come minor edits, where the overhead of interacting with an AI suggestion outweighs the benefit; complex business logic and heavy refactoring, which demand a deep understanding of the system's nuances; and vulnerability fixes, handled manually or with deterministic tools, because precision there is non-negotiable and caution toward generated suggestions remains warranted when security is at stake.

Since this data was collected, agents able to explore multiple systems autonomously have started closing part of the gap on incident diagnosis, but the underlying rule stands: the more implicit context a task requires, the tighter the human supervision must be.

@cite:comment-cultiver-la-confiance-avec-les-assistants-de-codage

SECTION 6

From Autocomplete to Coding Agents: What Changes in 2026

Are these 5-to-15% gains bad news? No, provided you read them three ways. First, the anchoring effect: the industry anchored on the 50% marketing figure, which makes 10% look trivial; without that bias, a team that durably gains 10% in speed is getting a very good deal. Second, cost-benefit: assistant licenses represent a tiny fraction of a delivery team's run rate. Third, the work cycle isn't the whole story: onboarding, skill development, test coverage, and developer experience move too.

### The agentic era moves the needle

The landscape has shifted markedly since the study: autocomplete has ceded center stage to coding agents, Claude Code, GitHub Copilot in agent mode, Cursor, able to autonomously chain code reading, change writing, test execution, and iteration. Early-2026 developer surveys show sharply rising adoption of these command-line tools, and the first studies of their large-scale rollouts suggest increased throughput on well-framed tasks. The heuristic's lever shifts: the assistable portion of work grows, but review, framing, and context engineering become the new bottlenecks.

### Measure less, frame better

We caution against obsessing over fine-grained measurement of speed gains: it is often wasted effort. Better to track overall delivery efficiency rather than the impact of one isolated tool; to improve developers' actually available development time and make problems as clear and specific as possible before calling on the AI; and to devote the energy saved to monitoring medium-term risks, quality, security, and the comprehension debt of generated code.

@cite:du-vibe-coding-au-context-engineering-2025

FAQ

Frequently asked questions