Pimp My IDE / garage dispatchBack to the garage
October 12, 2026 / coding agents / delivery evidence

Code is the tach. Delivery is the road.

A new study saw coding agents raise lines, commits, and pull requests. Issue and epic resolution did not move by a statistically significant amount. The review lane took the hit.

More draft work is evidence of activity. It is not a shipped outcome.

The code gauges moved first.

Fiona Chen and James Stratton studied 300 million work events across 718 firms. Their current paper uses staggered firm adoption of coding assistants and coding agents. It follows repository activity, issue work, calendars, employment records, and recorded tool use through March 2026.[1]

After firms introduced coding agents, lines of code rose 30 percent, commits rose 20 percent, and pull requests rose 23 percent on average. Those are real movements in the study. They are also intermediate outputs. A pull request has not passed review, reached production, or solved a customer problem.

Count work at the last boundary you care about, not the first boundary your tool makes cheap.

The review brake heated up.

The same paper reports that average pull-request review time rose 49 percent. The share of pull requests with requested changes nearly doubled. Comments per pull request rose 35 percent. The share of workers doing code review rose 14 percent.[1]

This does not prove that every agent produces poor code. More submitted work can increase queue pressure even when each change is sound. Changed code quality can also increase effort per review. The authors model both paths. A team needs its own queue, revision, defect, and delivery data to tell them apart.

The finish-line gauge stayed flat.

The researchers used resolved Jira issues and epics as firm-level software output. They found small positive estimates after agent adoption, but those estimates were not statistically significant. For agents, the analysis rules out an increase larger than 12 percent of the baseline mean. That is below the 30 percent increase in lines of code.[1]

Ars Technica's report puts the practical problem plainly. Coding speed rose while review absorbed the gain.[2] The paper is stronger evidence than that summary, but it still has limits. It studies participating firms, uses an observational design, and ends before several later agent releases. Issue closure is useful, but it is not revenue, reliability, or customer value.

Adoption volume raises the stakes.

A JetBrains survey of more than 15,000 professional developers in May through July 2026 found that respondents attributed an average 47 percent of their code to agents. The result is self-reported and bucketed. JetBrains notes that category averages can exceed 100 percent and that responses may not be fully accurate.[3]

That survey does not measure delivery impact. It shows why the distinction matters. If agents create a large share of draft code, a dashboard that stops at generated lines can turn a downstream queue into a productivity celebration.

Move the measurement boundary.

Google's Four Keys guide separates deployment frequency and lead time from change failure rate and recovery time. It also warns that teams must define what counts as a production deployment and connect deployments to incidents.[4] That is the right direction. Add review wait, revision rate, issue resolution, and customer-facing outcomes to the same time window.

  1. Record agent adoption by team and task type.
  2. Measure draft volume, review wait, review work, and revision rate.
  3. Connect merged changes to deployments and incidents.
  4. Track resolved work in the issue system without treating every issue as equal.
  5. Compare a stable baseline with the same definitions and time window.
  6. Read the outliers. A median can hide one review queue that is on fire.

The dyno below replays the study's five measurement lenses. It is a reading tool, not a forecast and not telemetry for your team.

Interactive makeover / one productivity number replaced with a linked measurement route

Shift the evidence lens.

A single output counter hides where work accumulates. This native shifter moves through draft, review, and outcome measures. The readout keeps the observed result and its claim limit together.

LinesCommitsPull requestsReviewIssues

Evidence shifter

Use the arrow keys or drag the native range control. Each detent selects one reported study result. It does not combine the values into a score.

Five ordered stops. The control value is the source for every mirrored readout.

Draft
activity
Review
coupler
Resolved
work
Downstream process / observed association
+49%

Average pull-request review time increased after firms introduced coding agents. This result does not identify whether queue volume, code quality, or both caused the extra time.

Stage: reviewRead: review load increased
Sources read / October 12, 2026

Source log

Open the research and measurement record
  1. Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production", current version dated August 4, 2026 and read October 12, 2026. The paper supports the sample, method, activity, review, issue-resolution, labor, and limitation claims in this dispatch.
  2. Kyle Orland, Ars Technica, "AI coding agents generate more code, but not more software", published October 9 and read October 12, 2026. This was the reporting lead. Technical claims were checked against the paper.
  3. JetBrains Research, "How Much Code Do Developers Really Let Agents Write?", published August 26 and read October 12, 2026. The post provides the survey sample, self-reported code-share results, and methodology caveats.
  4. Google Cloud, "Are you an Elite DevOps performer? Find out with the Four Keys Project", read October 12, 2026. The guide defines deployment frequency, lead time, change failure rate, and recovery time. Its editor's note records later changes to the old performance clusters.
  5. Hacker News item 50059523, resolved through the official API and read October 12, 2026. It was the discovery route. Its score and comments support none of the research claims.

Evidence boundary: this dispatch reads and compares published research. We did not receive the proprietary event data, reproduce the difference-in-differences analysis, audit the survey sample, or measure a specific engineering team. The shifter displays reported results and drafts a study note. It does not calculate productivity.