Zenaique

Match each framework property to the declarative or imperative paradigm it belongs to

Match pairs·Medium·4.0 · 0·~2 min·Asked atLyzrUberWandb
Attempt it

Drag each answer to line up with its matching prompt

Developer authors the prompt string directly

Imperative (LangChain, LlamaIndex)

Framework compiles a prompt from a signature + metric

Declarative (DSPy, BAML)

Step by step debuggability. Every Runnable is inspectable

Imperative (LangChain, LlamaIndex)

Few-shot exemplars chosen by an optimizer, not hand picked

Imperative (LangChain, LlamaIndex)

PyTorch style 'program + optimizer + metric' mental model

Declarative (DSPy, BAML)

Chain of Runnables composed with a pipe operator

Declarative (DSPy, BAML)

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.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

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.

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The declarative versus imperative divide is the single most useful mental model for navigating the 2026 LLM-framework landscape. It explains why LangChain feels like plumbing and DSPy feels like PyTorch, why a team that loves one often dislikes the other, and why production stacks frequently use both for different parts of the system.

This deep dive pins down the difference precisely, walks through the property matching, and ends with a hybrid pattern that most production teams converge on.

The fault line: who owns the prompt

The cleanest way to separate the two paradigms is to ask: when prompt quality matters, whose job is it to make the prompt good?

In imperative frameworks, that job is the developer's. You write the prompt as a string (or a template with slots), you commit it to Git, you A/B test variants by hand. LangChain and LlamaIndex are imperative by this test. Their primary documentation walks you through writing prompts, parsers, and chains.

In declarative frameworks, that job is the framework's compiler. You declare a signature ('question → answer', with semantic field names) and a metric ('exact match against gold label'), supply a training set, and the compiler searches over prompt templates and few-shot exemplars to find the combination that maximises the metric. DSPy and BAML are declarative by this test. Their primary documentation walks you through signatures, metrics, and compiler runs.

Why the distinction is not cosmetic

A prompt is a hyperparameter. Imperative says: you tune it by hand, like you tuned learning rates before Adam. Declarative says: you delegate it to an optimizer, like you delegated learning-rate scheduling to a scheduler. Both are real engineering choices with measurable consequences.

Reading the matching pairs
Consequences for engineering practice
The hybrid pattern most production teams converge on
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.
AspectImperative (LangChain, LlamaIndex)Declarative (DSPy, BAML)
Developer writesThe prompt + the wiringThe signature + the metric
Few-shot exemplarsHand-pickedOptimizer-selected from labelled data
Mental modelPlumbing / Runnable compositionPyTorch-style program + optimizer + metric
Step-level debuggabilityFirst-class. Every Runnable is inspectableLimited. Compiled prompt is the artefact
Model migration costRe-tune prompts per provider quirkRe-compile against the new model
Best fitOrchestration, RAG plumbing, agentsPrompt-sensitive cores with labelled data

Real products, models, and research that use this idea.

  • DSPy's original Stanford NLP paper framed prompts as a search problem over a program + metric, popularising the declarative paradigm in 2023.
  • BAML (from Boundary) ships a declarative IDL for structured-output extraction with provider-portable compiled prompts, used in production by Anthropic-adjacent teams.
Sign in to see more production examples.

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?
A

Two questions: do you have a labelled train set + a metric, and is prompt quality the bottleneck? Yes to both → declarative. No to either → imperative.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

Sign in to see all red flags and common mistakes.

60 second bullets to scan on the way to the call.

  • Artefact the developer owns in each paradigm (prompt vs signature + metric)

  • Two named frameworks per side and what each is best at

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
Defend the call to…
Short answer·Hard