AI Can Write More Code Without Shipping Much More Software. Fix the Bottleneck After the PR

The useful takeaway is not that AI coding tools fail. It is that speeding up code generation can expose a slower part of the system. If developers can produce changes much faster but review, integration, release, and product validation still move at roughly human speed, the queue simply moves downstream.

That is the important result behind new research highlighted by MIT Sloan on September 2, 2026. The researchers studied activity from more than 100,000 GitHub developers using multiple generations of AI coding tools. MIT Sloan reports that coding activity rose substantially — up to a cumulative 180% with the broader mix of autocomplete, synchronous agents, and asynchronous agents — while the increase in actual software releases was much smaller.

For engineering teams, the practical question is therefore no longer just “How much faster can the model write code?” It is “Where does work wait after the model has written it?”

Research check: September 2, 2026. The figures below summarize the study as reported by MIT Sloan and the researchers' working paper. They describe measured effects in the study population, not a guaranteed productivity gain for every team or tool.

The new productivity problem is a funnel

The paper, Writing Code vs. Shipping Code — Productivity Effects Across Generations of Coding Tools, follows work through a software-production hierarchy rather than stopping at lines of code or commits.

MIT Sloan summarizes the stages as:

1. writing code;
2. organizing code into files;
3. committing changes;
4. submitting pull requests;
5. merging changes;
6. releasing finished software.

That framing is much closer to how software creates value.

A team can double the amount of code it produces and still disappoint customers if the additional work sits in review, fails integration, waits for a release window, or ships features nobody needs.

According to MIT Sloan's summary, autocomplete tools increased coding activity by about 40%. The cumulative effect with synchronous agents reached about 140%, and adding asynchronous agents pushed coding activity as high as 180%. Yet the boosted coding work was associated with roughly 50% more projects and 30% more actual releases compared with developers who did not use AI tools in the study.

Those are still meaningful gains. They are simply much smaller at the end of the production chain than at the beginning.

Why faster coding can make a team feel slower

Imagine a five-person team that used to open 20 meaningful pull requests a week and comfortably review 20.

AI assistance lets the same team open 35.

The review capacity has not changed. The team now has 15 extra changes waiting for attention. Engineers switch context more often, stale branches need rebasing, reviewers face larger queues, and the apparent speedup can create more unfinished work.

The model did its job. The system did not expand with it.

This is a classic constraint problem: once one stage gets faster, the bottleneck moves.

For many AI-heavy teams, that bottleneck is likely to sit in one of five places:

• deciding what should be built;
• reviewing generated changes;
• running integration and quality checks;
• merging and deploying safely;
• learning whether the shipped feature helped a user.

The mistake is buying another coding agent before identifying which of those is actually limiting throughput.

Stop using commits as the main AI productivity metric

Commits, lines changed, and pull-request counts are easy to measure. That is exactly why they can become dangerous targets.

A better dashboard follows the work all the way to a useful outcome.

You do not need a perfect analytics platform. A few timestamps from GitHub and CI can expose most of the queue.

A simple “where did the speedup go?” audit

Run this for two normal weeks before changing the tooling again.

1. Measure lead time in chunks

For a representative sample of changes, record:

• task started → PR opened;
• PR opened → first review;
• first review → merge;
• merge → production;
• production → first useful product signal.

Then calculate what share of total lead time is waiting, not active work.

If AI has already compressed the first interval but the second interval dominates, the next investment should probably target review capacity — not generation speed.

2. Count work in progress

Track open PRs and stale PRs rather than celebrating PR creation alone.

A growing queue is the clearest sign that upstream productivity is outrunning downstream capacity.

One useful rule is deliberately boring: cap concurrent AI-generated work. An agent that can start ten tasks does not mean a team should have ten tasks waiting for human judgment.

3. Separate review time from repair time

A PR can wait because nobody looked at it, or because it needed six rounds of correction. Those are different bottlenecks.

Measure both:

• time waiting for a reviewer;
• number of review/repair loops before merge.

The first points toward staffing, ownership, or workflow design. The second points toward task specification, test coverage, model routing, or code quality.

4. Track releases, not just merges

A merge is not customer value.

If merged work waits days for a manual release process, the constraint has moved one stage further right. Automating release notes, smoke tests, environment checks, rollout gates, and rollback preparation may produce more real throughput than asking the coding model to be 10% faster.

Four changes that are worth testing before adding more agents

Make AI-generated PRs smaller

When code is cheap to produce, the natural failure mode is oversized changes.

Smaller PRs reduce reviewer load, shorten feedback loops, make failures easier to isolate, and lower the cost of rejecting a bad approach. An agent should be able to split work into reviewable units rather than treating “more code in one run” as success.

Put AI on the downstream chores too

Many teams automate implementation but leave the rest of the pipeline untouched.

Good candidates for assisted automation include:

• summarizing a diff for a reviewer;
• generating targeted test cases;
• checking a change against an acceptance checklist;
• preparing release notes;
• triaging CI failures;
• drafting rollback steps;
• grouping related review comments;
• identifying files that deserve a human specialist's attention.

The goal is not to remove accountable review. It is to reduce the mechanical work surrounding the judgment.

Give reviewers an explicit service level

If every developer is generating more changes, “someone will review this when they have time” stops scaling quickly.

A rotating reviewer, a daily review window, or ownership by code area can be enough. The exact process matters less than making review capacity visible and intentional.

Delete more generated work

This is the slightly counterintuitive advantage of cheap code: throwing away a wrong approach becomes cheaper too.

The study's app-market analysis, as summarized by MIT Sloan, found more new applications after agentic coding became widely available, but not a corresponding rise in downloads or user reviews. More software supply does not create more user attention by itself.

For side projects and small teams, the better use of cheap implementation may be to run more experiments, reject weak ones earlier, and spend the saved time on product fit.

A two-week experiment for an AI-heavy team

Instead of debating whether AI “makes developers 2x faster,” test one bottleneck.

Week 1: observe. Keep the current workflow and record the five lead-time intervals, open-PR count, review loops, deploy delay, and one product outcome that matters.

Week 2: change only the constraint. If review is the queue, add smaller PR limits plus a reviewer rotation and AI-generated review summaries. If release is the queue, automate the release checklist and smoke-test handoff instead.

At the end, compare:

• median task-to-production time;
• median PR wait time;
• number of releases;
• rework or rollback rate;
• the chosen product outcome.

That gives a much stronger answer than counting generated tokens or commits.

What this means for individual developers

The durable skill is moving one level up from code production.

As implementation gets cheaper, more value shifts toward:

• decomposing ambiguous problems;
• defining acceptance criteria;
• evaluating generated work;
• understanding system interactions;
• debugging failures across boundaries;
• deciding what not to build;
• validating whether a release helped users.

That does not make coding knowledge irrelevant. It makes judgment around code more important because there is now much more code available to judge.

A developer who can generate five solutions is useful. A developer who can quickly identify which one belongs in production is harder to replace.

Conclusion

AI coding tools can produce a real productivity gain without producing an equally large shipping gain. The new research is useful because it measures the whole production chain rather than stopping where the model looks strongest.

The practical response is not to slow AI down. It is to follow the queue.

If code arrives faster, find the next place work waits. Improve that stage, measure the effect on production and users, and only then decide whether another model, agent, or subscription is the next constraint worth attacking.

The cheapest line of code is becoming less interesting. The scarce resource is increasingly the path from a plausible change to a trusted, useful release.

Sources

Checked September 2, 2026:

• MIT Sloan — AI boosts worker productivity — but does that translate to final outputs?
• NBER — Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools