Building AI Surfaces: Chat, Streaming & Generative UI

Nisha's three days compress the entire discipline of AI-surface engineering: the difference between a demo and a product is streaming mechanics, security architecture, and state design — all of it frontend work, none of it in the model. This is also the least-substitutable skill set in the track: the chat panel is the one surface where your users directly experience the model, and every deficiency — buffering, thrash, injection, a spinner where reasoning should be — is attributed by users to "the AI being bad." The frontend engineer who owns this layer owns the product's AI reputation.

What You'll Learn

• The streaming chat surfaceSSE, useChat, typed message parts, stop/regenerate, scroll anchoring
• Prebuilt AI componentsAI Elements and assistant-ui, restyled onto your system
• Streaming resiliencetoken batching, cancellation, resume, chaos-tested failure UX
• Generative UItyped tool parts mapped to real design-system components
• Client securityBFF proxy, output sanitization, zero authorization in prompts
• The AI UX state matrixthinking, uncertainty, refusal, feedback — wired into the eval loop

The Streaming Chat Surface

Streaming is not a nicety — it is the difference between 500ms-to-first-token and 9-seconds-to-anything, and users experience that gap as product quality. The 2026-standard web stack: SSE transport (the AI SDK v5 standard — one-directional server-push fits completion streaming exactly; WebSockets buy bidirectional complexity you don't need for chat) into useChat or an equivalent hook managing message state, streaming status, and abort — rendering typed message parts. That last concept is the architectural one worth internalizing: a modern assistant message is not a string, it is a sequence of parts — text, reasoning, tool call, tool result, citation, file — each with its own type and its own renderer. Typed parts are what make everything later in this module possible: reasoning panels, generative UI, structured citations.

Around that core, four mechanics separate shippable from demo-grade, and all four are pure frontend craft:

• Markdown and code rendering, incrementalthe renderer must handle incomplete markdown gracefully (an unclosed code fence mid-stream), style code blocks with copy buttons, and never re-parse the entire transcript per token.
• Stop and regeneratestop aborts the stream and reconciles state to the partial response (users keep what streamed); regenerate re-runs the last user turn. Both are trust affordances: users forgive wrong answers they can interrupt.
• Scroll anchoringpinned to bottom while streaming, released the instant the user scrolls up to read history, with a jump-to-latest affordance. Fighting the user's scroll during a stream is the most-cited chat-UI irritation in the pattern literature.
• History persistenceconversations survive refresh (server-side persistence keyed to the session), which also sets up stream resumption below.

Assemble, Then Restyle: Prebuilt AI Components

Hand-rolling every chat primitive is 2024 behavior. AI Elements (Vercel, shadcn-based) and assistant-ui ship the assembled vocabulary — Conversation, Message, PromptInput, Reasoning, Tool, InlineCitation, Sources — as headless-first components designed to be restyled. The senior workflow: assemble the surface from primitives, then apply M2's discipline to bring it fully on-system — your tokens, your type scale, your motion — so the assistant panel looks like your product, not like a bolted-on chatbot. The build-vs-assemble decision is honest engineering, not fashion: assemble when your needs match the chat paradigm; hand-roll only the parts where your product genuinely diverges (and keep the transport/state layer from the SDK either way — that code is where the resilience bugs live, and it's battle-tested upstream).

Streaming Resilience: Engineering the Stream as State

A token stream is a long-lived, failure-prone, high-frequency state source feeding a render tree — treat it with the respect you'd give a websocket feed in a trading UI:

• Token batching against re-render thrashnaive implementations re-render per token: 60+ renders/second through a markdown parser, and mid-range devices melt (M6's INP lens applies). Batch stream updates on an animation-frame or small time window; measure renders-per-response before and after (Lab 11 requires exactly this measurement).
• Cancellation as a first-class pathAbortController wired from the stop button through the fetch to the proxy, which cancels the upstream provider call — otherwise "stop" keeps billing tokens server-side. State reconciliation after abort is part of the feature, not an edge case.
• Resumable streamsrefresh mid-generation should reattach to the in-flight response (AI SDK resumable-stream support plus server-side persistence), not orphan it. This is the difference between a toy and a tool users trust with long generations.
• The partial-failure contractstreams die mid-flight: network blips, provider errors after 400 good tokens, timeouts. Agree the contract with the backend (error events in-band on the stream), keep the partial text visible, and offer retry-from-here. Chaos-test it deliberately — kill the connection mid-stream and watch what the UI does; Lab 11's chaos drill is precisely this.

Generative UI: Typed Tool Parts to Real Components

The CTO's "can it render shipment cards?" is the frontier that makes this surface a product: generative UI. The architecture is a strict trust split, and getting it right is what separates the pattern from a security hole:

The payoff: answers become interactive product surface — a shipment card with live status and a reschedule button, not a text table — while every pixel stays on-system and every action stays inside your existing authorization. Lab 12 builds exactly this: two tools whose streamed results render as typed components with full per-part state handling.

Client Security: Never Trust Either Direction

The AI surface adds a twist to frontend security: you can trust neither what goes up (user input, which may be crafted to manipulate the model) nor what comes down (model output, which may carry injected content from anywhere in the model's context — including documents your RAG pipeline retrieved from the wild). The non-negotiables:

None of this is exotic — it is classic web security applied to a new data source. The mental model that makes it stick: model output is user-generated content from an untrusted user who reads everything and can be talked into anything. Render it accordingly, authorize around it accordingly. Lab 13 hands you a deliberately naive build — key in bundle, raw markdown injection, no rate limit — and passes only when the seeded XSS and injection payloads demonstrably die.

The AI UX State Matrix — and the Feedback Loop

Deterministic UIs need loading/success/error. AI surfaces need a wider matrix because the system has more ways to be partially useful, and each state is a designed experience, not a fallback: thinking (streamed reasoning or honest progress, never a bare spinner for 8 seconds), streaming (with stop), complete (with copy/retry/feedback), uncertain (the model hedges — surface the hedge honestly rather than styling it away), refusal (safety declines rendered as respectful product moments explaining what can be asked — not error styling), error/retry (transport failures, distinct from refusals), and empty (first-run suggestion chips that teach capability boundaries). NN/g-derived pattern research backs the matrix; Lab 14 requires implementing all of it in Storybook with a rationale per state.

Close the loop while you're there: thumbs, edit-and-resend, regenerate, and abandonment are eval signal — instrument them as structured events (message id, model/prompt version, conversation context, rating) shipped to the team's eval store. The frontend is the only place this signal exists; wiring it is how the product's AI actually improves, and eval literacy is a differentiator the JD data keeps flagging. Perceived-latency and cost levers round out the client's contribution: optimistic user-message echo, skeleton-vs-stream choices, prompt caching for repeated contexts, and routing trivial UI tasks (title generation, suggestion chips) to cheap models — the frontend's hand on the AI bill.

Try It Now

1. 1Prove streaming end-to-end. Build (or audit) a minimal chat route: open DevTools' network tab and confirm tokens arrive progressively as SSE events, not as one buffered response. If you see buffering, find which layer (proxy, framework, CDN) is aggregating — this is Lab 10's evidence artifact.
2. 2Audit your bundle for secrets. Grep your built client bundle (not source) for sk-, key, and your env-var prefixes. Then check what your markdown renderer does with <img onerror=alert(1)> in a model response. Twenty minutes; two potential incident classes.
3. 3Storyboard the refusal state. Write the actual copy and design the actual component your product shows when the model declines a request. If your current answer is "the error toast," you've found the state-matrix gap most products ship with.

Your playbooks & labs

This module's playbooks: pb-47 (First Chat Surface: useChat, SSE and Message Parts), pb-48 (Streaming Resilience), pb-49 (Generative UI: Typed Tool Parts to Design-System Components), pb-50 (Client-Side AI Security), and pb-51 (AI UX States and the Feedback Loop). Labs 10–14 chain into the track capstone: ship the streaming surface, harden it under chaos, make it generative, kill the seeded attacks, and design the full state matrix — the complete production AI surface, end to end.

Further Reading

• •
  Vercel — AI SDK 5 — typed UIMessage parts and SSE standardization, the architecture this module builds on.
• •
  Vercel — Introducing AI Elements — the prebuilt component vocabulary.
• •
  Vercel Academy — Multi-Step & Generative UI — the tool-part-to-component pipeline, hands-on.
• •
  OWASP — LLM Prompt Injection Prevention Cheat Sheet — the threat model behind the security table.
• •
  Setproduct — AI chat interface UI design — the state-matrix pattern catalog.