Lesson 16 of 30

AI SDK Patterns

Q: Why would you reach for an AI SDK-style abstraction instead of calling a provider's chat API directly from your components?

A strong answer covers: Names the real cost being avoided: every provider has a different streaming format, error shape, and message structure, and calling directly means hand-rolling parsing/state logic for each one; Explains that the abstraction gives you a provider-agnostic interface, so swapping or adding a provider becomes a config change rather than a UI rewrite; Distinguishes the client-side state management piece (message list, loading/streaming/error state) from server-side concerns like key resolution; Recognizes the abstraction's limits — not every provider supports every feature identically, so 'provider-agnostic' doesn't mean zero coupling.

Every provider streams differently, errors differently, and shapes messages differently — an AI SDK exists to hide those differences behind one interface so your UI code doesn't have to know which model is answering.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

Your app currently calls one AI provider directly, hand-parsing its streaming response format in your chat component. What's the main cost of that approach as the app grows?

Provider-specific parsing and state logic ends up baked into UI code, making it costly to swap or add providers laterDirect provider calls are always slower than going through an SDK, regardless of network conditionsProviders reject requests that don't originate from an official SDK's client library

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on AI SDK Patterns

What interviewers actually ask about this, and what a strong answer has to cover.

Why would you reach for an AI SDK-style abstraction instead of calling a provider's chat API directly from your components?

A strong answer covers

Names the real cost being avoided: every provider has a different streaming format, error shape, and message structure, and calling directly means hand-rolling parsing/state logic for each one
Explains that the abstraction gives you a provider-agnostic interface, so swapping or adding a provider becomes a config change rather than a UI rewrite
Distinguishes the client-side state management piece (message list, loading/streaming/error state) from server-side concerns like key resolution
Recognizes the abstraction's limits — not every provider supports every feature identically, so 'provider-agnostic' doesn't mean zero coupling

Likely follow-ups

If you were building this yourself instead of using an off-the-shelf SDK, what's the minimum interface you'd need to design to get the same benefit?
Where would you draw the line between what the client-side chat hook owns and what a server-side handler like Praxis's handleChat owns?

Practice these with the AI interviewer →

The plain-language idea

Calling a raw provider API for a chat feature means handling a lot yourself: opening a streaming connection, parsing whatever chunk format that specific provider uses, tracking loading/error/streaming state in your own useState calls, and reshaping the provider's response into whatever your UI expects. Do that for one provider and it's manageable. Do it for two, or swap providers six months later, and you're rewriting UI-adjacent plumbing that has nothing to do with your actual product.

An AI SDK (the pattern, not any one specific library) is an abstraction layer that solves this two ways:

Provider-agnostic interface. Your code calls one consistent shape — send messages, get a response or a stream — regardless of which model is behind it. Swapping providers becomes a config change, not a rewrite.
Ready-made state management. Framework hooks (the common shape is something like useChat/useCompletion) manage the message list, the streaming/loading/error state, and the send/retry actions for you, so a chat UI component consumes state instead of building a state machine from scratch.

The value isn't "less typing." It's that the streaming-response parsing, the error-shape normalization, and the message-array bookkeeping are the exact same problem for every team building a chat feature — solving it once in a shared layer means your component code stays about your product's UI, not about re-deriving provider plumbing.

See it in a real thing: what the abstraction is hiding

Provider A stream chunk:  data: {"choices":[{"delta":{"content":"Hi"}}]}
Provider B stream chunk:  event: content_block_delta
                           data: {"delta":{"text":"Hi"}}

Two providers, two different wire formats, for the same underlying idea: "here's the next piece of text." Without an abstraction layer, code that renders a streaming response has to know which shape it's looking at. With one, both get parsed into the same internal event type before your UI ever sees them — the component that renders streaming text writes one handler, not one per provider.

Praxis's own backend takes a related but narrower approach: lib/ai/chat/handler.ts's handleChat is the single entry point every AI call site goes through, and lib/ai/provider/resolveKey.ts's resolveProviderConfig resolves which key/provider config to use before the call happens. It's a hand-rolled version of the same underlying idea an SDK's provider-agnostic interface solves — one seam that call sites depend on, so the provider-specific details (which key, which fallback ladder) stay out of every route handler that needs to talk to a model.

What people usually miss

Watch out

The abstraction is about the interface, not about hiding that an LLM call is happening. You still need to think about latency, streaming, and failure modes — the SDK just gives you one consistent shape to handle them in, not a reason to stop thinking about them.
"Provider-agnostic" has limits. Not every provider supports every feature (function/tool calling, structured output, vision) identically, so swapping providers can still surface capability gaps the abstraction can't paper over.
These hooks manage client-side state, not your backend's key/quota/fallback logic. A chat hook tracking message state in the browser is a separate concern from server-side decisions like which API key to use or what to do on a quota error — conflating the two leads to putting business logic in the wrong layer.
Vendoring the abstraction yourself is a legitimate choice, not a shortcut for people who "don't know the standard SDK." A small, well-scoped app with one provider and one call pattern may not need a general-purpose SDK's full surface area — Praxis's own handleChat is exactly this kind of deliberate, narrower version.

Why this matters in interviews

"Why would you reach for an AI SDK instead of calling the provider's API directly?" tests whether a candidate can name the real cost being avoided (re-solving streaming/state/error-shape plumbing per provider) rather than giving a vague "it's easier" answer.