Five roles, one hard gate

The job that grades what it cannot see

The run phase has more jobs than planning, and the default move in this industry is the same as before. Wire a frontier model into every step and let the bill arrive. Most of it is still cost-vs-capability. One job in it is not, and the chain for that job is built to make the wrong call impossible.

Five hires this time. The Author who writes the code. The Reviewer who reads the diff. The Tester who exercises the change and looks for what broke. The Stager who runs the whole thing end to end. The Pixel Judge who grades the rendered UI.

Four of those five are the same shape as the planning roles. Capability levers (coding, reasoning, context, independence), cost levers, sometimes a soft preference for one family over another. Pick the cheapest model that clears the bar. Park a frontier model at the end of the chain as a break-glass floor. Move on.

The Pixel Judge is different. The Pixel Judge has to see what it is grading. A model that cannot see what it is grading still produces a number, and that number arrives looking like every other number in the run report. The chain that grades the UI is built to keep any such model out of it.

Four roles you can still cost-shop

The Author writes the code. Multi-file edits, tool use, a tight fix loop against the test suite that the design phase wrote earlier. The capability lever is agentic coding; the model needs to write correct diffs more than it needs to deliberate about them. A heavy reasoner spends its budget thinking and burns retries. The chain runs deepseek-v4-pro, then minimax-m3, then qwen3-coder. All three coders, all three with enough context to not truncate; claude-sonnet-4-6 sits at the end as the break-glass floor.

The Reviewer reads the diff. The Reviewer is a judge over the Author’s work, which makes the load-bearing rule independence: the Reviewer cannot be the Author. The chain runs qwen3-max-thinking, then kimi-k2.6, then glm-5.2. Alibaba at the head, Moonshot second, Zhipu third, deliberately three different families so the advocate and the adversarial critic do not share blind spots. deepseek-v4-pro (the Author) is absent from the chain entirely. A model is biased toward approving its own patterns. Do not let it grade itself.

The Tester exercises the change and hunts for defects. For backend tasks that is a text-only agentic loop. For frontend tasks the agent drives a browser and gets handed screenshots, which means the head has to see pixels. The chain runs minimax-m3, then kimi-k2.6, then gemini-3.5-flash. All three multimodal at the top of the chain, so a frontend task never falls over into a text-only judge. The rule the chain encodes: keep the multimodal models at the front and never let a text-only model lead this phase on a frontend project.

The Stager runs the whole pipeline end to end. Long agentic sessions, sprawling multi-task transcripts, one final pass before merge. The lever is context window: a million tokens, or the transcript truncates and the model grades half a story. The chain runs gemini-3.5-flash, then minimax-m3, then deepseek-v4-pro. All three at one-million-token context; the head is pricey but the phase runs rarely, so the cost amortises.

Four chains, four levers, four cost-first orderings. Same shape as the planning side. Then the Pixel Judge.

The chain has one rule: every entry has to see what it is grading. The rule is what makes the silent failure impossible.

The judge that has to see

The Pixel Judge grades the rendered UI. It receives screenshots and decides whether the layout, the spacing, the contrast, the hierarchy are right. The lever is vision. Not preferred. Required.

The chain has one rule. Every entry must accept image input. No exceptions, no failover into text. The rule sounds boring until you imagine what happens without it. A text-only model in this chain would not crash on a wrong input. It would not flag a missing field. It would return a score. That score would sit next to every other score in the run report, and the Pixel Judge stamp on a frontend task would look identical whether the model could see the screenshot or not.

So the chain is built to make that scenario impossible. It runs gemini-3.5-flash, then kimi-k2.5, then minimax-m3, with claude-sonnet-4-6 parked at the end as the break-glass floor. Every entry is multimodal, verified against OpenRouter, not against the repo catalogue. The text-only models that lead other chains, deepseek-v4-pro, glm-5.2, qwen3-max-thinking, are excluded here by design. There is no override path that lets one in.

This is the gate Part 1 did not have to worry about. Planning is text in, text out; pick the cheapest capable reader and trust the answer. Run-phase vision is binary. The other four chains are cost-vs-capability optimisations where the wrong call costs money. This one is a correctness gate, and the chain is what keeps the silent failure off the truck.

The Takeaways

1. Hard gates are not preferences. Most chain decisions are cost-vs-capability trade-offs; pick the cheapest capable model and move on. The Pixel Judge is not one of those. Vision is binary, and the chain has to enforce it: every entry multimodal, no override that lets a text-only model in.

2. Independence matters where the judge only sees the artefact. The Reviewer cannot be the Author. The same rule generalises to any judge whose only input is another model’s output: pick a different family at the head and the second so blind spots do not stack.

3. Cost still wins where the job allows it. Four of the five run-phase chains lead cost-first, frontier model parked at the end. The bill on the run phase is the bill on the whole pipeline. Default to cheapest capable; reserve the exception for the gates that are binary, not the ones that are merely important.