What problem does LangChain actually solve, and when is it the wrong tool?
Quick Answer
LangChain standardizes the plumbing around LLM calls — model-provider abstraction, prompt templating, tool calling, retrieval, streaming, and observability hooks — so you compose pipelines instead of hand-rolling HTTP clients. It's the wrong tool for a single prompt-in/answer-out call, or when your team needs full control over every token and retry.
Detailed Answer
The value is the interfaces: a ChatModel abstraction over providers (swap OpenAI for Anthropic or a self-hosted vLLM endpoint without rewriting call sites), Runnables that compose with uniform invoke/stream/batch semantics, structured-output helpers, retriever/vector-store integrations, and callback hooks for tracing. That buys speed and portability. The costs are real too: an abstraction layer to debug through when something misbehaves, historical API churn (the 0.x line broke things repeatedly until v1.0 in late 2025 committed to stability), and the temptation to use framework machinery where 30 lines of direct SDK calls would be clearer. Wrong-tool cases: one-shot completions (call the provider SDK), maximal-control serving paths (token-level budget/retry logic), and teams that already built their own thin layer. Right-tool cases: RAG pipelines, multi-provider products, agents with tools, and anywhere you want LangSmith-style tracing without building it.
Code Example
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_messages([('system', 'You are terse.'), ('user', '{q}')])
chain = prompt | ChatOpenAI(model='gpt-4o-mini') | StrOutputParser()
chain.invoke({'q': 'What is a vector index?'})Interview Tip
Saying when NOT to use it is the credibility move — frameworks are easy to praise. Name the tradeoff: uniform interfaces and tracing vs debugging through an abstraction layer.