Frontend for AI Apps
AI is slow, probabilistic, and sometimes wrong — so the UI’s job is to make it feel responsive, trustworthy, and in your control.
You wire your AI feature to a simple form: the user types, clicks submit, and… stares at a frozen button for eight seconds before a wall of text suddenly appears. It feels broken — even though the model is working fine. The experience is the problem. AI apps have unusual front-end needs (slow responses, streaming, uncertainty, trust) that an ordinary instant-response form was never designed for.
Latency & streaming: never freeze
Model calls take seconds, not milliseconds, so a “click and wait silently” form feels broken. Two musts: show a clear thinking/loading state the instant the user submits, so it never looks frozen, and stream the response — display tokens as they arrive — so the user sees progress within about a second and perceives the whole thing as fast. Let them stop/cancel a long generation, too. The model didn’t get faster; the experience just stopped feeling stuck.
Trust & control: it’s sometimes wrong
Because AI output can be wrong, the UI should help users verify and steer, not just read. Show sources/citations (from your RAG step) so a claim can be checked. Make it easy to edit the prompt and retry. Render the model’s output safely. And handle errors, timeouts, and refusals with a clear, helpful message — “something went wrong, try again” — instead of a blank screen or a crash. Good AI UX assumes imperfection and designs around it.
Keep the key server-side
The frontend must never hold your API key. Anything in the browser is fully visible to the user — open dev tools and there it is. So the frontend calls your backend, and the backend holds the key and enforces limits (caps, rate limits, auth). That’s the chokepoint this very app uses: the client talks only to /api/..., never directly to the model. The division is clean — frontend owns the experience; the backend owns secrets, keys, and policy (next lesson).
A good AI frontend is a restaurant dining room, not a vending machine. The dining room sets expectations and keeps you comfortable while the kitchen cooks: you get a menu, water, and visible signs that things are happening — not a locked door for eight minutes. Streaming is the waiter bringing dishes as they’re ready rather than nothing until everything’s done. And the secret recipe (your API key) stays back in the kitchen — the dining room never holds it where any guest could grab it.
Fixing the frozen-button form:
1. On submit, immediately show a “thinking…” indicator (not a dead button).
2. Stream the reply token-by-token, so text appears within ~1s and grows.
3. Add a Stop button to cancel a long answer.
4. On error/timeout, show “Something went wrong — try again,” not a blank screen.
5. Under a RAG answer, show the source links; offer “edit & retry.”
6. All requests go to /api/chat (your backend); the key is never in the browser.
Same model, dramatically better app.This is the reading. The interactive version — active-recall quiz, a hands-on experiment you run in your own AI, and an earned mastery check — is free in the app.
Start this lesson free →