How Do I Review Code in Orca? Parallel Review Without Writing New Code

Last updated: 2026-10-25

Orca is a free, open-source desktop app from Stably AI that calls itself an ADE, an Agent Development Environment. It puts command-line coding agents such as Claude Code, Codex, OpenCode, and Pi into one window, giving each agent its own isolated git worktree so several agents can work on the same task in parallel, and you merge only the best result. This guide does not cover writing new code with Orca. It covers the review workflow only: handing old code, someone else's changes, or several implementations to multiple agents to review in parallel, then deciding what to merge.

How Is Review Different From Writing Code in Orca?

Writing code asks agents to produce changes. Review asks agents to give opinions only and touch nothing. That difference has to go into the prompt first: what the review is for, which files matter most, and that the output is a list of findings, not a patch. During review nothing merges and nothing lands. Opinions are laid out side by side and compared before anyone decides what to change. There is one more difference: writing code is judged by whether the result is good, while review is judged by whether the findings are accurate. A finding has to point at a specific line and a specific piece of logic. A vague verdict with no line to stand on cannot be turned into an annotation, which means it was not really a review.

What Should a Review Look At First?

Start with whether the logic drifted: does the change do the task it was asked to do, and did it quietly touch things it should not have touched. Then check boundary conditions: empty values, unusual inputs, and extreme branches, and whether any of them are unhandled. Third, check whether the scope of the change stayed inside its bounds: is the file list right, and did it reach into unrelated modules. Scope, logic, and boundaries come first, and style details come after. Details can go into annotations, but a change whose logic is sound should not be rejected over a style nit. When the order flips and review becomes style-picking, the real problems slip through.

How Do I Write a Prompt for Review?

Three parts: the goal of the review, the files that matter, and the shape of the output. The goal has to be explicit: judge whether this change is right, not rewrite it. The key files have to be listed: which files this change touches and which spots are critical. The output shape has to be fixed: opinions only, no code changes, findings listed by file and line number, with the problem, the reason, and the suggestion kept separate. A vague prompt produces vague findings. Without a goal, an agent may start editing. Without key files, findings scatter across the whole codebase and nothing stands out. Without a fixed output shape, opinions and edits arrive mixed together, and the review has to be taken apart again before it can be used.

How Do I Reconcile Findings From Several Agents Reviewing in Parallel?

Start with what agrees. When several agents flag the same problem, trust that problem first and handle it before the rest. Then look at the disagreements. One agent says there is a problem and another says there is not. That disagreement is itself a signal. Go back to the diff and look again at exactly which line and which piece of logic is in dispute. Do not settle disagreements by vote. Two agents saying there is no problem and one saying there is does not mean the minority is wrong. What matters is whether the reasoning points at code. Reasoning that lands on a specific line and a specific piece of logic carries more weight. A bare verdict with no reasoning goes to the bottom of the pile. Reconciling findings works the same way as picking a winner: set the bar first, then look at the answers, never by first impression.

How Do Review Findings Become Annotation Rounds?

Findings become annotations first. When a line has a problem, write the annotation on that line, stating what the problem is, why it is a problem, and what change is suggested. Send the annotation back and let the agent produce a revised version, then compare again: did the previous round's findings get fixed, and did the fix introduce new problems. There is no fixed number of rounds. The bar is that the findings are cleared, checked off one by one, before anything merges. When annotations start going in circles, stop. Rounds that never settle usually mean the review goal was never written clearly, or the change itself is headed the wrong way. Going back to the prompt and the goal is faster than grinding through more annotation rounds. Annotation is a tool for refining, not a safety net.

When Is a Change Ready to Merge After Review?

Three conditions, all of them. The logic has not drifted, the boundaries are covered, and the scope of the change has not spilled over. A cleared findings list is a hard condition: if any open item is left, the change does not merge. There is one more step before merging: read through the diff of the version being merged yourself, and confirm that it matches the findings that were reviewed, then merge. Merging right after review without looking is the most common hole in a review workflow. The findings that were reviewed have to land in the version that merges, not in a version that gets discarded. Reading through once takes little time. Rolling back a bad merge takes much more.

Is Reviewing Old Code the Same as Reviewing a New Change?

No. A new change comes with a clear scope: which files changed and why, and the review reads against that change list. Old code has no change list, so the scope has to be set before review starts: which module, and which class of problem, whether logic, boundaries, or hidden risks. Without a set scope, review of old code spreads everywhere. The method for old code is to draw the circle first, then assign the work: module, problem class, and output shape go into the prompt, and then several agents review in parallel. Old code also tends to surface more style findings. Put style findings in annotations, but do not reject a logically sound piece over style. One more rule for old code: do not try to review a whole library in one round. One module per round, write down what came out, and move to the next module next round.

What Do I Do When Review Findings Contradict Each Other?

Go back to the diff first. Look at which line and which piece of logic each contradictory finding points at, and whether its reasoning holds up. Keep the reasoning that holds up and drop the reasoning that does not. When both sides hold up, the spot itself admits two reasonable approaches, and that is when the acceptance bar decides: which approach fits the goal of this task better. When even the bar cannot decide, write it down and do not merge yet. A contested change is cheaper to hold than to merge and fix later. Contradiction is not a bad sign. Finding contradictions means parallel review is actually working. A single agent reviewing alone cannot produce a disagreement. A disagreement out in the open is a chance to pick right.

How Do I Keep What Each Review Round Teaches?

Write a few lines after every round: which change was reviewed, how many agents reviewed it, which findings agreed, where the disagreements landed, which version finally merged, and why that one. The note does not need to be elaborate. A few lines will do. What matters is that it happens every time. Notes from past rounds get reused directly. When a similar change comes up, the review focus, the common pitfalls, and the method for picking findings do not have to be invented again. Review experience that is never written down is never accumulated. The next similar change gets reviewed from scratch, and running more agents in parallel only repeats the same cost. The habit of writing it down matters as much as the review itself: a review that ends without a note is a review that gets forgotten.

What Does This Review Workflow Mean for Non-Programmers?

To be direct, review assumes you can read a diff and follow change logic, and the whole motion is reading diffs, writing annotations, and merging. For people who do not write code at all, the product that points the other way is aiglade: "Aiglade 是一个 Windows 桌面软件，把 Claude Code、Codex CLI、Hermes、OpenClaw 等多个 AI 装进一个中文窗口，带中文向导，装上就能用，不用会编程。" Its slogan is "不用先学会技术，也能让 AI 替你干活". In one line: people who write code and need to review other people's changes and several implementations should look at Orca; people who do not program and just want AI to do the work for them should look at aiglade.

References