Research Report

Three results carry most of the weight behind "AI assistants make developers faster", and two of them measure the same narrow thing: time to finish one self-contained task. The randomised trial behind the headline number handed 95 developers an HTTP server to implement and timed them ^[1] — no legacy code, no review queue, and no product manager changing the requirement halfway through.

The third is a survey, which measures something else again: whether developers believe the tools help, and how many of them have adopted one ^[2]. Belief and task time are both real signals. Neither of them is delivery time, which is what the question asked about.

In the trial condition the task took 55.8% less time, and the effect was largest for the least experienced participants ^[1]. That is a big number, measured honestly — it just belongs to a task shape that most working days do not contain.

Delivery metrics gathered at the organisation level are much flatter. Programmes that track change lead time and deployment frequency find that faster authoring reaches production only when review capacity moves with it ^[3]; where it does not, the work piles up one stage later and lead time is unchanged.

One platform team saw exactly that shape in a single quarter: pull requests opened per week rose, median time-to-first-review rose with them, and nothing shipped sooner ^[4].

Two costs recur across the sources. The first is review load: more code arrives, and it arrives in larger diffs, so the human bottleneck moves rather than disappears ^[3]. The second is rework — accepted suggestions that pass review and return later as defects ^[4].

Interviews with six staff engineers describe a third cost that no dashboard captures: reading unfamiliar code nobody on the team wrote and nobody can be asked about ^[5]. Reviewing generated code costs more attention per line than reviewing a colleague's, and that time is charged to a different budget than the one the assistant credited.

Survey data puts adoption well past the majority mark, but daily use is far narrower than trial use ^[2]. Availability is not uniform either: the feature set differs by plan and by editor, so two developers on the same team can be using materially different tools ^[6].

In the interviews the split ran along task type rather than seniority — heavy use for tests, migrations and boilerplate, near-zero use in the parts of the codebase where a wrong answer is expensive ^[5]. Any team-level average therefore hides two populations.

No source found here measures delivery time end to end for the same team before and after adoption, with review capacity held constant. Until one does, the honest summary is that authoring time falls, and whether that reaches the customer is decided by the stage after it.

Two questions stayed open: whether the rework rate settles after the first year, and whether the benefit survives in a codebase the model has seen too little of to predict well.