The AI code review bottleneck is becoming the defining problem of agentic software development. A recent experiment involving one lead coding agent, 20 real issues, and isolated Git worktrees shows that implementation can now scale faster than a developer’s ability to confidently understand, test, and merge the results.

The important lesson is not that autonomous agents can complete a long backlog. It is that parallel code generation changes where engineering time goes. When several agents finish at once, the scarce resource becomes human judgment: deciding whether a change is correct, safe, compatible with the rest of the system, and worth merging.

A 20-Issue Experiment That Exposed the Real Constraint

In a post on r/SaaS, Zuse creator Swaraj Bachu described giving a lead agent 20 real Linear issues simultaneously. The lead agent delegated the work to separate coding agents, each operating in its own workspace, Git worktree, and branch. The architecture was deliberately designed to avoid the most obvious danger of multi-agent programming: agents overwriting one another’s files while working on the same repository.

The reported result was striking but appropriately qualified. In roughly two hours, the system completed 18 of the 20 issues, while two needed human intervention. Crucially, none of the work was merged automatically. Instead, the developer retained the artifacts needed for a conventional engineering decision: code diffs, test results, browser testing evidence, and screenshots.

That distinction matters. “Completed” in an agent workflow should not be confused with “safe to ship.” It should mean that an agent has produced a reviewable proposed change and supporting evidence. The human is still responsible for determining whether the task was interpreted correctly, whether the implementation creates regressions, and whether a locally passing test suite is enough proof for a production merge.

The original post did not include substantive top-comment discussion at the time the source was captured. But the question it raised is widely shared: if agents can produce thousands of lines of code and multiple finished branches in a single session, how does a small engineering team keep review from becoming an unmanageable queue?

Zuse itself is positioned as a chat-first local workspace for developers using multiple coding-agent providers, with project context, terminal access, file tools, session management, and Git worktree support. Its repository also documents a practical multi-worktree problem that is easy to miss: separate app instances may need separate local user-data directories to avoid competing over a shared SQLite database or schema migrations. That is a useful reminder that workspace isolation is broader than Git isolation. (github.com)

Why Parallel Agents Change the Shape of Software Delivery

Traditional development has a relatively linear rhythm. A developer receives a task, explores the codebase, writes code, runs tests, opens a pull request, gets feedback, and merges. There are interruptions and parallel efforts, but implementation time is usually a meaningful part of the total cycle.

Agentic workflows compress that implementation phase. A lead agent can decompose a backlog into independent slices, assign each slice to a specialist agent, and let those agents run commands, edit code, test behavior, and prepare branches at the same time. OpenAI now explicitly describes Codex as supporting multi-agent workflows with worktrees and parallel execution, reflecting how quickly this pattern has moved from an experiment to a product design principle. (openai.com)

The gain is real only when the work is sufficiently separable. Twenty tasks that touch entirely different modules, pages, tests, or documentation files may proceed concurrently. Twenty tasks that all modify a shared authorization layer, schema, build configuration, or design system are not truly independent just because they have separate branches.

This produces a new delivery equation:

  1. Agent throughput increases the number of proposed changes.
  2. Isolation reduces direct file collisions during implementation.
  3. CI and automated checks filter out simple failures.
  4. Human review capacity determines how much of that output becomes trusted product work.
  5. Integration capacity determines whether individually valid changes still work together.

The first two stages are increasingly easy to accelerate. The last three are not. A team that doubles generation speed without redesigning review, test, and merge processes can simply move its queue downstream.

Google’s 2025 DORA research frames AI as an amplifier rather than an automatic productivity machine. Based on survey responses from nearly 5,000 technology professionals and more than 100 hours of qualitative research, DORA’s core argument is that AI magnifies the strengths and weaknesses already present in an organization’s delivery system. A team with weak tests, unclear ownership, giant pull requests, and slow deployment feedback will likely experience those weaknesses at higher volume. (services.google.com)

Git Worktrees Are a Safety Primitive, Not Just a Convenience

The technical backbone of the experiment was Git worktree isolation. Git worktrees allow a single repository to have multiple working directories, each checking out a different branch, while sharing the underlying repository data. In practical terms, an agent can work in one directory on a feature branch while another agent works in a second directory on a bug fix, without either agent constantly switching branches or trampling uncommitted local edits. (git-scm.com)

For multi-agent coding, that gives teams three immediate advantages.

1. File-system separation

Separate worktrees prevent one agent from editing a file that another agent has open in its own working directory. This does not eliminate eventual merge conflicts, but it prevents the much worse failure mode of concurrent, invisible mutation in a shared checkout.

2. Reproducible task environments

Each agent has a concrete branch and working directory associated with the task. A reviewer can inspect the exact state the agent tested rather than reconstructing what happened after subsequent changes altered the main workspace.

3. Better cleanup and rollback

An unhelpful agent attempt can be discarded by removing its branch and worktree. That is far safer than attempting to untangle an unknown series of local edits in a shared directory.

However, worktrees are not a substitute for coordination. They isolate writes, not meaning. Two agents can independently make sensible changes that encode conflicting assumptions: one may rename an API field while another introduces a consumer for the old field; one may add a migration while another changes the model semantics; two agents may update a shared snapshot in incompatible ways.

That is why a good multi-agent system should identify shared surfaces before delegation. It needs a map of high-risk files and domains: database schemas, lockfiles, dependency manifests, infrastructure configuration, authentication, authorization, API contracts, shared UI primitives, and deployment pipelines. Those areas should usually be serialized, assigned to a single owner, or treated as explicit integration tasks.

The AI Code Review Bottleneck Is About Judgment, Not Reading Speed

It is tempting to describe the problem as “too many lines of code to review.” That is true but incomplete. The true cost of review is not scrolling through a diff. It is rebuilding enough context to answer questions the diff cannot answer on its own.

A reviewer needs to know:

  • Does this change solve the actual product problem described in the issue?
  • Did the agent choose a design consistent with existing architectural conventions?
  • Does the test verify meaningful behavior, or merely confirm the implementation’s own assumptions?
  • What happens under invalid input, concurrency, partial failure, degraded dependencies, and permission boundaries?
  • Does the change interact badly with other branches likely to merge soon?
  • Is the code understandable enough that the next human can operate and modify it?

An agent can generate plausible answers to these questions, but it cannot remove the accountability requirement. In a production codebase, someone ultimately needs to own the risk decision.

This is why screenshots and browser tests in the Zuse experiment are useful but insufficient. A screenshot proves that a particular UI state rendered at a particular time. It does not establish that the state is reachable under the right permissions, that the data is durable, that analytics remain accurate, that responsive behavior works, or that the change does not violate an accessibility requirement.

Likewise, a passing test suite is evidence, not a verdict. Tests may be incomplete, brittle, incorrectly scoped, or written by the same agent that made the implementation. The most dangerous outcome is not an obvious failing test. It is a clean-looking pull request that has enough evidence to encourage premature trust while missing the exact behavior that matters.

Why “No Automatic Merge” Was the Right Design Choice

The experiment’s most mature decision was refusing to merge agent work automatically. With 18 of 20 issues apparently completed, it would be easy to treat the agent run as a pipeline that should end in a batch merge. That would turn speed into risk.

Pull requests exist to create a deliberate decision point between changing code and integrating code. GitHub describes pull requests as proposals to merge changes where collaborators can discuss and review work before it enters the project, helping teams catch problems early and preserve quality. That workflow is even more important when the author is an autonomous agent rather than a teammate who can explain every tradeoff from memory. (docs.github.com)

The right goal is therefore not “hands-off merging.” It is high-confidence, low-friction human approval. That changes how teams should configure agents.

Instead of asking an agent to “fix issue 412,” ask it to produce a compact review package:

  1. A one-paragraph explanation of the user-facing problem and acceptance criteria.
  2. A list of files changed, grouped by purpose.
  3. The key design decision and alternatives considered.
  4. Commands run, their output status, and tests added or modified.
  5. A browser or API verification record where appropriate.
  6. Known limitations, assumptions, and areas the agent could not verify.
  7. A short reviewer checklist tailored to the change.

This turns an opaque code dump into a decision-ready artifact. It also gives reviewers a fast way to spot whether the agent actually understood the task before they read every changed line.

Build a Review Funnel Instead of a Review Pile

If five agents finish within ten minutes, sending all five raw diffs to a senior engineer creates a review pile. The answer is a funnel: cheap, automated checks should reject or classify work before expensive human attention is required.

A practical funnel has four layers.

Layer one: task quality before execution

The lead agent or human planner should reject vague tickets before delegation. A task needs a clear problem statement, acceptance criteria, affected area, and a definition of done. “Improve onboarding” is not a safe autonomous task. “Add an empty-state message when a user has zero campaigns, with copy approved in the ticket and a Playwright assertion for the state” is much safer.

Layer two: agent self-verification

The agent should run targeted checks, not merely claim success. That can include formatting, static analysis, unit tests, type checking, a focused integration test, and browser verification for user-interface changes. Agents should state precisely what they ran and what they could not run.

Layer three: independent automated gates

CI should rerun critical checks in a clean environment. This matters because local agent environments may have cached dependencies, uncommitted setup, secrets, or database state that does not exist elsewhere. Add dependency scanning, secret detection, linting, test shards, and policy checks appropriate to the repository.

Layer four: human review based on risk

Humans should not spend equal time on every branch. A typo correction in a static page and a permission change in a billing workflow deserve radically different scrutiny. Route changes by blast radius, not by the fact that AI wrote them.

For transactional email systems, for example, agent-authored changes that affect sender identity, suppression behavior, webhook handling, template rendering, or retry logic should be considered high risk because small errors can affect deliverability, compliance, or customer communications. Teams building delivery features should document those boundaries as clearly as they document their email API setup guides.

A Risk Model for Reviewing Agent-Generated Changes

The simplest way to prevent review overload is to make review effort proportional to risk. A useful model uses four dimensions: impact, uncertainty, coupling, and reversibility.

Impact

What happens if the change is wrong? Cosmetic text, internal tooling, and isolated documentation are typically lower impact. Authentication, payments, privacy, production data deletion, outbound messages, and access control are high impact.

Uncertainty

How confident are you in the task specification and the available tests? A well-defined bug with a reproduction case has lower uncertainty than a request that depends on undocumented product behavior or ambiguous stakeholder intent.

Coupling

How many other systems, modules, users, or branches does the change touch? A self-contained component is easier to review than a modification that changes a shared library, database schema, API contract, or deployment configuration.

Reversibility

Can the change be rolled back safely? A feature flag can lower risk. A destructive migration, irreversible external side effect, or customer-facing email blast raises it substantially.

Use these dimensions to create simple policies:

  • Low risk: Agent can prepare the branch, run checks, and request a lightweight review.
  • Medium risk: Require an independent test or reviewer, plus a staged rollout if relevant.
  • High risk: Require a human-written plan, limited agent scope, multiple approvals, and explicit rollout and rollback procedures.
  • Critical risk: Do not delegate open-ended implementation. Use agents for research, test scaffolding, or tightly controlled edits only.

This framework also helps founders avoid a common mistake: treating an agent-generated diff as lower cost because it arrived quickly. Code may be cheap to produce, but a mistake in a high-impact domain is not cheap to discover or repair.

Smaller, Dependency-Aware Changes Beat Giant Agent Batches

The 20-issue result is compelling because it demonstrates throughput. But the production workflow should not be “run 20 agents, then review 20 giant branches.” A batch of independent tasks can still create an integration mess if every branch is based on a slightly older view of main.

The better approach is to combine concurrency with dependency ordering. Before agents start, classify work into:

  • Independent tasks: Can proceed in parallel with separate branches.
  • Foundational tasks: Must land first, such as schema additions, shared types, or reusable APIs.
  • Dependent tasks: Can be prepared early but should be rebased and validated after their prerequisite merges.
  • Contentious tasks: Touch shared files or business rules and should be serialized.

GitHub’s own guidance emphasizes that breaking work into small, logical, dependency-ordered changes makes review more accurate as well as faster. That applies particularly well to agent output: reviewers can reason about one coherent intent at a time instead of reconstructing a sprawling automated implementation. (github.com)

There is a subtle tradeoff here. More branches mean more coordination overhead. Fewer, larger branches mean more reviewer cognitive load and more painful merge conflicts. The best batch size depends on your codebase and test maturity, but the principle is stable: optimize for the smallest independently releasable unit that has a clear owner and a verifiable outcome.

How to Make Agent Diffs Easier to Review

Review acceleration does not begin with buying an AI review product. It begins by making the author—human or agent—produce better evidence and better-structured changes.

Require an intent-first pull request description

The pull request should lead with what changed in product terms, not a file list. A reviewer needs to understand the desired behavior before interpreting implementation details.

A useful template is:

  • Problem: What user or operational issue exists?
  • Approach: What was changed and why?
  • Behavioral proof: What test or manual flow demonstrates success?
  • Non-goals: What was intentionally not changed?
  • Risk and rollback: What could fail, and how would the team recover?

Make test evidence inspectable

“Tests pass” is weak evidence. Better evidence identifies the exact test command, relevant test cases, changed coverage, and whether the test would have failed before the implementation. For visual work, add before-and-after screenshots and state the viewport, account state, and browser context used.

Ask agents to annotate unusual code

If an agent introduces a cache, a retry policy, a migration, a feature flag, a regex, or a non-obvious performance choice, require a short comment in the pull request explaining why. The goal is not to justify every line; it is to expose the places where reviewers should slow down.

Separate mechanical changes from behavioral changes

Formatting, generated files, dependency updates, refactors, and behavior changes should not be mixed without a compelling reason. Mechanical noise makes it harder to spot semantic risk. If an agent needs to refactor to make a feature possible, ask it to create a separate prerequisite branch.

Use AI as a second reader, not a final authority

A second model or agent can summarize the diff, compare it to the ticket, flag missing tests, trace data flow, and generate questions for the reviewer. That is valuable triage. But it should not be considered independent assurance when it shares the same incomplete requirements, repository context, or blind spots as the implementing agent.

The best pattern is adversarial specialization: one agent implements, another attempts to find regressions or requirement mismatches, and a human makes the merge decision. The review agent should be prompted to disprove the implementation, not merely praise it.

The Hidden Integration Problems Worktrees Do Not Solve

Worktrees eliminate one class of concurrency problem, but they can create a false sense of safety if teams stop there. The branches remain logically coupled through the main branch they will eventually join.

Consider a simple example. Agent A adds a new required field to a shared TypeScript type. Agent B builds a UI flow that assumes the field is optional. Agent C changes a backend endpoint that returns the old shape. Every agent might pass its focused tests in isolation. The integration failure appears only when the changes are merged, ordered, and deployed together.

To manage this, establish an integration queue and treat it as a first-class stage of agentic development. Before merging a set of related changes, run a fresh test suite against the intended combined state. For complex feature work, create an integration branch or temporary environment where multiple approved branches can be validated together before any reaches production.

This is also where branch freshness matters. An agent that began work two hours ago may have made technically sound changes against an outdated base. Require a rebase or merge-from-main step followed by rerunning relevant tests before final approval. Agent systems should be able to do this automatically, but the reviewer should see that it happened.

What Founders and Small Teams Should Do This Week

You do not need a bespoke multi-agent platform to benefit from the insight behind the Zuse experiment. The immediate opportunity is to redesign the handoff between generation and review.

Start with a narrow pilot: five low-to-medium-risk tickets that are genuinely independent. Use worktrees or separate clones, one branch per task, and a fixed pull request template. Measure not only coding time, but the time from agent completion to merge, the number of review rounds, the number of changes rejected, and any regressions found after merge.

Then implement these operating rules:

  1. No direct agent merges to production branches. Protect main and require checks.
  2. One ticket, one outcome, one branch. Avoid broad “cleanup” assignments.
  3. Every branch needs a review packet. Include intent, evidence, limitations, and rollback notes.
  4. Risk-route the review. Spend senior attention where incorrect code would be costly.
  5. Make CI the first reviewer. Automate objective checks before humans inspect behavior.
  6. Measure review latency. If agents finish faster than reviews clear, do not add more concurrent tasks yet.
  7. Feed review findings back into agent instructions. Repeated feedback about tests, error handling, architecture, or style belongs in repository guidance, not in endless one-off comments.

Repository-level instructions are particularly important as agent use grows. OpenAI’s Codex guidance recommends project-level AGENTS.md files to give agents persistent context about setup, conventions, test commands, dependency rules, and working agreements. That is an effective way to reduce avoidable review findings before a branch is ever opened. (learn.chatgpt.com)

For teams that operate customer-facing messaging, it is also worth documenting which changes can affect cost, compliance, or delivery performance. Clear internal rules around provider behavior and transactional email pricing make it easier for agents and reviewers alike to recognize when a seemingly small implementation has business consequences.

The Strategic Shift: Optimize for Trusted Throughput

The central takeaway from this experiment is not “one agent can handle 20 tickets.” Results will vary widely by task quality, repository maturity, model capability, test coverage, and the degree of hidden coupling in the work.

The stronger lesson is that code generation is no longer the only—or even primary—constraint for many software teams. Once agents produce multiple candidate changes in parallel, the important metric becomes trusted throughput: the rate at which a team can turn proposed code into verified, integrated, reversible product improvements.

Trusted throughput is a system property. It depends on clear tickets, repository instructions, worktree isolation, reliable tests, clean CI, risk-based review, small changes, deployment controls, and fast feedback from production. Adding more agents without those elements may increase activity while decreasing confidence.

Zuse’s experiment is valuable precisely because it does not claim to have solved the final step. The agent run produced a large amount of work, but the creator identified review as the hard part. That is the honest state of agentic engineering today. The next wave of advantage will go not only to teams that can ask agents to write more code, but to teams that can review, integrate, and learn from that code faster without lowering their standards.

FAQ

What is the AI code review bottleneck?

The AI code review bottleneck occurs when coding agents generate proposed changes faster than people and existing quality systems can verify, approve, integrate, and safely release them. The constraint moves from implementation capacity to trusted decision-making capacity.

Are Git worktrees necessary for parallel coding agents?

They are not the only option, but they are a practical and lightweight way to give agents separate working directories and branches within one repository. They reduce direct local-edit conflicts, though they do not eliminate semantic conflicts or integration work.

Should coding agents be allowed to merge pull requests automatically?

For low-risk, highly tested changes, teams may eventually automate limited merges behind strict policies. But a default human approval step is safer for most production repositories, especially for changes involving security, payments, data, permissions, infrastructure, or customer communications.

How can teams speed up reviews of agent-generated code?

Start with smaller task scopes, task-specific acceptance criteria, automated checks, evidence-rich pull request templates, risk-based routing, and a separate agent that critiques the implementation. The goal is to reduce the human effort needed to understand intent and locate meaningful risk.

Does passing tests mean an agent change is safe to ship?

No. Passing tests are valuable evidence, but they only prove what the tests cover. Reviewers still need to assess requirement fit, edge cases, operational behavior, security, integration with adjacent changes, and the ability to roll back if something goes wrong.