Prompt In, Website Out

One text message from a phone can come back as a working site. Here is the assembly line that makes that possible. Click any station on the conveyor (or the buttons), and flip the prompt switch to see how input quality ripples through every stage.

Output quality
62%
specific prompt
click a station · drag to orbit · scroll to zoom

Prompt quality

Pipeline stages

Why agents beat single-shot generation

Early code models emitted one blob of code and hoped. Modern agent pipelines loop:

  1. Plan before writing - decompose into pages, components, data.
  2. Generate in slices small enough to reason about.
  3. Run and inspect the result: execute tests, render the page, read console errors.
  4. Self-correct - feed the errors back in and patch. Loops of write-run-fix are why an agent can be trusted unattended while you get coffee.

The 3D conveyor above is honest about one thing: quality is decided mostly at the leftmost station.

Anatomy of a strong build prompt

  • Audience and goal: "landing page for a dog-walking service targeting busy professionals" beats "make me a website".
  • Concrete inventory: list sections - hero, pricing (3 tiers with prices), FAQ, contact form.
  • Constraints: single HTML file, no frameworks, mobile-first, loads under 1 second.
  • Look and feel: two or three adjectives plus a palette ("warm, playful; cream and forest green").
  • Acceptance test: "the form must validate email format and show a success state". Testable statements become the agent's checklist.

What still goes wrong

FailureCauseFix
Beautiful but wrong contentModel invented facts you never suppliedPaste real copy, prices, names into the prompt
Works on desktop, broken on phoneNo viewport constraint statedSay "test at 380px width" explicitly
Placeholder images everywhereAgent has no asset accessProvide URLs or accept generated SVG art
Half-finished featuresScope too big for one passShip core first, iterate with follow-up prompts
Security holes in formsGenerated backend trusted user inputAsk for validation and review anything server-side

The mobile-prompt workflow

Phone-to-production works because the pipeline is asynchronous:

  • Your prompt is queued to a cloud agent with a full dev environment - shell, browser, test runner.
  • The agent works for minutes unsupervised; you are not holding a connection open.
  • Result arrives as a preview link plus a diff or repo commit, so review happens on your schedule.
  • Best practice: send the specific version of your idea the first time. A round-trip you avoid is 10–30 minutes saved - mobile prompting punishes vagueness more because iteration is slower.

Stage-by-stage timing (typical)

StageTimeToken cost share
Prompt intake + plan10–30 s~5%
Scaffold structure10–20 s~10%
Code generation1–5 min~50%
Test + self-repair loops1–10 min~30%
Deploy + preview URL10–60 s~5%

Self-repair time is the wildcard: a vague prompt can triple it because the agent iterates against guesses instead of requirements.

Glossary

  • Scaffold - the empty skeleton: file layout, HTML shell, build config, before real logic exists.
  • Context window - how much of your project the model can see at once; agents manage it by reading only relevant files.
  • Self-repair / reflection - feeding runtime errors back to the model as a new prompt.
  • Preview deploy - a throwaway URL per build so you can judge the result before it touches production.
  • Acceptance criteria - testable statements in your prompt that the agent can verify mechanically.
Enjoy this tool? Build your own with Super