Framework compiles a prompt from a signature + metric
Step by step debuggability. Every Runnable is inspectable
Few-shot exemplars chosen by an optimizer, not hand-picked
PyTorch-style 'program + optimizer + metric' mental model
Chain of Runnables composed with a pipe operator
LLM frameworks split into two camps based on what artefact you, the developer, are responsible for producing.
Imperative frameworks (LangChain, LlamaIndex) ask you to write the prompt and wire the steps. You compose a chain, `prompt | model | parser` in LangChain's pipe syntax, and you can pause execution between any two steps to inspect what is happening. The mental model is 'plumbing': you connect named primitives in a specific order.
Declarative frameworks (DSPy, BAML) ask you to declare a signature ('this function takes a question and returns an answer') and a metric ('the answer is correct if it exact-matches the gold label'). The framework's compiler then searches over prompt templates and few-shot exemplars to maximise the metric on your training set. You do not write the prompt; the compiler does.
The matching question turns on three tells. If the property names a metric, a compiler, or optimizer-chosen exemplars, it is declarative. If it names a prompt string, a Runnable, or a pipe composition, it is imperative.
The split is about which artefact the developer owns. In **imperative** frameworks like LangChain and LlamaIndex, you write the prompt string and wire each step explicitly. The unit of composition is something like a Runnable or a QueryEngine; you build a pipeline with the pipe operator or method chaining, and you can step through any intermediate state. The trade-off is power for control. You can build anything, but every prompt is yours to maintain.
In **declarative** frameworks like DSPy and BAML, you declare a signature (input fields, output fields, semantic description) plus a metric, and the framework compiles a prompt and a set of few-shot exemplars that maximise the metric on labelled data. The mental model is borrowed from PyTorch: program + optimizer + metric. You do not author the prompt; the compiler does, and re-compiles when the model, the data, or the metric changes.
Matching the properties: prompt authoring, Runnable inspectability, and pipe composition are imperative tells. Signature-driven compilation, optimizer-selected exemplars, and the program plus optimizer plus metric framing are declarative tells. The two paradigms are not religious; production teams mix them. Declarative for the prompt-sensitive core, imperative for the surrounding orchestration.
Quick reference
TL;DR
Imperative frameworks (LangChain, LlamaIndex) make you write the prompt and wire each step; declarative frameworks (DSPy, BAML) make you declare a signature and a metric and let a compiler choose prompts and exemplars.
Imagine two cooking shows. In the first, the chef hands you a recipe step by step: chop the onion, sauté at medium, add salt at minute three. You can stop at any step and inspect what is in the pan. In the second, you tell the kitchen, 'I want a dish that scores nine out of ten on this taste test,' and a robotic chef tries combinations against your taste-test rubric until it finds the best one. You do not write the recipe. You write the scoring rubric. The first show is imperative cooking; the second is declarative cooking. Both produce dinner; they ask you for very different artefacts.
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.
Declarative with no labelled training set and no real metric The optimizer has nothing to optimise against. You get a randomly chosen prompt and lose the inspectability of the imperative path
Imperative for a prompt-sensitive task across multiple providers, with no time to re-tune prompts per provider You pay the cost of hand-tuning prompts on every model switch; declarative absorbs that via re-compilation
Either paradigm for a one-off script that hits a single model with a single prompt Neither framework's overhead is justified. Call the SDK directly and skip the abstraction
Declarative for a step that needs deterministic per-step inspection (debugging a multi-step tool flow) The compiled prompt hides intermediate decisions; imperative composition keeps every step visible
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: who owns the prompt, why optimizer-selected exemplars are the tell, and when production stacks mix both paradigms.
Side-by-side
Aspect
Imperative (LangChain, LlamaIndex)
Declarative (DSPy, BAML)
Developer writes
The prompt + the wiring
The signature + the metric
Few-shot exemplars
Hand-picked
Optimizer-selected from labelled data
Mental model
Plumbing / Runnable composition
PyTorch-style program + optimizer + metric
Step-level debuggability
First-class. Every Runnable is inspectable
Limited. Compiled prompt is the artefact
Model migration cost
Re-tune prompts per provider quirk
Re-compile against the new model
Best fit
Orchestration, RAG plumbing, agents
Prompt-sensitive cores with labelled data
Real-world examples
Real products, models, and research that use this idea.
1DSPy's original Stanford NLP paper framed prompts as a search problem over a program + metric, popularising the declarative paradigm in 2023.
2BAML (from Boundary) ships a declarative IDL for structured-output extraction with provider-portable compiled prompts, used in production by Anthropic-adjacent teams.
3LangChain Expression Language (LCEL) is the canonical example of imperative composition: `prompt | model | StrOutputParser()` builds a Runnable you can `.invoke` or `.stream`.
4LlamaIndex's QueryEngine API is imperative in flavour, you wire retriever, postprocessors, and response synthesizer explicitly, though it shares retrieval primitives with declarative pipelines.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you decide whether to put a particular task on the declarative or imperative side?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens to a DSPy program when you swap the underlying model?
Sign in or go Pro to see the approach for this follow-up.
QWhy is observability harder in declarative frameworks?
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
Calling DSPy 'just another prompting library' and missing that the load-bearing object is the compiler that searches for prompts and exemplars against a metric.