Describe It, and Ship It: AI-Assisted Frontend at Scale

AI-generated frontends are easy to produce and historically easy to throw away. They look right in a demo, then collapse the moment you ask them to live in a real codebase: no data wiring, no accessibility, design tokens ignored, one giant component where there should be fourteen. The prototype is a sketch, and the production version is a rewrite.

We recently overhauled a complex post-purchase experience, a risk-monitoring surface inside our customer dashboard, and used it to test a single claim: that the throwaway gap is not a property of AI-generated code, it’s a property of a codebase the agent can’t read. Make the surface legible to the agent, the argument goes, and “describe it, the agent builds it, ship it” stops being a demo trick and becomes a real pipeline. The premise was deliberately blunt. An engineer describes the UI in plain English, an AI coding agent generates real React code, and it ships to production behind feature flags.

It worked. Everything that follows is an argument for why, and the why is always the same: the agent succeeded to the exact degree that we had made our conventions readable to it.

What “shippable” actually demanded here

The experience we were rebuilding was genuinely hard to get right. It surfaces a customer’s risk profile across several categories, and the redesign needed three things at once: a richer information architecture, a custom data visualization as its centerpiece, and live wiring to each customer’s plan entitlements so we could offer the right next step.

The old implementation was a single monolithic desktop component. The new one needed to become a tabbed, three-pathway architecture, self-serve, done-for-you, and expert assistance, with the centerpiece being a custom radar chart that plots each risk category as a tier-colored dot (high, mid, low), with a pulsing animation, per-category tooltips, and a clear call to action.

That is exactly the kind of work where AI prototypes usually break down. A demo radar chart is a weekend afternoon. A production radar chart is keyboard-navigable, screen-reader-labeled, fed by real risk data, styled with design-system tokens rather than hand-rolled CSS, and decomposed cleanly enough that the next engineer can extend it. Notice that every item on that list is a convention the codebase already holds. The hard part was never generating the code. It was making the codebase’s standards available to the thing generating it.

Encoding the rules into the surface, not the prompt

So our core decision was to stop treating the AI as a one-shot mockup generator. The discipline that normally gets retrofitted in code review, token compliance, component reuse, real service wiring, we moved upstream into the generation step itself, as rules the repo carries rather than instructions a human remembers to type.

The local loop looks like this:

1. Spin up an isolated git worktree for the experiment
2. Start a branch-scoped local dev server with its own preview URL
3. Describe the desired UI in plain English to the agent
4. Iterate conversationally; the agent regenerates real React
5. Publish: commit, push, open a draft PR, attach an
   ephemeral-deploy label, return a live preview URL

Each experiment gets its own worktree and its own preview server, so multiple ideas run in parallel without colliding. All of it is feature-flagged from the first commit, so prototype code never reaches a real customer while it’s being explored.

The part that carries the whole thesis is what the generation step enforces automatically. Before any code is pushed, the agent’s repo-local rules require:

• A component-reuse audit: prefer existing components over net-new ones.
• Design-system token enforcement: typography and color come from our tokens, not ad-hoc values.
• Custom-CSS guardrails: hand-written CSS is the exception that must justify itself.
• Mandatory use of the app’s shared API clients for loader data, so data fetching follows the same pattern as the rest of the app.
• A pattern-detector scan plus an auto-fix pass that must clear typecheck and lint before anything leaves the machine.

This is the lever. Asking an AI to “use our design system” in a prompt is fragile, because the prompt is a hint and the agent is free to ignore it. Encoding token discipline, component reuse, and API-client usage into the repo’s rules makes the right output the default output. The agent reaches for useMemo, useId, and sensible component decomposition not because we got lucky with a prompt, but because the surface it generates against pushes it there. And when an engineer publishes, a stakeholder gets a live URL with zero setup: no branch to check out, no local environment to build. They review the actual running experience, not a screenshot.

The safety rails were already legible, so they stayed

A 14-component overhaul is not one reviewable change. We shipped it as a stacked series of PRs, each independently reviewable and each gated behind the same feature flag, with a query-param override so we could exercise the new experience in any environment without touching targeting. The content-and-styling overhaul, for instance, was the fourth PR in a six-PR stack: a discrete, readable diff rather than a 4,000-line wall.

This is the same argument in a different register. Small diffs, independent review, flag-gated rollout are conventions our process already understood, so they cost nothing to keep. We didn’t trade them away for speed. The agent got us to good, reviewable code faster, and then that code went through the gates we always run. The flag gave us a clean rollout and a clean rollback. The stack kept each diff legible to a human reviewer, the same way the repo rules kept the codebase legible to the agent.

Where the agent couldn’t read, review had to

The agent got it roughly 80% of the way there. The remaining 20% is precisely the part that no convention had made legible yet, which is why review closed it. Two examples are worth being specific about.

Entitlement wiring. The expert pathway needs to choose between a “schedule a call” action and an “add to plan” upsell, depending on what the customer is already entitled to. The first generated pass hardcoded the entitlement flag, a perfectly demo-able shortcut that would have been wrong in production. Review caught it, and we replaced the constant with live entitlement data pulled from the route loader. The prototype looked right; only review knew it wasn’t true. Truth about runtime state is not something the static surface could hand the agent.

Accessibility. The radar chart’s interactive dots initially worked with a mouse and nothing else: no tabIndex, no roles, no labels, no focus handling. A custom SVG visualization is the kind of component where accessibility is easy to skip and hard to bolt on later. Review flagged it, and we hardened the chart with full keyboard navigation and ARIA roles, labels, and focus management. A visualization that only works for mouse users isn’t finished, no matter how good the demo looks.

Neither of these is a failure of the approach. They map the boundary of it. Where the codebase made a rule legible, the agent honored it; where the requirement lived in live state or in judgment, a human carried it. The work moved from typing boilerplate to reviewing for state correctness and accessibility, the things that are genuinely hard and genuinely matter.

That boundary also shows up in product judgment. On the radar chart, risk categories the customer hasn’t assessed are plotted as high priority, not as a neutral “not assessed” state. Unknown risk is treated as high risk. The neutral framing was easier to defend visually, but it quietly understated exposure, so we chose the framing that nudges customers toward closing real gaps. That call had nothing to do with AI. The agent generates the how; the should is still ours.

The bottleneck moved to wherever the surface goes dark

So the lesson generalizes cleanly from this one screen. Generation got cheap, and the scarce work relocated to exactly the places the agent cannot see for itself: clear specification, convention enforcement, and high-signal review of state correctness and accessibility. Engineering judgment didn’t disappear. It moved to architecting the rules the agent reads and reviewing the things that don’t show up in a demo.

For validated ideas, this compressed UI ideation-to-deployment from sprints toward days. One validated idea went from concept to production in about a day, built overnight, shared the next morning, no meetings required, because the prototype was the production code, minus the review pass. That speed is downstream of legibility, not the other way around: the prototype was already production-shaped because the surface it grew on enforced production shape.

This pattern has spread across our engineering org as part of a broader shift in how we build software with AI. The frontier now isn’t generating more components faster. It’s widening the band of things the surface can make legible, so the agent learns our conventions, surfaces its own uncertainty, and flags the entitlement-wiring and accessibility gaps before a human has to. We’re not there yet. But the durable result holds: AI doesn’t replace engineering judgment, it relocates it to the seams the codebase can’t yet describe to a machine.