Paul: Joining us is Johannes, an open-source developer and the creator of Super Productivity and Plainspace. His latest project, Parallel Code, is an MIT-licensed desktop app for coordinating CLI coding agents in isolated Git worktrees.
Passing the mic 🎙️
Ask one AI agent to fix a bug, and you get one guess, delivered with total confidence. A better model makes that guess better. It is still one interpretation of the problem, one proposed solution, and one set of blind spots.
You have probably seen this play out. You hand an agent a bug report, and ten minutes later it returns a clean, passing, 400-line diff. Only during review do you notice that it patched the symptom in the wrong layer, duplicated a helper that already existed, and quietly changed behavior nobody asked about. The obvious workaround, running several agents on the same task and picking the best result, only moves the pain: now you review three 400-line diffs instead of one. Either way, the bottleneck is the same. Generating code is cheap. Your attention, spent working out whether the code is right, is not.
For important engineering problems, a stronger workflow is:
Explore in parallel. Implement once. Review in parallel. Refine and review until the result is trustworthy.
This uses more inference, but less programmer attention. The aim is not to generate more code. It is to reach a strong solution quickly without forcing the developer to compare several complete implementations.
Explore the problem in parallel
Before writing code, several different models inspect the task and repository independently. Think of it as the first half of planning: it gathers the evidence the plan will be built on.
This is where multi-model usage provides the most value. Different model families are more likely to inspect different execution paths, favor different architectural patterns, and challenge one another’s assumptions.
Each model should return:
its understanding of the problem;
evidence from relevant files and symbols;
the proposed solution;
alternatives considered;
affected components;
risks and possible regressions;
and tests that should prove the result.
They should not edit the repository yet.
A useful prompt is:
Investigate the task independently. Do not modify the repository.
Identify:
the likely cause or core design problem,
evidence from specific files and symbols,
the smallest viable solution,
alternatives considered,
expected risks,
tests that should fail before and pass afterward.
Comparing several short proposals is much cheaper than comparing several finished implementations.
One model may propose changing persistence logic. Another may find that the actual defect is in derived UI state. A third may discover an existing abstraction that makes both changes unnecessary.
The developer or a lead agent then selects one approach, possibly combining compatible parts of several proposals.
The decision should be based on evidence:
Does it address the cause rather than the symptom?
Is the change made in the correct layer?
Is there a smaller solution?
Does the codebase already contain a suitable pattern?
Can the result be tested clearly?
What could regress?
Only create competing implementations when analysis cannot resolve an important uncertainty, such as two algorithms that need benchmarking or two architectures with genuinely different trade-offs.
Turn the selection into a plan
Exploration answers “what is actually wrong, and what are the options?” Planning answers “what exactly will we change?” Before any code is touched, the selected approach is written down as a short plan:
the root cause, and the evidence for it;
the files and symbols to change, and those to leave alone;
the ordered steps;
the tests that should fail now and pass afterward;
and explicit non-goals.
The plan becomes the contract for the implementation agent, and later the reviewers check the diff against it. Rejected proposals still contribute: their risks and edge cases go into the plan as things to guard against.
Implement once
One agent implements the selected approach in an isolated Git worktree.
It receives the requirements, chosen plan, relevant insights from the other proposals, repository guidelines, and expected tests.
This keeps the implementation coherent. There is one branch to understand, one diff to review, and one result to merge.
If the implementation agent discovers evidence that contradicts the plan, it should update the approach rather than follow the plan blindly.
Review in parallel
After implementation, several independent agents review the same change.
Generic review prompts produce repeated comments and noise. Each reviewer should have a defined responsibility.
A thorough review team might include:
Correctness: bugs, invalid assumptions, races, missing error handling, and edge cases.
Security: authorization, injection, sensitive data, unsafe input handling, and configuration risks.
Architecture: consistency with existing patterns, coupling, abstractions, and separation of concerns.
Alternatives: simpler algorithms, framework features, standard-library replacements, and more idiomatic solutions.
Performance: unnecessary work, memory use, rendering cost, network behavior, and blocking operations.
Simplicity: unnecessary files, layers, abstractions, and speculative generality.
Independent model review: a broad review from another model family.
Every reviewer receives:
the original requirements;
the complete diff;
the changed-file list;
repository guidelines;
and access to the surrounding source code.
Reviewers must inspect the repository before reporting a problem. A patch alone often lacks the context needed to distinguish a real defect from an intentional project pattern.
Each finding should include:
severity;
exact location;
a concrete failure or maintenance scenario;
supporting evidence;
the smallest reasonable fix;
and confidence.
The reviewers work independently so that one review does not anchor the others.
Synthesize the findings
The programmer should not have to read seven raw reports.
A synthesis step should:
verify every claim against the code;
remove false positives;
merge duplicate findings;
correct inflated severity;
identify disagreements;
and produce one final verdict.
The result should contain only verified critical issues, relevant warnings, useful suggestions, unresolved disagreements, and a clear approval decision.
Reviewer agreement is useful, but it is not proof. Several agents may share the same misunderstanding, especially when they use the same underlying model.
Agreement determines what to investigate first. Evidence determines what to accept.
Human judgment remains necessary for trade-offs. One reviewer may recommend an abstraction to remove duplication, while another may argue that the abstraction hides meaningful differences. The correct choice depends on the project, not on vote count.
Refine and review again
Accepted findings are passed back to an implementation agent. It refines the existing branch, and the change is reviewed again.
The second review matters because fixes can introduce new defects or unnecessary complexity.
The loop should stop when:
no verified critical issues remain;
remaining warnings are resolved or explicitly accepted;
tests cover the important behavior;
the result still matches the original requirements;
and another review pass produces little new information.
The goal is confidence, not endless iteration.
A worked example
A task manager receives a bug report: “Tasks I complete on my phone show up as undone on my laptop after sync.”
Explore. Three models investigate in read-only mode. Model A traces the sync code and concludes that conflict resolution drops the completed flag when both devices edited the task. Model B blames the UI: the laptop recomputes its “done” filter from stale cached state. Model C finds that the app already has a per-field merge utility, used for projects but not for tasks. Each proposal cites files and names a test that should fail.
Decide and plan. Reading three one-page proposals takes five minutes. A reproduction test confirms the conflict path, so the UI theory is rejected, but its stale-cache observation goes into the plan as a risk. The plan: reuse the existing merge utility for tasks, add a regression test for concurrent edits, and leave the UI layer alone.
Implement once. One agent executes the plan in its own worktree: about 60 lines of code plus tests.
Review in parallel. The correctness reviewer flags an uncovered case: a task deleted on one device while it is completed on another. The architecture reviewer approves the reuse. The simplicity reviewer notes that an old helper is now dead code. The security reviewer finds nothing.
Synthesize. A new test confirms that the delete-and-complete case fails, so it is accepted as critical. Removing the dead helper is accepted as a warning. Two duplicate comments are merged, and one reported race is dropped because sync runs serially.
Refine and review again. The agent handles the edge case and removes the helper. The second review adds nothing of consequence, and the change is merged.
The developer made three decisions: which cause was real, whether the edge case mattered, and whether to merge. Everything else was agent time.
Why this saves programmer time
This workflow consumes more agent computation than asking one model to solve the entire task. But computation is not usually the bottleneck.
Programmer attention is.
The developer does not need to investigate every approach personally, compare several complete implementations, or read every unfiltered review comment.
Instead, the developer receives a compressed sequence of decisions:
These are the strongest approaches.
This is the selected implementation.
These are the verified problems.
These refinements were made.
This is the evidence that the result is ready.
When to use it
This workflow is not a fit for the smallest tasks. Use it when the cost of a wrong solution outweighs the additional orchestration, for example:
bugs whose cause is unclear or spans several layers;
changes to core code such as sync, persistence, or data models;
security-sensitive changes;
and cross-cutting refactors or architectural decisions.
For typo fixes, renames, dependency bumps, or small changes you already know how to make, a single agent is faster. A useful middle ground is to skip parallel exploration and keep only the parallel review.
Using it with Claude Code, Codex, and other agents
You do not need a new platform to try this. The building blocks already exist in the CLI agents most developers use:
Explore: run the investigation prompt non-interactively in several agents at once, for example: claude -p, codex exec, and gemini -p, each restricted to read-only access, and save each proposal to a file.
Plan: commit a short PLAN.md to the branch, or use Claude Code’s plan mode, so the implementation agent has an explicit contract.
Implement: git worktree add gives the implementer an isolated checkout that no other agent touches.
Review: define each reviewer role once, for example as a Claude Code subagent in .claude/agents/ or as a reusable prompt file, so every run uses the same responsibilities and finding format. Keep project conventions in CLAUDE.md or AGENTS.md so every agent sees them.
Synthesize: one more agent call that receives the diff, all review files, and the verification instructions.
Wrap these steps in a custom slash command or a small script, and the whole loop runs from a single command. I built Parallel Code, an open-source desktop app, partly for this: it runs Claude Code, Codex, and Gemini CLI side by side, each in its own worktree, so the parallel phases stay easy to follow.
Conclusion
The future of AI coding is not simply one increasingly capable model working alone.
For important problems, the more effective workflow is:
Use multiple models to explore the problem, implement one coherent solution, review it from several perspectives, and repeat until the evidence is convincing.
Better models improve each role. Multi-agent workflows turn those roles into an engineering process.
‘Till next time!
Johannes
Enjoyed the article? The most sincere compliment is to restack this for your readers.
Whenever you’re ready, here is how I can help you
Go from agent user to agent builder. Master the foundations of AI agents and turn fragile demo code into reliable, production-ready systems with my course, Agent Engineering: Building Multi-Agent Systems (made with Towards AI).
35 lessons. Pure foundations from scratch. 4 mini-projects. 2 production systems. A certificate and direct access to me & industry experts in our Discord.
Built for software and data professionals transitioning into AI engineering. Rated 5/5 with 300+ students. The first 7 lessons are free:
Not ready to commit? Start with our free Agent AI Engineering Guide, a 6-day email course on the mistakes that silently break AI agents in production.
Images & videos
If not otherwise stated, all images and videos are created by the author.
