Thirty percent more lines of code. Twenty percent more commits. Twenty-three percent more pull requests. And no statistically significant change in the rate firms resolved their Jira issues and epics. Those are the headline numbers from a study by Harvard's Fiona Chen and James Stratton, which Ars Technica wrote up on Friday: 300 million work events from more than 700,000 engineers at over 700 firms, measured before and after each one brought in AI coding agents.

The code went somewhere. It went into review. Time from pull request to merge grew 49%. The share of PRs sent back for changes nearly doubled, comments per PR rose 35%, and the share of workers doing reviews rose 14%. The authors put it plainly:

The code review process significantly increases in length, pull requests are more likely to require revisions, and reviewers leave more comments.
Ars Technica, quoting Chen and Stratton

None of this should surprise anyone who has read Eli Goldratt's The Goal. On a Boy Scout hike, the troop moves at the pace of Herbie, the slowest kid, no matter how fast the kids up front can walk. Speed them up and all you get is a longer gap in the line. In a factory that gap is inventory. In a software org it's a queue of open pull requests. Coding agents made the fast kids faster. Nobody sped up Herbie.

The tempting read is that review is slow because reading is slow, and the next model fixes reading. The data says otherwise. By March, 80% of the firms in the sample used some form of AI code review, and agents still wrote only 23.3% of review comments. The tools were there. The work stayed with people, and for the right reason: review is the step where a human agrees to own the change. A bot comment can flag a bug. It can't be the person paged at 3 a.m. for the merge. Every line an agent writes is a line someone has to be willing to sign for, and signing doesn't parallelize the way typing does.

Coding agents made the fast kids faster. Nobody sped up Herbie.

The strongest objection is time. The data stops in March 2026, agents have improved since, and an agent whose code reviewers trust on sight would shrink the queue on its own. Grant it: better agents will cut the share of PRs sent back. But the mechanism the study found doesn't depend on agent quality. Agent output is measured in code; reviewer capacity is measured in hours of attention. Make generation cheaper and teams generate more, so a better agent lands more code on the same reviewer, and the queue grows faster. Improving the step that isn't the constraint is how these firms got here.

Goldratt's fix wasn't a faster Herbie. It was to put Herbie at the front of the line, tie everyone else to his pace, and lighten his pack. For a team running agents that translates directly. Release agent work at the rate review can absorb it, not the rate the agent can produce it. Then spend the spare agent capacity making each change cheaper to judge: smaller diffs, tests that state the intent before the implementation, a written reason for the change that a reviewer can check in two minutes instead of reconstructing in twenty. That is the work that moves the constraint, and none of it shows up as more lines of code.

Thirty percent more code and the same number of tickets closed isn't a failed tool. It's a working tool aimed at the wrong station. The order was never for code. It was for software, and software ships at the speed of whoever signs for it.