How AI Has Reshaped Frontend System Design and Interviews

A chat assistant feels broken long before it actually fails. A user types a question, presses “Enter”, and waits through silence while the model thinks, streams half an answer, gets canceled, or returns text that sounds confident but does not fit the UI. That gap between click and trust now belongs to the frontend.

This lesson treats that problem as a System Design problem. In older frontend flows, the browser sent a request and rendered a mostly deterministic payload when the server responded. In AI interfaces, the browser must coordinate variable latency, partial output, cancellations, retries, and trust signals while the answer is still forming.

The scope here stays on architecture. The next lesson will cover how roles, tooling, and interview expectations changed, but this lesson focuses on the boxes, states, and control points a frontend engineer now owns directly.

You need to reason about inference placement, stateful streaming components, generative UI constraints, and latency vs. quality trade-offs. Once those four pieces are explicit, AI frontend design becomes discussable in the same structured way as caching, rendering, or data fetching. That framing leads directly into the architecture itself.

The new considerations in frontend architectures

Once AI enters the request path, the diagram gains several new boxes. A plain component tree plus API client is no longer enough because the browser may need to stream output, validate it, cancel it, or reroute it to another inference path.

Use this architecture vocabulary when walking through the system.

• Browser client: The browser collects user input, renders partial output, tracks life cycle state, and owns visible trust cues.

• Backend for frontend: A BFFA server layer tailored for one client experience that proxies APIs, hides secrets, and reshapes responses. often routes prompts to models and enforces policy.

• Edge worker: An edge runtime executes logic near the user to reduce round-trip delay, and on platforms with edge-hosted compute, may run small models directly.

• Model provider: The inference service generates tokens or structured output and may support streaming.

• Structured output validator: A validator checks whether model output matches a schema before the UI renders it.

• Stream transport: The transport carries partial output using mechanisms such as SSE or WebSocket and feeds the parser incrementally.

• UI state machine: The client tracks explicit states rather than a few booleans.

• Cancellation controller: The browser must stop in-flight generation cleanly and release resources, typically via an AbortController tied to the fetch or stream, so a canceled request stops consuming tokens and doesn't leak a dangling connection.

• Optional in-browser runtime: WebGPU or WASM can host a local model where browser support and device memory allow, when privacy or speed justifies the trade-off.

Three inference topologies

A simple comparison makes the shift easier to reason about.

The topology changes what the frontend can promise the user, but choosing a path isn't a one-time decision. The browser first checks what it can do (capability detection), decides where a request should go (fallback routing), and prepares to handle whatever comes back (a streaming parser, a cancel action, and schema validation on the result). Only then does the request actually reach cloud, edge, or on-device inference. If validation fails, the router can send the request down a different path rather than surfacing a broken response.

With those boxes in place, the next step is to see where older frontend assumptions stop working.

Where classic assumptions break

Classic frontend design assumed a fetch returned a deterministic payload, then the page rendered success or error. AI breaks that contract in several ways at once. Output can be uncertain, latency can vary by seconds, tokens may arrive incrementally, and local models may spend more time downloading or warming up than generating.

A richer life cycle appears in the client. Instead of idle, loading, success, and error, the system may pass through downloading, initializing, warming up, ready, streaming, complete, canceled, and error. A spinner alone hides too much. Users need signs of real progress and a way to stop the operation.

The failure modes also change the component design.

• Mid-stream moderation block: The stream starts normally, then policy filters cut it off and the UI must explain the interruption.

• Partial structured output: The model emits some valid fields but never completes the schema.

• Invalid schema: The output parser rejects malformed JSON or missing required fields.

• Hallucinated content: The text looks fluent but does not match citations or product rules.

• Device-specific collapse: A local model loads, then performs poorly because memory or GPU bandwidth is insufficient.

The frontend responds by separating shell rendering from answer rendering. The page frame, input controls, and prior messages stay stable while partial answer state remains isolated inside the assistant panel. That isolation protects layout stability, memory usage, and trust indicators such as citations or retry controls. Those life cycle details are easier to model with explicit states than with scattered flags.

Once the states are explicit, the frontend gains several new control levers.

The new design levers

The browser cannot remove model uncertainty, but it can control how that uncertainty reaches the user. That turns frontend design into a sequence of operational decisions around pacing, validation, and fallback, and the simplest of those decisions is also the most effective: if the user sees useful progress early, the system feels faster even when total completion time stays the same.

The client can mask delay in several concrete ways:

• Skeletons and shell-first rendering: The shell appears immediately while the answer region reserves stable space, so the layout never jumps once content arrives.

• Token streaming: The model streams partial text so the user sees the response take shape as it’s generated, rather than waiting for it to complete.

• Buffered chunk rendering: The client batches several tokens before each paint, trading a small amount of latency between visible updates for less jitter and layout churn.

• Explicit stop controls: The user can cancel generation at any point, which stops wasted tokens and hands control back to them.

• Progress states for local models: Download, initialize, and warm-up stages show meaningful, distinct progress instead of one generic spinner.

Pacing solves how fast something appears. It says nothing about whether what appears is safe to render, and that's a separate problem once the model's output stops being plain text. Free-form streaming is easy to prototype but hard to govern, since anything the model produces gets rendered as-is. Structured output streaming avoids that by having the model emit cards, citations, or component descriptors instead, which the client validates against a schema before render. That validation acts like airport security for UI data, it slows the line slightly, but it prevents dangerous items from getting through.

Safe generative UI and placement trade-offs

Generative UI should not render arbitrary HTML from the model. The safer pattern maps model output into a fixed component catalog with validated props. The model chooses from known building blocks, and the client renders only allowed components. That keeps auth gates, billing actions, and irreversible side effects outside model generation.

The placement decision then becomes numerical rather than philosophical.

• Local fast path: A small quantized classifier can respond in under 100 milliseconds for autocomplete or privacy-sensitive labeling.

• Remote reasoning path: A cloud model may take multiple seconds but produce better reasoning and citations.

• Split execution: The browser handles capability detection, preloading, caching, and simple local tasks, while the server handles expensive reasoning and policy checks.

Those design levers are exactly what interviewers now expect candidates to articulate.

How the interview changed

A strong frontend System Design answer now goes beyond component trees and API calls. The candidate should state where inference runs, what latency budget the user experiences, how TTFTTime To First Token differs from full completion time, and how each component behaves while output is partial or uncertain.

Consider a document assistant for web and mobile web. The request enters an input panel, the browser starts a stream, citations appear in a structured sidebar, and follow-up suggestions render only after schema validation succeeds. Under poor networks, the UI may buffer tokens before paint, expose stop and retry controls, and degrade to plain text if richer cards fail validation.

Interviewers usually listen for a few high-signal trade-offs.

• Cloud vs. local inference: The answer should connect placement to privacy, capability detection, and fallback.

• Schema-validated UI vs. arbitrary text: The answer should define how unsafe or malformed output is contained.

• Buffered rendering vs. token-by-token rendering: The answer should connect smoother layout to perceived responsiveness.

• Weak-device fallback: The answer should describe what happens when GPU or memory support is limited.

A life cycle view often makes those trade-offs easier to explain, especially the parts that are easy to skip over in prose: what happens after a cancel, and what happens after an error. The diagram below treats both as real states with their own path forward, a cancelled or failed local session can still fall back to cloud inference and restart the sequence from there, rather than leaving the user stuck.

One last performance note sharpens how to discuss these systems under interview pressure.

Conclusion

Classic frontend design assumed deterministic APIs and mostly complete responses. AI systems move streaming, uncertainty, cancellation, and device-aware inference into the browser, so the frontend now owns latency masking, partial rendering, schema-safe UI, and graceful fallback. For interviews, keep one mental sequence in mind: choose topology, define the state machine, describe fallback behavior, then quantify latency and quality trade-offs. The next lesson builds on that architecture and shows how roles, tools, and interview signals changed with it.