HOW IT ACTUALLY WORKS
From an idea to a finished product. Both halves, every step.
The first half writes the plan. The second half builds the product from it. Here is what happens inside each one, in the order it actually runs — no summary, no hand-waving. This site went through both.
- 7steps to write the plan
- 7stages to build the product
- 0times an agent grades its own work
THE HARD PART
Everyone already agrees the loop is what matters.
There is a well-known way to build software with AI: three agents in a loop. One plans, one builds, one judges, and they go around again until it works. We think that is exactly right. The disagreement is not about whether you need a loop. It is about how far the loop goes.
That same write-up names three reasons agents lose the plot. They are the right three. Here is what we do about each one.
1 · WHAT GOES WRONG
It cannot carry state.
An agent forgets. Sessions end, the context window fills up, and the next one starts cold with no idea what was already done or why.
WHAT WE DO INSTEAD
The memory is a file, not a mind.
Everything the build needs to know lives in documents that outlive any single agent: the plan itself, a tracker updated as each piece lands, and the notes each agent leaves behind when it finishes. Work can stop in the middle and the next agent picks it up from the page. Nothing important is ever only inside somebody’s head.
2 · WHAT GOES WRONG
It cannot size the work.
Ask for a whole product and an agent will try to do it in one go, call something finished when it is half done, and run out of room in the middle of a feature.
WHAT WE DO INSTEAD
The work is divided before any of it starts.
The plan splits the product into numbered pieces, each with a finish line written down in advance. Then the build runs as stages, and each stage has its own exit. Nothing is called done because an agent felt done. It is done when the thing that was written down is true.
3 · WHAT GOES WRONG
It cannot judge its own output.
The agent that wrote the code also writes the test for it, and it tends to be generous with itself. Shallow tests pass. Mediocre work gets rated as good.
WHAT WE DO INSTEAD
Nobody grades their own work. Ever.
Every review is done by an agent that did not do the work. Reviewers read drafts they did not write. Testers test features they did not build. Auditors read code they never touched. And a review is not an opinion — it has to point at the exact line, and the fix has to be proved with a before-and-after.
We are not claiming a better model. We are claiming a longer loop.
None of this is secret. The instructions our agents follow are open source — the same ones we run. Read them on GitHub →
PART ONE
How the plan gets written.
This is the half you buy. It takes about 60 to 90 minutes and it runs on our servers while you watch. Pick any step to see what happens inside it.
1 of 7
You describe it. An agent asks you questions.
Write your idea in one box, in as much detail as you have. An agent reads it and comes back with one short list of questions — all at once, not one at a time. Answer the ones you care about and skip the rest. Then you get a summary of what it plans to write. Fix anything that is wrong and press go. This is the only part where you steer, so take your time here.
A vague plan makes vague software. This is where the vagueness gets removed, and it is the last chance to remove it.
2 of 7
Several agents write the first version at once.
The document gets split into sections and handed out: what you are building, what to build it with, the database tables, every feature in detail, the API, security, the design, and the order to build in. The agents write their sections at the same time, then the pieces are assembled into one document.
Writing in parallel is why this takes an hour instead of a week.
3 of 7
Two reviewers pull draft one apart, from different angles.
Neither of them wrote it. One reads it as the architect: does it contradict itself, is anything left vague, is anything missing, do the steps depend on things that do not exist yet. The other comes at it from a completely different direction — security, testing, the parts people forget. Both file findings in a fixed format: what is wrong, where it is, and how to fix it. Feedback too vague to act on gets sent back.
Two different kinds of reader catch two different kinds of mistake. One reader only ever finds one kind.
4 of 7
Every finding gets fixed.
All of them, not just the easy ones. Each fix is written out precisely enough to apply without interpretation, because a vague instruction just creates a new contradiction somewhere else. This pass also settles the things that quietly disagree across a long document: one way to name things, one shape for errors, one answer per question.
Every contradiction left in a plan becomes a bug in the product.
5 of 7
One more read, and it goes deeper than the first.
Fresh eyes, whole document. Did the fixes actually land? Did any fix break something that used to be right? Do the sections still agree with each other? Does every milestone have a finish line you could actually check? The obvious problems are gone by now, which is exactly why this pass has room to find the hard ones.
The second look always goes deeper than the first. That is the reason there is a second look.
6 of 7
The last fixes go in.
Usually small by this point: a number that is wrong in one place, a missing item, a sentence that could be read two ways. Then the document is marked final.
Small and wrong is still wrong. It costs a minute here and an afternoon later.
7 of 7
Checked against your own words, then handed over.
Before it is yours, the finished document is read back against what you asked for in step one — your words, not the summary of them — to make sure it is still your product and not the one that was easier to write. Then you get the file: one markdown document, usually 6,000 to 12,000 lines. Read it here, download it, or send someone a link.
One payment, one spec, written once. There are no revision rounds, which is why step one matters as much as it does.
Questions
- 3drafts
- 2review rounds
- 60-90minutes, start to finish
- 1file at the end
No round gets skipped because the document already looks fine. Skipping one costs more later than it saves now.
WHY IT HAS TO BE THIS LONG
A plan this detailed is what makes the next half possible.
A spec is not a prompt. A prompt is a wish. A plan is a build order: exact database tables, exact API calls, numbered steps, and a finish line for each one.
That difference is the entire reason the second half can run for hours without stopping to ask you anything. An agent that has to guess will guess — and it will guess differently in section four than it did in section two. An agent that has been told does not have to.
It is also what lets the work be split across a team of agents at once. You can only divide a job between ten workers if the job was divided up first, on paper, before anybody started.
PART TWO
How the plan becomes a working product.
This half runs on CRHQ. One agent reads the plan and runs the whole job, handing pieces of it to a team of other agents. It runs for hours, not minutes. Pick any stage to see what happens inside it.
1 of 7
Set up first, then stop and ask.
Before anything gets built: a repository, one shared working branch, and a live development environment on a real server. From that point on, every piece that gets finished is already running somewhere you can go and look at it. Then the builder stops and waits for a person to approve the setup before it writes a line of the product.
There is no launch day at the end. It has been live since the first day, which is why nothing is a surprise on the last one.
2 of 7
The whole plan gets built.
The lead agent works through the plan in order and hands each piece to a different agent. Several work at the same time. There is one hard rule: never two agents editing the same files at once — work that overlaps gets queued instead of run in parallel. Test accounts and realistic sample data get created along the way, so the product can actually be used rather than just compiled.
Parallel where the work is separate, one at a time where it is not. That single rule is what stops a team of agents from overwriting each other.
3 of 7
A real QA round, run by agents who did not build it.
First the test plan gets written: one agent writes a checklist of every way the product must be tested, a second reviews that checklist and says what is missing, a third merges both into the final list. Then testers work through it in batches, driving a real browser, on a desktop and on a phone, signed in as each kind of user. Anything that is not right goes back to be fixed, then gets tested again. The round ends with the numbers: how many passed, how many were flagged, and what happened to every flag.
Three agents to write a checklist sounds like a lot. It is cheaper than one missed payment bug.
4 of 7
The whole codebase gets read, then cleaned up.
An auditor reads the entire codebase — not one feature, all of it — and comes back with a ranked list of what is worth improving and what is not. A person picks the scope. Each approved item then gets its own written plan, which has to include the exact before-and-after checks that will prove nothing else moved. Only then does anyone touch the code.
Cleanup that cannot prove it changed nothing else is not cleanup. It is a new set of bugs with a tidy diff.
5 of 7
A second audit, deliberately deeper.
The same pass runs again with one difference: the auditor is told exactly what was skipped on purpose last time, so it cannot hand back the same list. With the surface problems gone, this round finds the things that were sitting underneath them.
A second review that repeats the first one is a wasted review.
6 of 7
Every screen, every state, on a phone and on a desktop.
There is a standing checklist of what a picky reviewer always finds: forms that accept nonsense, layouts that break a phone screen, buttons that do nothing when you press them, dialogs you cannot scroll, error messages copied straight out of a database. Every screen is tested against every item, at both sizes, for every kind of user. The fixes are made in one place — the shared component — so one fix lands everywhere that component is used, instead of one screen at a time.
Fixing it in the component is the reason the same problem does not reappear on the next screen.
7 of 7
Read back against what you actually asked for.
At the end, the finished product is compared against your original words — the first thing you wrote, not anybody’s summary of it. Anything missing gets listed and quoted against the line that asked for it. The clear ones get built. The ones that need a real product decision get written down and brought to you instead of guessed at.
The last check is the same as the first one: is this still your product?
Set up
- 7stages
- 2independent code audits
- 3agents just to write the test plan
- 2screen sizes, every screen
THE PART THAT IS EASY TO MISS
One agent runs the job and never does the work.
The lead agent does not write code. It reads the plan, decides what happens next, writes a full briefing for each piece of work, and hands it to a worker. Workers start with nothing — no memory of the project, no access to anything by default — so the briefing has to carry everything: what to build, which rules to follow, which files to touch, and how the result will be checked. Then the lead waits, reads what comes back, and decides whether it is good enough or goes around again.
Two things fall out of that, and they are the same two problems from the top of this page. Work can run in parallel, because every briefing is self-contained. And nothing depends on one agent staying alive, because the state lives in the documents rather than in anybody’s memory.
Lead agent
Reads the plan, writes each briefing, decides what happens next. Writes no code.
Worker
Boots from its briefing and builds one piece.
Worker
Builds a different piece at the same time, in different files.
Worker
Tests what the others shipped, and did not build any of it.
WHY THIS NEEDS A HARNESS
None of this runs in one chat window on a laptop.
A loop that runs for hours needs somewhere to run. Here is what that somewhere has to do.
Agents have to be able to hand work to other agents.
One agent runs the job and gives pieces of it to a team. They work at the same time, and the lead gets woken up when each one reports back. A build this long does not finish without that.
The work has to survive a restart.
Jobs that run for hours get interrupted. Because progress is written down as it happens rather than held in memory, an interruption costs the piece that was in flight — not the build.
It has to run on a real server, not your machine.
The agents work on the same server the product runs on. They can read the logs, run the tests, and drive a browser against the live site. Every finished piece is already online.
Somebody has to notice when an agent goes quiet.
Delegated work gets watched. A stalled agent gets spotted and restarted by the system, rather than discovered by you a day later.
And afterwards, it keeps running.
Once the product is live, agents on that same server can fix things, add to it, and answer customer email on their own.
PROOF
This page is inside the product it describes.
GenerateSpecs was written as a spec first, then built from that plan by a team of agents, then taken through both review rounds and the polish round you just read about. The plan is published on this site — all 6,667 lines of it, and the instructions the agents follow are on GitHub. This page is not a description of the process. It is one of its outputs.
Six other live products were built the same way.
- TranscriptAPI →
A YouTube transcript and search API. Around 15 million transcripts a month.
- YouTube2Transcript
Paste a YouTube link, get the transcript.
- Recapio →
Tools for YouTube: summaries, transcripts, chat and research. Tens of thousands of users.
- Zillapi →
US property data for developers and agents. Photos, taxes, schools, in one call.
- StayingAPI →
Live prices and availability across Airbnb, Booking.com and Vrbo, in one call.
- CRHQ →
The platform all of this runs on. Agents on real servers, working around the clock.
Start with the plan.
You can stop after the first half and take the file anywhere — most people do. The second half is there when you want it.
99 of 100 free specs left. Free ones get posted publicly.