An LLM framework gives you four things: composition (chains, agents), provider abstraction, observability hooks, and higher-order patterns (RAG, parsers, tool loops). When your app uses those things, the framework saves you wiring them yourself. When it does not, you are paying for code you do not need.
The four 'yes' cases are clear. Multi-step chains with retrieval and tool calls are exactly what frameworks compose. A/B testing across providers needs a uniform interface, which frameworks provide. Observability vendors plug into framework callbacks; without them you wire OTel by hand. And explicit agent-loop control with branches and checkpoints is what LangGraph and similar were built for.
The two 'no' cases bite teams who do not think hard about them. A single-prompt app has nothing to compose. Calling the provider SDK directly is fewer lines. And when a provider ships a new capability, the framework's wrapper lags by 4-8 weeks; if you need the feature now, you have to bypass the framework anyway.
The interview signal is spotting both kinds of case, not just defending frameworks in general.
**The four wins.** Frameworks earn their keep when at least one of these holds.
- **Composition complexity.** Retrieval + tools + structured output + reasoning glued together is the canonical 'chain' shape. Writing the orchestration yourself is doable but bug-prone; a framework's primitives (LCEL Runnables, LlamaIndex QueryEngines, LangGraph nodes) save real work.
- **Multi-provider portability.** If your product needs to swap OpenAI for Anthropic for a local model with one config change, for A/B testing, regional cost, or risk diversification, a framework's unified interface is the cleanest path. Roll your own wrapper and you reinvent the framework, poorly.
- **Observability integration.** LangSmith, Langfuse, Phoenix, and Arize hook into framework callback surfaces. The framework hands you tracing for free; without it you wire OTel manually per call site.
- **Agent-loop control.** Explicit graphs with conditional edges, checkpoints, human in the loop interrupts (LangGraph's sweet spot) are genuinely hard to build from scratch.
**The two taxes.**
- **Single-prompt apps.** One prompt in, one completion out. There is nothing to compose; the framework is a layer of indirection over a one-line SDK call.
- **Day-one provider features.** When OpenAI ships prompt caching, prediction outputs, or computer use, the wrapper takes weeks. If you need it today, you call the provider directly. Which means writing the bypass that defeats the abstraction.
The interview maturity is naming both halves.
Quick reference
TL;DR
Frameworks earn their keep on composition, multi-provider portability, observability, and agent-loop control; they tax you on single-prompt apps and day-one provider features.
Think of a framework like buying a full kitchen appliance set. If you cook six-course meals every weekend with multiple stoves, ovens, and a mixer running together, the set saves you wiring everything yourself. The investment pays back.
But if you only ever make instant noodles, the same set is overkill. A kettle is faster. And the day a brand-new gadget comes out, the appliance brand will take weeks to fold it into the set, while the standalone gadget is on shelves today.
Same trade-off with LLM frameworks. Complex pipelines pay back the abstraction; one-shot prompts and bleeding-edge provider features do not.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-prompt feature with no composition or tool calls The SDK call is one line; the framework adds indirection, dependency surface, and upgrade risk for zero composition value.
Competitive surface is day-one provider feature adoption Wrappers lag 4-8 weeks; the framework becomes a structural drag if speed to feature is the product's edge.
Team with no real plan to swap providers Provider abstraction is the framework's biggest sell; without exercising it, you pay the tax for optionality you never use.
Tiny team optimising for ejection cost Once a framework's types thread through the codebase, removing it is a multi-sprint refactor; thin wrappers around the SDK keep the option open.
Quick scan · 2–4 min
Everything important, quickly.
5 min: the four wins, the two taxes, ejection cost, multi-provider reality check, and how to stage adoption without locking in.
Real-world examples
Real products, models, and research that use this idea.
1Cursor and Perplexity ship raw-SDK code paths for their hot loops despite using frameworks elsewhere. Single-prompt surfaces do not need the abstraction.
2Vercel AI SDK adoption took off because its callback contract instruments OpenTelemetry cleanly, hitting the observability win without a heavy abstraction.
3LangGraph adoption in 2025-2026 was driven by the agent-loop control case, explicit graphs with checkpointers, that LCEL alone could not express.
4Stripe and Notion teams use LangChain for RAG composition but call the OpenAI SDK directly for day-one features like prompt caching and prediction outputs.
5Anthropic's Claude prompt-caching feature shipped six weeks before clean LangChain wrapper support. Exactly the day-one tax this question names.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you stage a framework adoption to keep ejection cost low?
Sign in or go Pro to see the approach for this follow-up.
QWhen does LangGraph beat plain LangChain for an agent app?
Sign in or go Pro to see the approach for this follow-up.
QWhat would change your answer if the team is shipping in TypeScript?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Adopting a framework for a single-prompt feature 'because we might compose later'. Paying the abstraction tax up front for composition that may never happen.