Stop building
from scratch.
AI Studio Build spends 4–5 minutes generating every app greenfield under a 184-page instruction. We propose a cascade: a short ideation exchange routes each request onto a canonical starter codebase, and the model transforms it instead of re-inventing it. Modeled effect: 25–50 s end-to-end, first pixel in ~15 s, quality up.
Build already generates against one frozen, invisible template — tsconfig.json and vite.config.ts are byte-identical across all 45 audited apps, and the dead AI/server scaffold ships in 45/45, including offline unit converters. The question is not whether to use canonical codebases. It is whether the canonical codebase stays one, hidden, and wrong by default — or becomes a small selected family, visible to an ideation step. Every competitor that ships at scale has already chosen.
Latency is output tokens
A 4–5 minute build isn't slow infrastructure — it's autoregressive decoding of 25–50k output tokens at ~180 tok/s (Gemini Flash class). Prefill of the 184-page prompt and thinking cost little wall-clock. The one lever that dominates is generating fewer tokens — exactly what starting from a canonical codebase does.
The cascade
- Routesmall model · 1–3s
Classify the prompt on three axes: chassis family, capability modules, design genre. Low confidence → one clarifying question, or fall through to generic. Never block the happy path.
- Blueprintstreamed, auto-proceeds
Name, features, family, modules, theme — visible and editable, but generation starts immediately. The one-prompt magic survives.
- Scaffold0 LLM tokens
Copy the canonical chassis + selected modules + theme tokens. Instant, pre-tested. Dead deps die here;
ErrorBoundary, format utils, reduced-motion arrive for free. - Transformbig model · thinking-off
Slim per-family cached prompt (~10–15k tokens). The model emits only app-specific files, whole-file, sequentially — coherence is structural, not repaired after the fact. 5–15k output tokens instead of 25–50k.
- Gatelint + fixer · 5–10s
Deterministic checks (render,
transition-all,100vh, title, model-ID allow-list, phantom classes) + a small streaming autofixer — the proven move (93.9% error-free). - Previewshell-first
The scaffold is real from second zero, so the shell renders immediately and hydrates as files stream in. First pixel < 15s.
The taxonomy — three axes, not one list
A flat list of "app types" conflates three orthogonal decisions: chassis (a game vs a resume), modules (a notes app and a shop can share a chassis), and design (two SaaS landings differ only here). Routing each axis separately holds the maintained repo count at two while covering the long tail compositionally.
Seven user-facing families, each a composition preset (module bundle + layout shell + instruction module) on just two maintained repos: a universal web chassis, and a canvas/game chassis for rAF loops where the DOM is the wrong runtime. Two repos, not seven, keep maintenance small and make a preset misroute a styling error, not a broken build.
Pre-tested drop-ins: persistence, auth, AI proxy, realtime, payments, charts, routing, PWA, export. Each = a folder + its instruction snippet + its deps. Dependencies become conditional — the dead-scaffold defect dies on this axis.
The 23-genre routing table + 10 named themes from the DESIGN axis, validated by the 6-rater blind panel. Conditions style only — never the chassis. The existence proof that genre routing works.
Routing rule: the only structurally binding call is binary — DOM app vs game loop (>95% separable). Family presets route with calibrated abstention: below the confidence floor, ask one question or default to the bare universal chassis — a safe landing, never a broken one. The blueprint shows all three axes in plain language and doubles as the correction surface.
Prove it — the experiment
A proposal to be tested, not asserted: a within-subjects A/B with the prompt as the unit, the same OFF/ON twin method that produced our 0/10→10/10 instruction result (McNemar p≈0.002). The outside-in arm runs from the downloadable artifact now; the inside-out arm needs the real prompt distribution and pipeline instrumentation only the internal stack has.
| Metric | Today | Cascade target | Who measures |
|---|---|---|---|
| Time to first preview | = total build | < 15 s (shell-first) | either |
| End-to-end build | ~270 s | 25–50 s | either |
| Output tokens / build | ~25–50k (modeled) | 5–15k | real stack confirms |
| Dead-dependency rate | 87–91% (measured, n=45) | 0% (conditional deps) | either |
| 12-dimension scorecard | F–B− (measured) | ≥ current, no regressions | either |
| Router coverage / misroute | — | >95% binary; abstain below floor | real prompts only |
Dead-dep rate, the scorecard, and defect classes are measured on our 45–157-app corpus. Latency and token counts are modeled — exactly what one instrumentation pass turns into ground truth. The claim is the method, not the numbers.
The evidence frozen template · the market · the 184-page prompt
Build already has a template — one, frozen, wrong
From our 157-app probe corpus (16 rounds, downloaded zips only), the tech-stack audit of 45 apps:
- 45/45 —
tsconfig.jsonbyte-identical md5 8827451c… andvite.config.tsbyte-identical md5 9c319043… - 91% dead —
@google/genaideclared in every app, imported by 4.express87% dead,dotenv91%,autoprefixer100%. - 45/45 —
SERVER_SIDE_GEMINI_APIflag ships even in a "simple offline unit converter." - 0/45 — strict TypeScript. 0/157 — an
ErrorBoundary, by default.
The chassis is already canonical — just invisible, unconditional, and wrong by default. Making it plural and selected deletes a whole defect class: dead deps become conditional on selection.
Nobody who ships at scale does greenfield
| Product | Starting point | Pre-code stage |
|---|---|---|
| Lovable | One fixed template (Vite/React/shadcn + Supabase) — never greenfield | Plan mode, clarifying questions, design-system-first |
| Same.dev | A literal startup tool — 8 enumerated templates incl. a SaaS boilerplate | Template selection is the first tool call |
| Firebase Studio | Per-framework workspace templates | Editable blueprint (name · features · style) before any code |
| Replit Agent | Curated app-type templates, later + escape hatch | Plan approval, design-first mockups, verifier agents |
| Orchids | Pre-initialized Next.js + shadcn project | Router → design-system generation → coding handoff |
| v0 (Vercel) | No template — Next+shadcn baked into weights + RAG | None. The counter-example — works because the domain is narrow |
Iteration is transform-based everywhere already — search-replace edits, small fast apply-models, scoped annotation edits. The fastest loops come from precomputation: warm scaffolds, cached prefixes (~90% cache efficiency), one-time design-system indexing.
184 pages is a quality bug, not just a cost bug
- ~68% adherence — best frontier models, at 500 simultaneous instructions (IFScale), with strong primacy bias. A 184-page rulebook is hundreds of directives; a large fraction is silently ignored today.
- Lost in the middle — U-shaped attention puts most of a 90k-token prompt in the dead zone.
- Our Set-F law — concrete rules stick (reduced-motion 0/9→5/5); pure prohibitions don't (
transition-allsurvived 4/5). Prohibitions belong in a deterministic gate, not prose.
The cascade dissolves the monolith instead of compressing it: a core correctness block (our v4 is 94 lines, paired-proven 0/10→10/10) + one small module per family + the theme block. Each variant is byte-stable → a permanently cached prefix. The 184 pages get re-homed across instruction / lint / template / pipeline.
Design questions we pressure-tested chassis count · generation order · router safety
Before proposing the cascade we stress-tested it against its own weakest points — where a plausible design quietly fails at scale. Three questions decided the final shape; each answer made it smaller and safer.
- One chassis, or a family per app type? Seven starter repos × ~10 modules is ~70 surfaces to keep current across every framework release — the "template rot" that sank earlier scaffolders. Resolution: two maintained chassis (universal web + canvas/game), with the seven families surviving as composition presets. Maintenance collapses to 2 × modules; a preset misroute becomes recoverable styling, not a dead end.
- Generate files in parallel, or in sequence? Parallel per-file generation assumes files are independent; they aren't — shared types, imports, and routes make cross-file coherence the hard part. Resolution: sequential whole-file generation with the template as a speculative draft keeps coherence structural. Parallel fan-out is demoted to a gated experiment.
- Can a small model silently pick the start? General intent routers land around 70–83% exact accuracy on messy traffic — too low to bind structure blindly. Resolution: the only structurally binding call is binary (DOM vs game loop, >95% separable); everything else routes with calibrated abstention — below the floor, ask one question or default to the bare universal chassis.
Two open trade-offs we're holding. Speculative/fast-apply decoding accelerates transforms most where output matches the template prior — so we model 2–5× on transform-heavy files, not everywhere. And distilling the instruction set into model weights is promising but unproven at ~90k-token scale — so it stays staged behind slimming the prompt first.
Honest risks misroute · sprawl · the magic · homogenization
- Misroute cost. A wrong structural start is worse than greenfield → the binding decision is binary (DOM vs game loop), presets fail soft on the universal chassis, and the visible blueprint makes any routing call correctable in one click.
- Template sprawl. The gallery failure mode → exactly two chassis repos; families are module presets, so the matrix is 2 × modules, all CI-tested against the gate on every framework update.
- Multi-step kills the magic. The real warning → the cascade is invisible by default; one prompt still yields one app, faster.
- Homogenization. Starters could flatten output → the design axis is the counterweight; theme conditioning turns one chassis into thousands of distinct apps.