The call
The source is a Harvard working paper by Fiona Chen and James Stratton, built on Jellyfish engineering telemetry: 725,938 workers at 718 firms, about 300 million work events, January 2021 to March 2026 (independent, the paper). Coverage broke on 12 October (AI Weekly, quoting Ars Technica) and reached the Hacker News front page the same day with 298 points (Zeli digest).
What it is, and what it is not
What it is. A staggered difference-in-differences study comparing firms before and after they adopted coding agents of the Claude Code, Cursor, and Devin class. After adoption, each engineer wrote 1,494 more lines a month (30% on a 5,017 baseline), 20% more commits, and 23% more pull requests. Jira issues resolved per engineer moved by 0.12 on a 3.67 baseline, which is not statistically significant, and the confidence interval rules out a rise above 12% (independent, the paper). Employment did not fall.
What it is not. It is not proof that agents fail. It is not a defect study: bug and escape rates are not reported. It is not peer-reviewed; it is a job market paper, first posted 7 January 2026, current version 4 August. And it is not Salesforce-specific. Apex and metadata teams are not broken out.
The number nobody is quoting
Everyone is quoting “30% more code”. The number that decides your delivery dates is the review queue. The paper reports that time from pull request to merge rose by 3.45 days on a 7.03-day baseline, 49%, and that the share of pull requests sent back for changes rose from 13% to 25% (independent, the paper). Nobody has multiplied the two together.
Little's Law says work waiting equals arrival rate times time in the system. Apply it per engineer, with a 30.44-day month:
| Per engineer | Before agents | After agents | Label |
|---|---|---|---|
| Pull requests a month | 5.34 | 5.34 + 1.22 = 6.56 | independent |
| Days from PR to merge | 7.03 | 7.03 + 3.45 = 10.48 | independent |
| Pull requests waiting in review at any moment | 5.34 ÷ 30.44 × 7.03 = 1.23 | 6.56 ÷ 30.44 × 10.48 = 2.26 | our maths |
| Sent back for changes, per 100 engineers a month | 534 × 13% = 69 | 656 × 25% = 164 | our maths |
For a 100-engineer team that is about 123 pull requests sitting in review on an ordinary day before agents, and about 226 after: 83% more work in progress, and 2.4 times as many send-backs, for an increase in shipped issues the study cannot distinguish from zero (our maths, steady-state assumption). At the very top of the confidence interval, 12% more shipped issues from 30% more code, at most 40% of the extra code reaches the backlog as finished work (our maths).
The licence buys typing. The queue is where the money goes.
Missing
What neither the study nor the agent vendors have told you:
- Defect and rollback rates after adoption. The paper does not report them.
- A split by tool. Claude Code, Cursor, and Devin are pooled.
- Usage intensity. Adoption is the first seat or bot signal at the firm, not how much each engineer uses it.
- Anything after March 2026. Current agent generations are not in the data.
- Whether AI review closes the gap. By March 2026 nearly 80% of firms had used AI review tools, yet only 23.3% of review comments were AI-generated (independent, the paper).
- Salesforce numbers. No figures for Apex, Lightning Web Components, or metadata deployments.
Who owns what
Writing the code is the agent's job. Merging it safely is ours.
In a Salesforce programme the review queue already has a hard gate: Apex needs 75% test coverage to deploy to production, and every change should pass through source control, a sandbox, and a human reviewer before it gets there. Agents feed the front of that pipeline faster. They do nothing for the reviewer, the sandbox refresh, or the release window. Salesforce Code Analyzer and a CI check in your Git pipeline can catch the mechanical issues before a human looks, so reviewers spend their time on design and data access, which is where an agent's mistakes cost most.
Monday morning
- Step 1. Baseline the queue. Pull 90 days of pull requests: count opened, median days to merge, and share sent back for changes. Owner: engineering manager.
- Step 2. Do the multiplication. Pull requests a day times days to merge gives your work in progress. Put it next to seat count. Owner: VP engineering.
- Step 3. Name reviewers before you add seats. Every new agent seat gets a named reviewer with protected hours. Owner: delivery lead.
- Step 4. Automate the mechanical checks. Code Analyzer, Apex tests, and linting run in CI on every pull request, before a human sees it. Owner: Salesforce platform owner.
- Step 5. Report shipped issues, not lines. Retire lines-of-code and commit counts from the agent business case. Owner: CIO.
We move this to WATCH if a peer-reviewed version shows defect rates rising with adoption. We drop the review caveat when someone shows AI review tools bringing merge time back to baseline.
Frequently asked questions
Do AI coding agents make developers more productive?
They make developers write more. In the Harvard study of 718 firms, agents added 30% more code, 20% more commits, and 23% more pull requests per engineer, but Jira issues resolved did not rise significantly. Output rose; finished work did not.
Why does more code not mean more shipped software?
Review. Time from pull request to merge rose 49%, from 7.03 to 10.48 days, and the share sent back for changes nearly doubled, from 13% to 25%. On our arithmetic, pull requests waiting in review rise 83% per engineer.
Should we stop buying coding-agent licences?
No. Pilot them with review capacity budgeted alongside the seats, automate mechanical checks in CI, and measure shipped issues rather than lines of code. The bottleneck is the review queue, not the agent.
Living page. Last updated 13 Oct 2026. What would change our call: a peer-reviewed version reporting defect rates, or evidence that AI review restores merge time.