Runs and Judges
File-first execution#
Everything goes into files at every action: reasoning, collected data, intermediate output, all written immediately. The rule exists because subagents die. A run that crashes halfway must leave its work behind rather than an empty outputs folder, and a run you interrupt should still be worth something.
Judge panels#
A judge is a scoring step with a stated bar. Some loops use one, others use a panel with distinct perspectives. FrontendBuilder scores each UI iteration with four judges plus a fifth check:
Owner
Does this change serve the business? A UI that looks good and sells nothing fails here.
Customer
Do I understand this within three seconds of looking at it?
Aesthetic Designer
Is it beautiful, balanced, and intentional, rather than merely tidy?
Best Customer Experience
Is this the least-friction path to the outcome the user came for?
Human-Parity check
Does the result read as human work, or does it look AI-generated?
Judges score pixels and artifacts, never descriptions. A screenshot goes to the judge, not a summary of what the change was supposed to do.
Gates#
A gate is stricter than a judge: the loop is forbidden from finalizing while a gate is unmet. Well-Architected Design holds six of them at once, including a requirement for at least three competing architectures and a why-chain under every technical decision.
Why this matters for your own loop#
When a loop breaks, the fix is not the output but the loop. Add a judge, add a gate, or change the step so the same failure cannot pass silently next time. That principle is packaged as a runnable starter app in Building a Loop.