Oracles & AI-assisted build
AI coding agents implement against written specs; oracles drive the loop while they work; parallel work stays safe because each piece has a decidable done-check.An oracle is any mechanism that can look at code and say this is wrong without a person having to inspect it. A type checker is an oracle. A lint rule is an oracle. Schema validation that rejects malformed input at runtime is an oracle. A test is an oracle. They differ in how fast they answer and how specifically they explain the problem — a type error names a file and line in seconds; a failed end-to-end test might just say the checkout flow broke. Types, lint, and schema validation act as fast oracles that drive the agent's loop as it works. The expensive test suite against real infrastructure runs last, gating the merge once the cheap layers have already caught what they can.Multiple independent pieces of work run at once — each in its own cloned repo with its own spec and its own agent — rather than one agent working serially through a queue. What makes that safe is that every piece of work has a written definition of done and a single verification command that proves it, so review is a bounded check of a diff against explicit criteria rather than an unbounded read from memory across five things at once.A check written to verify one piece of work is not thrown away when that work ships. It gets folded into the standing lint rules and test suite, so every future change is automatically checked against it without anyone remembering it exists. That is what makes automated gates a compounding asset rather than a fixed checklist.
In practice: two parallel agent runs — one on an API contract change, one on a merchant UI flow — each green on their own verification command before merge. The new lint rule and integration test written for that work are folded into CI, so the next change inherits them automatically.