The build
loop
The business requirements say what it does. The reference architecture says what it runs on. The build plan comes from both, and the loop runs it one stage at a time.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
The build plan is the only one of the three the AI writes.
One: what it does
The business requirements. What it does, for whom, the rules, and what done means. Written by the business.
Two: what it runs on
The technical requirements. For most projects a pointer to the reference architecture, plus whatever this project does differently.
Three: in what order
The build plan. The stages in order, and which requirement each one satisfies. Written by the AI from the first two.
Naming the requirement each stage satisfies is what makes the loop checkable.
A stage is small enough that the change can be read.
Add the export. Handle the blank field. Make the totals reconcile.
Asking for the whole tool produces a large change nobody can evaluate, so it gets accepted on trust. Short steps drift less. The seams between them are where problems get caught.
Until it runs, generated code is only plausible.
It uses real-looking function names against real-looking interfaces and reads as though someone who knew the system wrote it.
An agent’s account of what it did is generated the same way. It will state that it added error handling and updated the tests. That sentence carries no more weight than the code it describes.
Running is the check that costs nothing.
It returns in seconds and is never ambiguous.
Real input, not a described example. An example was chosen to work.
The error text names the file, the line and the problem.
It is also the part most often skipped, because the agent’s summary is easier to read.
TypeError: Cannot read properties of null (reading 'total') at buildInvoice (lib/invoice.ts:42)
Line 42 tried to read the total off an invoice, and there was no invoice there to read. That is a different problem from a wrong total. The text is what distinguishes them.
The error goes back, not a restatement of the request.
Pasting the error is more useful than describing it, because the text contains the file, the line and the failing value.
Most failures clear on the next attempt. The errors are not repeated exactly, so a second attempt with the error attached is a genuinely different attempt.
A stage is finished when it satisfies the requirement, not when it runs.
Code that runs is the beginning of the check. The end of it is reading the output against the part of the business requirements that this stage was supposed to satisfy.
When the result and the requirements disagree, the plan is what is wrong. The build plan serves the business requirements, so it is the plan that gets corrected and the stage that gets run again.
The problem is the stage, not the explanation.
The instinct is to explain again, at greater length. That rarely changes the result.
The stage is too large
Too much is changing at once for the result to be evaluated or the failure to be located.
The context is too thin
The agent was not given what it needed, and it filled the gap with something plausible.
The requirements are silent
Document one does not say what the thing should do, so every attempt is a guess at the gap.
Generate, run, read the error, iterate, then check the stage against document one.
An agent has no sense of finished. It will keep improving code that already worked. The testable sentence in the business requirements is what ends the build.