Six pull requests landed in my repo in one day, and the agent I talk to all day didn’t write any of them. They were small, bounded backlog items – the quick-win tier – built by a rival vendor’s CLI agent in isolated git worktrees. My primary agent briefed it, audited its work, sent the review findings back to it, and merged the results.
Every comparison post this year asks the same question: Claude Code or Codex or Grok Build, which one wins. After running two of them together for six weeks, I think that’s the wrong question. The interesting one is: you already pay for a second agent, what job do you give it?
Most people answer “code review”, and that’s where mine started too. Second-model review is cheap to set up and catches things the first model is blind to, because the two share fewer habits. But review-only leaves the second agent doing the easy half of its job. The promotion worth writing about is from critic to builder – and it only stays safe because of the contract around it.
The lane contract
The shape is hub-and-spoke. One agent – call it the judge – never builds. It picks the task, writes the brief, dispatches the builder into its own git worktree, re-runs every gate on the result, and lands the merge. The builder never lands anything, and never talks to me directly.
Four rules carry all the weight.
The judge doesn’t build. The one time I let my judge “quickly” implement a tooling bridge itself, it burned an afternoon doing work a builder lane would have done in parallel, and while it was heads-down nothing else moved. Orchestration is a full-time job: sequencing tasks, watching gates, deciding what’s worth a dispatch. A judge that builds stops judging. The boundary I settled on: a trivial tooling fix is fine, anything product-facing goes to a lane. The precise rule is “the judge owns no product diffs” – but “the judge doesn’t build” is the version that survives in your head.
Findings report up, never sideways. Early on, a dispatched agent surfaced a “suggested task” chip straight into my UI. The suggestion asserted a premise that was simply wrong – and nothing had checked it, because it skipped the judge on its way to me. Now every brief carries an explicit line: report findings in your final output; do not open tasks, chips, or messages addressed to the human. Everything the builder produces passes through the judge’s verification before I see a word of it.
Review findings round-trip to the original builder. When the reviewer came back with three warnings across the run, the tempting move was to fix them in the judge’s session, where I was already sitting. Wrong move. The builder that wrote the diff still holds the context: which alternatives it already rejected, which invariant shaped which line. All three warnings went back to the same builder session, and all three fixes came back correct. The proof step stays with the judge, though: deliberately re-break the code, watch the gate fail, watch it pass again with the fix in place. A builder certifying its own repair is the original problem wearing a hard hat. A fresh fixer, meanwhile, re-onboards from zero and guesses; the author doesn’t have to.
The judge re-runs every gate itself. The builder’s log says the tests passed. Lovely. The judge runs the full suite again in the worktree before merging, because an agent’s own green summary is the weakest evidence there is. Trust the diff, not the diary.
Write the brief as a file
Dispatching a builder with a chat message is how you get a plausible diff that solves a slightly different problem. Each dispatch here is a written brief the judge authors first – the version below is trimmed from the one I actually use:
BUILDER BRIEF: <task-id>
SCOPE - the only files you may touch:
<explicit paths>
OUT OF SCOPE (hard): anything not listed above. If the fix seems to need
another file, STOP and say so in your final output instead of editing it.
INVARIANTS IN PLAY: <the 1-3 project rules this task can plausibly break,
quoted in full - not a link>
VALIDATION CONTRACT - run these before reporting, paste real output:
<exact commands + what "pass" looks like>
REPORTING:
- Findings and status go in your FINAL OUTPUT only. Do not open tasks,
UI suggestions, or messages to the human. Your reviewer may send
findings back to you; fixing them stays your job.
- Never claim a gate you did not run this session. "NOT RUN" is an
acceptable answer; a pasted stale log is not.
STOP CONDITIONS: <what should abort the task instead of "creatively"
working around it>Two mechanical notes that cost me real time. This particular CLI swallows stdin when dispatched headless, so every dispatch ends with < /dev/null or the process hangs forever looking interactive:
grok --prompt-file brief.md --cwd ../wt-task-1 \
--permission-mode bypassPermissions --max-turns 30 --no-plan \
> task-1.log 2>&1 < /dev/null &Yes, that’s permission-bypass in the flags – sane only because the worktree is disposable and nothing lands without the judge’s own re-run.
And long briefs fail strangely: twice, a ~60-line multi-part brief got back a confident preamble and then… nothing. The same task as a short single-ask brief, with the scope carried by file paths rather than prose, worked first try. Poll the log; never block a session waiting on a builder.
The day the critic vanished
The same week, there was a day the second vendor was unreachable and that whole lane – builder and critic both – went dark. The failure mode that tempts you here is quiet: the pipeline step “second-model review” gets skipped, and skipped quietly becomes passed.
The rule that held: an unavailable critic is no evidence, not a pass. Work that day landed only where the deterministic gates – fixtures, type checks, the re-run suite – covered the risk on their own. The state file from that day still carries the line: the second model was “unavailable and therefore counted as no evidence”. Absence of review is a fact; the record should say so.
What this costs, honestly
The judge’s time is real. Briefing, auditing, and landing six PRs is a day’s work for the judge lane even though the building runs in parallel. The building isn’t free either: a second vendor seat, its tokens, and CI minutes for every re-run gate. You’re paying an attention tax for throughput; on a quiet week the lane isn’t worth spinning up.
The second model over-escalates. On its first review outing mine flagged documented, fixture-covered design decisions as warnings. Weeks later the same lane caught a real contrast failure everything else had missed; the fix measured 4.56:1 in light mode and 7.30:1 in dark. Both kinds of finding arrive wearing the same severity label. Filtering defect from disagreement is the judge’s actual job.
And none of this works without a deterministic gate the judge can re-run. If your project can’t already answer “is this change safe?” with commands, fix that before hiring a builder; a lane without gates doesn’t give you leverage, it gives you deniability.
Two agents, one judge, briefs in files, findings that flow up and round-trip back. It’s less a team of rivals than a fast contractor under a paranoid site inspector, and for code you have to own afterwards, that’s the right relationship. Start with the brief template, wire your existing gates into its validation contract, and promote your critic the week it stops surprising you.
Further reading: the terminal-agent field this setup lives in – Grok Build vs Codex CLI vs Claude Code and the July 2026 state of play. The full dispatch brief lives in my prompts library as builder-lane-dispatch-contract, failure modes documented, alongside the sign-off evidence gate the reporting rules are built on. The review standard my judge holds builders to, Think Like Roy, is free – CC BY 4.0.
Comments & Reactions
Got a thought, a war story, or a “well, actually”? Sign in with GitHub and jump in.
Loading comments…