Models basically approve their own code, so someone handed the grading authority to another model

The place where multi-agent collaboration gets stuck is often not code generation, but acceptance.

Hdr was originally a terminal tool and recently released a desktop app. Once installed, you can assign work in Claude Code, with workers running in the background, without switching interfaces back and forth. The official workflow is: Opus 5.5 acts as coordinator, Claude Code workers write implementations, Codex workers specifically nitpick, with a concurrency cap of 10.

Two lines to install, on Mac:

curl -fsSL https://releases.herdr.dev/app/install.sh | sh
hc --skill

The script verifies sha256; Linux and macOS are both supported; Intel Macs need to compile from source themselves. After installation, have Opus 5.5 confirm that hc works. Next is a very long setup prompt, roughly: read the official docs and skill instructions, create a coordination Skill called hdr-desktop, keep the main conversation in Claude Code, and use hc to manage the background. Check whether Claude Code CLI and Codex CLI are present; install them if missing; ask for login if needed. Start a Codex worker using Astra, explicitly set reasoning effort to xhigh, and first assign a read-only task: inspect the project and explain the main entry points. Once the loop of assigning work, waiting, and reading back results works, save the process into the Skill.

A user (Harry Tandy) said under that tweet that this setup prompt does too much. Indeed, environment checks, authentication, model selection, and reporting errors on failure instead of quietly switching models are all written into it.

The second prompt defines the long-term division of labor. Claude Code acts as coordinator, responsible for understanding the project, planning, splitting tasks, integration, and final review; heavy work is assigned to workers; frontend work must pay attention to layout, visual details, and real interactions; and a rule is added: don't design for rare cases no one mentioned. For parallel code changes, use independent worktrees; subsequent feedback should go back to the original worker to continue whenever possible, rather than starting over each round.

The review stage is the most interesting part of this workflow. Reviews must be handed to a Codex worker that did not participate in the implementation. The rule is: score each bug from 1 to 10 for frequency and severity; if the product of the two scores is below 5, just record it as an issue and don't touch the code. Rohan Bhanot said he wanted to steal this rule, because Codex reviewers love to rewrite half the repo over a small flaw.

The reasoning is in another reply. Salman Ahmed said Claude basically approves its own work when reviewing it; switching to another model can catch things the previous model was very confident about at the time. PanSalut said he runs it the other way around: Claude as tech lead, Codex does the typing, same rule: don't let a model grade its own homework.

There are also people pouring cold water. Josh Hoeg said this is essentially burning two subscriptions on the same bug. Jeff Bruchado pointed out a more practical problem: the reviewer reads the diff, so it can't see things like wrong spacing or a page that looks awkward; visual polish still requires opening a browser yourself. Arbaz asked why reviews must use Astra when Terra costs only one tenth.

A few details are worth calling out separately. After assigning work, you must read back the worker's actual reply for the assignment to count as successful; Carlo Makes said this is exactly what he likes. The authority to decide a task is complete stays with humans; the prompt states it plainly: don't treat it as complete just because another agent says it's complete. Finally, show the human the result, what was verified, and what problems remain.

10 concurrent workers sounds exaggerated. nick said the chaos is kind of satisfying; Read the Diff said the bottleneck now has a dashboard. In practice, the quotas of the two accounts are counted separately, and concurrency has to be adjusted based on the task and remaining balance. Neyronix asked a more technical question: do parallel workers avoid conflicts because of independent worktrees, or because of the coordinator's integration step? The source material doesn't provide an answer.

What this whole setup can currently deliver is turning acceptance into a process, while the final call remains with humans. Install once, configure once, and then bring up the Skill before starting each new task. As for whether the page looks good or the interactions feel smooth, the model saying it's fine doesn't count; you still have to click through it yourself.