Zuse Runs 20 Linear Issues in Worktrees

Zuse One agent coordinating 20 Linear issues in worktrees is Swaraj Bachu’s Show HN project for an open source workspace that lets a lead coding agent fan out work across separate Git worktrees. It deals with the awkward question behind agentic coding: what happens when agents stop doing one task at a time and start producing a stack of reviewable changes at once? The answer is not “merge faster”; it is “make the parallel work easy to isolate, test, inspect, and reject.” Zuse is a workspace for running coding agents in separate workspaces so their changes can be reviewed before they touch the main branch.

For Cursor users, the interesting part is less the leaderboard number and more the shape of the workflow. Cursor, Anysphere’s AI code editor, already gives developers an agentic loop inside the IDE; Zuse points at a wider pattern where one coordinator creates many isolated attempts and the human reviews the outputs with code review guardrails. That makes it a useful story for anyone following agentic coding governance, even if you never run this exact project.

See what Zuse actually ran

The author’s demo gave one lead agent 20 Linear issues. That agent created separate workspaces, started a different coding agent in each one, and let each agent make changes, run tests, test the app in a browser, and take screenshots.

The reported result was 18 completed issues in about two hours, with two needing human help. The important detail is that the author reviewed every result before merging anything.

That is why developers cared. The demo was not just “AI wrote code.” It was a small production-shaped experiment in parallelism, isolation, and human review.

The trap is reading the number as the product. Eighteen of 20 sounds impressive, but the safer question is what the review surface looked like: diffs, test logs, screenshots, failing cases, and clear branch boundaries.

Notice the worktree trick

A Git worktree is a second working directory attached to the same repository, so different branches can be checked out side by side without copying the whole repo. For coding agents, that is a neat boundary: one issue, one branch, one filesystem, one set of test results.

This removes a boring but real blocker. If you ask five agents to edit the same checkout, they can stomp on each other’s files, confuse local build state, and leave you with a mystery diff. Worktrees make the unit of review match the unit of work.

A realistic example is a repo with three small Linear tickets: “fix empty state copy,” “add API timeout handling,” and “update billing banner test.” In a worktree model, each issue gets its own branch and local app run. The reviewer can open each branch, run the same command, and compare the result without untangling three unrelated edits.

The trap is assuming isolation solves correctness. It solves collision. You still need tests, screenshots for UI work, and a human who knows whether the issue was the right issue to solve.

Review the pile before you merge it

The hard part in a Zuse-style run is not starting 20 agents. It is reviewing 20 finished-looking answers without getting tired and rubber-stamping the middle ten.

A good review receipt should be boring. For each issue, you want the branch name, linked Linear issue, changed files, test command and result, browser check if relevant, screenshots if UI changed, and a short “what I changed” note. If that receipt is missing, the work is not ready; it is just a branch with confidence theater around it.

This maps cleanly to Cursor workflows. You can keep the review in the IDE, inspect diffs branch by branch, ask Cursor Agent to summarize the local change, then verify the summary against the code instead of trusting it. Cursor’s agent is useful here because it can help navigate and explain a patch, but the merge decision should stay boringly human.

The trap is asking another agent to approve the first agent without adding evidence. An agent can help find risk. It should not become the only reviewer of agent-authored code.

Use MCP for context, not blind write access

Zuse’s demo centers on Linear issues, which is exactly the kind of external context coding agents need. In a Cursor repo, you might connect issue trackers, GitHub, docs, or internal systems through an MCP server.

Model Context Protocol is an open protocol for connecting AI applications to external tools and context. The useful pattern is read-first: let the agent fetch the issue, linked docs, and maybe recent PRs before you let it write comments, move tickets, or mutate production systems.

If you are experimenting with this style, make the first integration boring. Read Linear issue text. Read repository files. Write only to a branch. For more on where this integration layer is headed, see New MCP Roadmap for Agent Integrations.

The trap is giving a parallel worker the same permissions as a trusted developer. Twenty agents with broad write access is not productivity; it is a blast radius with a progress bar.

Try it when the work is small and separable

This pattern fits bugs and chores that can be described with a tight acceptance check. UI copy fixes, small test repairs, typed API edge cases, lint cleanup, and narrow component changes are good candidates.

It is overkill for vague architecture work. If the issue starts with “rethink,” “design,” “migrate,” or “investigate,” parallel agents may create more review work than implementation work. A senior developer should shape the problem first.

It is also a bad fit when your repo has expensive local setup, flaky tests, or hidden runtime dependencies. Parallelism amplifies whatever is already painful. If one local test suite is unreliable, 20 agent runs will mostly produce 20 versions of the same doubt.

The practical lesson from Zuse is simple: do not scale autonomy before you scale review evidence. Worktrees make the work separable; they do not make it safe by themselves.

Try it safely in a Cursor repo

Use this as a small experiment, not a ceremony. Pick three issues, not 20. Make the goal to learn what a good review receipt looks like.

Create a Cursor rule that tells the agent what evidence to leave behind:

---
description: Review boundary for parallel agent worktrees
globs:
  - "**/*"
alwaysApply: false
---

# Parallel agent review boundary

When working on an issue in an isolated branch or worktree:

- Keep the change scoped to one issue.
- Do not edit unrelated files to "clean up" nearby code.
- Run the narrowest relevant test command and record it.
- For UI changes, include the route tested and attach before/after screenshots when available.
- Leave a short handoff note with: issue link, files changed, test result, known risk, and follow-up needed.
- Do not merge, rebase main, change secrets, or modify deployment settings.

Then review each branch with the same checklist:

• Does the diff match the issue, or did it wander?
• Is there a passing test or a clear reason no test applies?
• Did the agent verify the app path a user would hit?
• Are generated files, lockfiles, and migrations expected?
• Can you revert this branch without touching the others?

The trap is making the checklist aspirational. If an agent cannot produce the receipt, shrink the task until it can.

Common questions

• Is Zuse replacing Cursor Agent?

  No. Zuse is better understood as a workspace pattern for coordinating multiple coding agents, while Cursor Agent is the in-editor agent experience inside Cursor. The overlap is the workflow: isolated task execution, local inspection, and human review before merge.

• Why use worktrees instead of separate clones?

  Worktrees give you separate working directories without duplicating the whole repository history. The practical benefit is speed and clarity: each issue can live on its own branch, while the reviewer still knows all changes belong to the same repo.

• Should I try 20 issues at once?

  Probably not at first. Start with three small, independent issues and measure review time, test reliability, and how many handoff notes are actually useful. Zuse’s reported 18-of-20 result is interesting because the author still reviewed everything before merging.

• Where does MCP fit in this workflow?

  MCP fits when agents need external context, such as issue text, docs, repository metadata, or design references. Keep early MCP servers read-only where possible, because parallel agents multiply permission mistakes as quickly as they multiply useful patches.

• What is the biggest risk in parallel agentic coding?

  The biggest risk is review collapse. When many branches arrive at once, humans can start approving by vibe instead of evidence. A short receipt per branch is the difference between useful developer productivity and a confusing pile of plausible diffs.

Best ways to use this research

• Best for: Developers experimenting with agentic coding on small, independent issues where branch isolation and review receipts are more important than raw speed.
• Best first artifact: A Cursor .mdc rule that forces every agent branch to include scope, test result, UI evidence when relevant, and known risk.
• Best comparison angle: Compare one-agent-one-issue work against one-lead-agent-many-worktrees work, using review time and revertability as the main metrics.
• Best safety line: Let agents create branches and evidence before you let them mutate tickets, deployment settings, secrets, or shared environments.

Further reading

• Zuse One agent coordinating 20 Linear issues in worktrees — source
• Zuse — GitHub repository
• Cursor — Agent
• Model Context Protocol — specification
• Linear — developers

Next step

Try the pattern with three low-risk issues and require a review receipt for each branch. If the receipts are useful, scale the number of parallel worktrees slowly; if they are not, fix the boundary before adding more agents.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.