AI generates 70% of a frontend feature in minutes — the layout, the markup, the plausible styling. The last 30% — edge cases, interaction polish, accessibility, performance, design fidelity — is where the product lives, and it stays yours. This module installs the operating posture for that split.
Meera, a senior frontend engineer at a payments startup, needs a usage-dashboard section shipped by Friday.
She prompts v0 with the ticket text and a screenshot. Ninety seconds later: a beautiful, responsive dashboard. Cards, a chart, filters. It looks done.
She ports it into the app, adjusts a few colors by eye, opens a PR. The diff is 640 lines. Tests pass. Preview deploy looks great.
Design review: the card padding is 20px, the system says 24; the chart uses raw hex colors, not tokens. Two components duplicate primitives the design system already ships.
Accessibility bot: the filter chips are divs with onClick. No keyboard path, no roles, no focus states. The "Export" control is a styled span.
QA: the empty state renders undefined items, the error state doesn't exist, and on a 360px viewport the chart overflows the card.
Generation took 90 seconds. Making it shippable took a day and a half — most of it re-discovering requirements the generator never knew existed.
Nothing malfunctioned here. The tool did exactly what prompt-to-UI tools do: it produced the plausible 70% at astonishing speed. What Meera skipped was the senior move — deciding in advance which parts of the output were raw material and which parts of the job the generator cannot see. Edge states, keyboard behavior, token discipline, responsive breakage, design-system reuse: none of these appear in a screenshot or a ticket, so no model will reliably produce them. Addy Osmani named this the 70% problem, and it is the single most useful lens for frontend AI work: AI compresses the first 70% dramatically, while the last 30% — the part users and auditors actually experience — still requires an engineer who knows what "done" means.
You already hold the Common Core: prompting, context, verification, trust tiers. This module specializes all of it to pixels, gestures, browsers, and devices — the domain where "almost right" is visible. The market context makes the stakes concrete: frontend interviews at product companies and GCCs now put candidates in front of AI-generated React/TypeScript and score whether they can read it, catch its defects, and fix it. Company mandates (Coinbase-style "AI use is mandatory, every line human-reviewed") assume you can do this daily. This track exists because no other curriculum teaches it for the frontend role — and this module is its frame.
In frontend work, AI's 70% is the part that was never the hard part. Layout scaffolds fast; edge cases, accessibility, fidelity, and interaction quality were always the senior engineer's job — and they still are. Route work accordingly.
The generic SWE payoff map (bounded scope, cheap verification, low blast radius) applies, but the frontend version has its own topology, because UI output has two verification surfaces: does the code work, and does it look and feel right. A model can satisfy the first and fail the second invisibly — until a designer, a screen reader, or a 360px viewport finds it.
The burn zone is not "AI is bad at CSS." It is: the frontend's acceptance criteria — fidelity, accessibility, feel, performance — live outside the text the model sees. Any workflow that doesn't route those criteria back into the loop (via tokens-in-context, screenshots, traces, or audits) ships them broken by default.
Prompt-to-UI tools moved prototyping from days to minutes, and that speed is only safe under one discipline: an explicit boundary between what the tool explores and what your repo ships.
v0 explorations, Claude artifacts, layout alternatives for a product debate, spike branches testing whether a virtualized table can hit 60fps. Value = what it teaches. Verification beyond "did it answer the question?" is waste. Harvest the decisions — layout, hierarchy, interaction idea — and delete the code. Label branches spike/; they never open PRs.
Anything that merges: built from your primitives, styled by your tokens, every interactive element keyboard-reachable, every async state present, reviewed under your name. The prototype's markup does not "port" — it gets re-implemented with the design system, because porting imports every off-system choice the prototype made invisibly.
The dangerous moment is identical to the backend version but faster, because UI prototypes demo so well: a v0 screen that wowed the product review gets "can we just ship this?" within the hour. The senior answer: the demo proved the layout communicates — feasibility, not correctness. Crossing the boundary re-tiers the artifact, and the production checklist (types, tokens, a11y, states, tests) runs from scratch.
A prototype that survives a product demo has proven the happy path renders. Empty states, error states, keyboard paths, RTL layouts, 360px viewports, and token compliance are precisely what prompt-to-UI skips — and precisely what production means.
Reviewing AI-generated UI is now a named job duty — postings say "review and fix AI-generated React/TypeScript," and interview loops simulate it. Generic code review misses the frontend-specific failure modes, so this track's operating instrument is a provenance checklist tuned to how UI generation actually fails. Run it on every PR you suspect (or know) is model-authored — including your own:
<Button variant="subtle"> on systems that have no such variant. IDE resolution plus a registry check settles it in seconds (M2 wires this into generation itself).Lab 09 gives you a 700-line AI-generated PR with all of these seeded, on a 45-minute clock — the same shape as the interview format.
Assessment scenarios for this domain describe a generated PR and ask what you check first. The high-scoring order is existence (hallucinated APIs) → states → accessibility → styling discipline → performance: cheapest-to-verify and highest-blast-radius first.
Personal discipline decays under deadline; mechanical gates don't. The minimum viable policy for a team shipping AI-generated UI is three gates plus one disclosure, all automated or checklist-enforced:
| Gate | Mechanism | Catches |
|---|---|---|
| Types & lint | CI typecheck + ESLint (incl. rules-of-hooks, no-restricted-imports on off-system paths) | Hallucinated APIs, off-system imports, effect misuse |
| Accessibility | axe-core in CI (jest-axe / Playwright axe) + manual keyboard pass on new surfaces | Div-buttons, missing names, focus traps |
| Visual diff | Screenshot tests (Playwright/Chromatic) on changed components | Fidelity drift, responsive breakage, token regressions |
| Provenance disclosure | PR template: "AI-generated portions; what I verified; what I'm unsure of" | Review attention routed to the risky diff regions |
Teams that adopt these four report the same shift: review conversations move from "did you write this?" to "the gate flagged X, walk me through it" — provenance stops being an accusation and becomes routing information.
It is worth saying plainly why this role is more defensible in the AI era, not less. The frontend's acceptance criteria are human-experiential: does it feel right, read right, respond right, include everyone. Those criteria resist textual specification — which is exactly why models, trained on text, under-deliver them, and why the engineer who can close that gap is scarce. Design fidelity, interaction quality, accessibility, and perceived performance are judgment domains where verification requires taste plus tooling. Meanwhile a new surface area landed entirely on this role: the UI side of AI products — streaming chat, generative UI, on-device inference (M7–M8) — which no adjacent role owns. The engineers being hired at a premium are not the ones who generate UI fastest; they are the ones whose generated UI ships — on-system, accessible, fast, and correct — and who can build the AI-product surfaces everyone now wants.
Check yourself: Your tech lead sees your v0 prototype demo and says, "This is 90% done — polish it and ship it Friday." What is wrong with the "90%" and what do you actually commit to?
This module's companion playbook is pb-01 (Prompt-to-UI Exploration with a Throwaway Boundary) — the disposable-side workflow done with discipline. The provenance checklist becomes muscle memory in pb-28 (Frontend Provenance Review of AI-Generated PRs) and is tested under time pressure in Lab 09, the seeded-defect PR review. Everything else in this module — conditioning generators (M2), fidelity review (M3), gates (M5) — is where the track goes next.
Generation is no longer the job. The AI-native frontend engineer routes work by the 70/30 lens, keeps prototypes disposable, re-implements on-system, and reviews every generated diff against the provenance checklist — because the last 30% is what users experience, and it has your name on it.