The common picture of building with AI is one person and one chat window, asking for a thing, reading the reply, asking for the next thing. It is a tidy picture, and it is not how this site got built. We did most of the heavy work here with many workers running at once, each handed its own task, while the two of us set the brief and judged what they returned. The chat window was the smallest part of it.
Take a few of the jobs behind what you are reading. Every chapter in the library cross-links to others by their titles, and when we changed the structure, those links had to change across the whole set at once. A batch of older diagrams, carried over from an earlier site, had to be redrawn in the current house style. A whole part of the course had to be drafted, chapter by chapter, against the same voice. When we added dark mode, every diagram on the site had to be moved off fixed colors and onto the theme tokens so it would read in both palettes. None of these was typed out in sequence in a single thread. We sent each one to a group of workers running in parallel, one per file or one per chapter, and they finished at the same time.
The moment one worker becomes many, you are doing a different job. You are no longer limited by how fast you can produce, because the workers now produce in parallel and cheaply; instead you are limited by two harder things. The first is stating the task clearly enough that a worker who cannot stop to ask a follow-up can still finish it correctly. The second is judging what the workers return, because a group of them will return a group of plausible answers, and plausible is not the same as right.
Building with AI at any real size is orchestration, not conversation. You stop typing the work and start briefing the workers and judging what they return.
That is the whole job once the scale is real. Hand the workers a vague brief and they return a fleet of wrong files that look finished, all at once, which is worse than one wrong file at a time. Hand them a sharp brief, one that names the constraint, the format, and the test for done, and they return work you can actually keep. And we never shipped anything a fleet returned without checking it: we ran a second pass on every batch, a practice that has its own note, How We Caught AI Mistakes With a Second Agent.
This is not a trick of building a website. It is the same shift the Frontier of The Builder's Stack teaches as orchestration: running many capable workers in parallel and keeping a person at the point where the judgment happens. The skill that mattered most across this build was not writing a better request; it was decomposing a large job into pieces a fleet could take in parallel, and then judging the results well enough to keep the good ones and send the rest back.
Where this goes next
The discipline behind this is the subject of the Orchestration part in the Frontier of The Builder's Stack, which covers how to split a job into independent pieces, run them at once, and verify the results before you trust them. For where this sits in the day-to-day loop of running an AI product, read The Operating Manual. The companion practice, a second worker whose task is to refute the first, is in How We Caught AI Mistakes With a Second Agent.
Sources
- The orchestration discipline behind this build is taught in the Frontier part of The Builder's Stack.
- The loop this fits into is laid out in The Operating Manual.