Describe a site in chat; get a real, running codebase — live.
Run the code generator inside a sandbox and never let the orchestrator write code itself. Swift Builder runs Claude Code headless in a per-project Docker container, proxies that container's dev server out as a live preview, and routes each step to a cheaper or stronger model to hold a $3 to $5 per-site budget.
Because mixing planning and generation makes both worse. An orchestrator that also writes code starts making implementation decisions inside the planning step, and the failure modes become impossible to separate.
Here the orchestrator plans steps, decides which model handles each, and reads results. All actual file writing happens inside the sandbox, by the generator. That separation is what makes the cost routing and the critique loop possible at all.
Because generated code is untrusted code. It installs dependencies, runs a dev server and executes whatever it was written to execute, and none of that should share a filesystem or a network with anything else.
A container per project gives isolation and a clean slate. It also makes the build reproducible: the same prompt starts from the same empty environment rather than inheriting whatever the last run left behind.
A proxy maps the sandbox's dev server outward to the browser. The user watches the real site, served by the real dev server, while it is still being written.
That is meaningfully different from rendering a mock. What the user sees during generation is the artefact they end up with, so there is no gap between the preview and the result.
By not using the strongest model for everything. A cost-aware router sends simple, mechanical steps to a cheaper model and reserves the expensive one for work that needs it, with a budget meter tracking spend per step.
A single site involves many small decisions and a few hard ones. Paying top rate for all of them is what makes AI generation uneconomic, and routing is most of the difference between a $3 build and a $30 one.
It reviews the generated output and asks for fixes, feeding a revision loop that runs until the pass comes back clean.
This is cheaper than it sounds and catches the ordinary failures: a broken import, a missing state, a section that does not match the brief. A generator that never checks its own work ships those to the user.
An AI website builder that streams a working preview while it generates, holding a $3–5 per-site cost target.
| Orchestrator | Plans and routes, writes no code itself |
|---|---|
| Generator | Claude Code running headless |
| Isolation | One Docker sandbox per project |
| Preview | Sandbox dev server proxied to the browser, live |
| Model routing | Cost-aware, cheaper model for simple steps |
| Budget | $3 to $5 per site, metered per step |
| Quality | Automated critique pass with a revision loop |
| Output | A running codebase, not a mockup |
Because generated code is untrusted code that installs dependencies and runs a server. A container per project keeps that off the host, isolates one build from another, and guarantees a clean starting environment so the same prompt does not inherit leftovers from the previous run.
Route by difficulty. Most steps in building a site are mechanical and a cheaper model handles them fine; only a few genuinely need the strongest one. Paying premium rates for every step is what makes AI generation uneconomic, and routing is most of the gap between a $3 and a $30 build.
Yes, by proxying the sandbox's own dev server out to the browser. The user watches the real site being served rather than a rendered mock, which means the preview and the final artefact are the same thing.
Better not to. An orchestrator that writes code makes implementation decisions inside the planning step and its failure modes stop being separable. Keeping planning and generation apart is what makes cost routing and an automated critique loop possible.
Real phone calls, answered and placed by a conversational AI.