August 2026 · Engineering

How builds verify themselves

AI output is probabilistic; shipped software shouldn't be. So we don't hand you what the builder produced — we hand you what survived verification. Every build runs a verify → fix → re-verify loop before it's called done, and the verifiers are separate agents from the builder: a fresh set of eyes with no attachment to the code.

The layers

LayerWhat it checks
Code reviewA read-only reviewer agent hunts real defects — broken logic, dead interactions, state bugs
Security auditInjection surfaces, credential leaks, unsafe patterns in generated code
Links & SEOBroken links, missing metadata, robots.txt and sitemap correctness
AccessibilityAutomated axe-core pass — contrast, labels, keyboard navigation, ARIA misuse
ConformanceDoes the build actually match what the plan promised? Pages, features, content
In-browser checkThe build runs in a real browser; games get played, apps get exercised

Findings get fixed, not filed

When a verifier finds something, the build doesn't come back to you with a bug list — the loop sends the findings to a fix pass and re-verifies, up to three rounds inside the build. Anything that must be fixed and still survives triggers an automatic follow-up fix run: a fresh builder invocation whose entire mission is the surviving findings, working on a clone of the build so the previous version stays untouched as a rollback point.

Why separate verifier agents? The agent that wrote the code is the worst judge of it — same blind spots in, same blind spots out. Verifiers run with their own prompts and no stake in the build passing. Findings only count when they can be shown concretely: a file, a behavior, a failing check.

What you see

Each completed build carries its verification record — which layers ran, what was found, what was fixed, and anything advisory left for your judgment. It's the difference between "the AI finished" and "the build passed."

← All posts