AI Coding Has Moved the Traffic Jam to Pull Requests

AI coding tools have solved a real and useful problem: there is now less time between “I know roughly what needs changing” and “here is a diff with 19 files, a migration, three tests, and an unsettling confidence in its own README.” That is progress. It is also how many teams discovered that their delivery system was a one-lane bridge staffed by people who are, inexplicably, in meetings.

The old limit was authoring throughput. The new limit is everything after git push: finding the right reviewer, establishing that a 900-line agent-generated diff has a coherent intent, waiting for CI, reconciling with the five other changes pointed at main, and discovering that the one test named does_not_flake has chosen today for self-expression. Software does not ship at the rate code is produced. It ships at the rate the slowest shared constraint can absorb change.

The pull request is now the on-ramp

This is not an argument to ban agents, which would be the organizational equivalent of responding to traffic with a stern memo about walking. It is an argument to treat agent output as incoming traffic. If an agent lets each developer produce twice as many merge-ready-looking changes, while the review and integration system remains the same, the backlog has merely become better formatted.

GitHub’s branch protections make the constraint visible. A protected branch can require approvals, status checks, resolved conversations, deployments, code-owner review, and a merge queue. Those controls are often correct. They also mean a harmless-looking follow-up commit can invalidate prior approval when stale-review dismissal is enabled. The code got faster; the state machine did not become sentimental about it.

The practical question is not “does the agent save keystrokes?” It plainly can. Ask instead: “What happens in the 30 minutes after the agent finishes?” If the answer is “someone eventually notices the PR,” your shiny new throughput is depositing cars directly into a roundabout with no exits.

Measure the wait, not just the writing

Start with one queue you can see from a terminal. This lists open PRs whose checks are successful but whose review is still required:

gh pr list --search "status:success review:required" \
  --json number,title,createdAt,url \
  --jq '.[] | "#\(.number)  \(.createdAt)  \(.title)"'

Run it at 10:00 and 16:00 for two weeks. Count the same PR twice if it is still there. That is not statistically elegant, but neither is a customer waiting for a one-character configuration fix because its reviewer has 14 “quick ones.” Then pull createdAt and mergedAt for merged work and calculate median and p90 time to first review and time to merge. Do not begin with lines of code. Agent-generated diffs make that number feel productive while giving reviewers an archaeological dig.

Set an explicit initial-response target of 600 seconds during a rotating review block. “Initial response” can be an approval, a useful comment, or “I cannot review this safely; please route it to the payments team.” It does not mean everyone must perform an instant, ceremonial thumbs-up from a phone in a grocery aisle. The point is that a PR should enter a known state quickly instead of becoming office furniture.

Reduce review surface before adding review automation

The most effective agent setting may be a social one: one active review-ready PR per developer, with extra agent work kept as local branches, drafts, or issues. This sounds annoyingly managerial until you compare it with having eight incomplete reviews per person, which is managerial too, just with more browser tabs.

• Ask the agent for a plan and a file list before asking for edits. If the plan touches auth, billing, API contracts, and CSS, it is probably not one review.
• Use a 250-line changed-code guideline as a prompt to split work, not a reason to play line-count golf. Generated snapshots, lockfiles, and migrations need different handling.
• Require the PR description to state the user-visible behavior, the rollback path, and the tests actually run. “Agent generated this” is not a test strategy; it is an incident report written early.
• Create draft PRs when you want architecture feedback. GitHub does not automatically request code-owner reviews for draft PRs, which prevents specialists from being paged for an experiment that may still be deleted before lunch.

CODEOWNERS is useful routing, not an accountability piñata. GitHub can automatically request owners when owned files change, and protected branches can require their approval. That is valuable for narrow, genuinely risky areas. Making a seven-person platform team owner of half the repository is how every small agent change becomes a group project with the emotional texture of airport security.

Make integration a system, not a raffle

Once review is moving, main becomes the next bottleneck. A merge queue is worth considering for a busy branch because it validates a PR against the latest target branch and changes already ahead of it, then merges only when required checks pass. This prevents the familiar sequence where six individually green PRs create one collectively red afternoon.

It is not magic. A merge queue cannot redeem a 28-minute test suite, a nondeterministic end-to-end job, or a CI bill that makes concurrency politically unavailable. It can also make failure reproduction more confusing because CI is testing a temporary merge group rather than the branch you were lovingly staring at five minutes ago. GitHub exposes build concurrency from 1 to 100; choose it according to runner capacity and actual test duration, not because 100 has a comforting three digits.

If you use GitHub Actions for required checks, add the merge_group trigger. Otherwise the queue can wait for a required workflow that never runs, which is a surprisingly efficient way to prove that software delivery remains a socio-technical system.

on:
  pull_request:
  merge_group:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./ci/test

The useful division of labor

Let the agent make implementation cheap. Spend the saved time making intent, review, and integration cheap too. Use it to prepare a small diff, summarize changed behavior, identify tests, and address predictable comments before a human sees the work. Do not use it to manufacture a larger pile of “ready for review” badges than your team can responsibly inspect.

A healthy result is not that every developer opens more PRs. It is that the oldest ready PR is boringly young, reviewers know which change needs their attention, CI answers promptly, and the merge queue behaves like plumbing rather than a municipal planning meeting. AI can make the on-ramp wider. Somebody still has to build the road.