The plan you skip is the outage you debug later
Every framework in software engineering tells you to move fast, ship early, iterate in production. For AI-generated websites, that's backwards. The builder here refuses to stream code straight from your prompt — it stops, writes a plan, and waits for you to look at it — and that refusal is the single decision everything else in this pipeline is built around. Slower up front, cheaper everywhere after. I'll take that trade every time, and I think most people arguing for the opposite haven't actually watched what a wrong guess costs downstream.
Here's the failure mode the plan exists to prevent. You type "a booking site for my studio" and hit go. The system has to guess what "booking" means — a calendar widget, a third-party embed, a real reservation system with conflict checking — and it has to guess before it's written anything, because there's no other order to do it in. Guess wrong inside a plan and the fix is one sentence, five seconds, done. Guess wrong inside generated code and you're not editing a sentence anymore, you're unwinding ten files that already depend on the wrong assumption. I've watched both versions happen. The plan-stage correction is one exchange. The post-generation pivot on the identical ambiguity is a discard-and-rebuild.
The plan isn't just a to-do list either, and this is the part people miss. It's a contract, and the system holds itself to it: a conformance-check verifier, one of the agents that has to sign off before a build ships, diffs the finished site against the plan you approved. Did every planned page get built? Does the feature list match what shipped? "Done" isn't a vibe here — it's relative to a written promise, checkable line by line. That's a stronger guarantee than "the code runs," and you only get it because there's a document to check against. Take the plan away and you take away the yardstick.
Where this actually pays off
Your leverage as the person driving the build is front-loaded, whether you exercise it or not. If you care about information architecture, page structure, which features make v1 versus v2 — that pickiness is worth ten times more at plan review than after the first generation pass. Four extra minutes rereading a plan beats a round-trip fixing a build that already went sideways.
The clearest example is product type — plain static site, installable app, framework build, server-backed app with real persistence. It looks like a dropdown. It isn't. It's the most structural choice in the whole process, because it silently decides a dozen things that have nothing to do with what the site looks like.
| Product type | Preview | Publish | Accounts / database |
|---|---|---|---|
| Plain static site | Instant, since it's just static files | Static output copies over cleanly | Not possible — asking for login is asking for something the type structurally can't do |
| Framework build | Compiles first; a broken build shows up as "no preview," not "broken page" | Same clean static-copy path, once compiled | Not possible |
| Server-backed app | — | Needs somewhere to actually run a process, which fails differently — a crashed process, not a missing file | The only type where accounts and databases exist at all |
And you cannot casually upgrade type later. Going from plain site to server-backed app isn't a settings toggle — it's close to a second build, because half the plan's assumptions (how pages load, where data lives, what "publish" means) were made against the old type. So say it at plan time, even half-sure: "there's a chance I'll need accounts." Planning for a server-backed app and only using the static parts costs nothing. Discovering you needed one after the fact costs a rebuild.
Where the critics have a point
None of this is free, and I won't pretend it is. Isolated per-run workspaces mean your knowledge files get copied in fresh, nothing reaches back to your machine — good for you if your laptop dies mid-build, bad for latency, because provisioning a workspace and, for framework builds, running a real dependency install inside a container boundary takes real wall-clock time. That container boundary exists because a framework build runs `npm install` and arbitrary build scripts — code you didn't write, executing with build-time privileges — and doing that on a shared host with no isolation is one dependency-confusion attack away from touching another tenant's data. Fast-and-unsafe was available. It just wasn't a trade worth making.
Same story with verification. A finished build doesn't leave the pipeline when generation stops; it leaves when a set of independent verifiers stop finding things worth blocking on:
- Code review
- Security
- Links and SEO
- Accessibility
- Conformance
- An actual in-browser run
That's not one pass, it's flag-fix-recheck, looping until nobody has anything left to say, because a single linter pass can miss a regression its own fix introduces. Fixing a broken link and accidentally breaking the heading hierarchy on the same page is exactly the kind of thing a one-shot check misses and a recheck catches. The honest cost of that loop is the occasional build that takes an extra minute right at the end for no visible reason. People notice that minute. They don't notice the six agents that just finished arguing about their site. That's a fair complaint about the experience — I just don't think it's a good argument for shipping without the argument having happened at all.
