Frontend Architecture for the Age of AI Codegen: Designing Code LLMs Get Right

The comforting story is that AI writes the code now, so designing boundaries and contracts matters less. After a year with assistants in the loop daily, I believe the opposite. An LLM predicts the most likely code given what it can see - your files, types, naming. When the architecture is clear, the likely completion is the correct one. When it is ambiguous, the model fills the gap with a plausible guess, and a plausible guess is exactly the kind of bug that passes review.

A vague API used to cost you one confused teammate. Now it costs you a confidently wrong assistant generating the same mistake across fifteen call sites before lunch. Bad architecture got more expensive; good architecture got more leveraged.

I learned this by accident. I spent a week writing a careful instruction file - conventions, do-nots, examples. Output barely improved. Then I deleted one folder of stale, half-migrated components nobody used, and quality jumped noticeably. The model had been copying the dead patterns because they were right there in the files it opened. My instructions were a footnote; the repo was the real prompt.

It is an observation, not a creed: the assistant matches surrounding code far more reliably than the request I type. So the highest-leverage move is to make the surrounding code unambiguous - one obvious place per concern, types that describe intent, and ruthless deletion of dead patterns. The same legibility that lets a new hire infer the rules lets the model generate against them.

The bug that changed how I design props: I asked an assistant to add a loading state to a submit button. My Button had a loading prop; the model passed isLoading - a reasonable guess, a prop that did not exist. The type was permissive there, so nothing complained. It rendered, passed review (the diff looked human-written), and shipped. The spinner never showed, a user double-submitted a payment, and I heard about it from a support ticket two days later.

The model was not dumb. It guessed a plausible name and my API let it through. Three rules I now apply, walk through them below: force a discriminated union when a component has more than one mode, require props that only make sense together, and never accept a bare string where you meant four specific values. If the AI could guess a prop name and be wrong, the API is too loose.

AI is confidently fluent about responses it has never seen. Ask it to render a profile and it will reach for user.avatarUrl, user.profileImage, or user.photo depending on the phase of the moon. None throw at generation time - they throw in production, as a broken image and a silent log.

A shared contract closes the whole category. Define the shape once (Zod, tRPC, a generated client) and reference it from both sides; when the assistant invents a field, TypeScript rejects it before the PR opens. It is the highest-return guardrail you can add - the full version is in "API Contracts Between Frontend and Backend."

"We will just review it carefully" does not survive contact with reality. The volume is too high and the output is too plausible - it looks right, which is exactly what makes manual review fail. Move correctness out of human attention and into the machine: a stack of nets, each tuned to a different failure mode, cheap, running in CI, never tired. Click through which net catches which mistake below.

Human review then focuses on the one thing machines cannot judge - is this the right thing to build at all. And the AI-era twist on testing: tests now double as the spec you hand the assistant. Write the test first, let the model generate until it goes green ("Testing Strategy for Frontend Architecture").

If the assistant writes the component, what is left? The judgment calls: where does this state live and who owns it, what is the contract between these services, is this a new component or a composition of existing ones. These - the questions in my "Frontend Architecture mental model" - depend on context the model does not have: the roadmap, the team, the tradeoffs nobody wrote down.

That is the more interesting half of the job. The tedious part - wiring the form, mapping the array, the ARIA attribute - is increasingly handled; what remains is design. So if you are choosing what to get good at: learn architecture. Prompting has a ceiling; architecture is what makes every prompt, and every engineer, more effective.

Guardrails are not a force field. Mine have failed, and the honest cases teach more than the theory - three that cost me something real:

The seam between two nets. An AI component read a config value that was always set in test fixtures but optional in production. Types were happy, tests were green, review waved it through - it only broke for users whose config omitted the field. The fix was not "more tests"; my fixtures were lying, so I now generate test data from the same schema that guards production.

The guardrail I trusted too much. I had an ESLint rule banning cross-boundary imports and leaned on it so hard I stopped reading import diffs. The model routed a forbidden dependency through the one path the rule missed - a re-export barrel. Zero violations reported. A quiet linter is not an intact architecture.

When the AI was right and I was wrong. I kept "correcting" an assistant that wanted to colocate data fetching in a feature - until I checked why it insisted, and found the codebase had already moved to server components, where that is correct. The model read the newer code more honestly than I read my own stale rule. I changed the architecture, not the output.

You do not need a migration project to get most of this value. Pick the friction you feel most and tighten it. Each item below makes both your AI assistant and your human team measurably more reliable.