# DSPy: The End of Prompt Engineering

Kevin Madura, AlixPartners | AI Engineer CODE 2025 | 1:13:13

Source: https://www.youtube.com/watch?v=-cKUW6n8hBU
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/dspy-the-end-of-prompt-engineering
Published: 2026-01-08
Tags: code-generation, prompt-engineering, structured-outputs

## TL;DR
- DSPy lets developers express an LLM application's inputs, outputs, and control flow as a typed Python program instead of repeatedly editing prompt strings.
- Signatures, modules, adapters, tools, metrics, and optimizers let one program use different models, output formats, and model-specific prompts without changing its business logic.
- DSPy optimizers use examples and metrics to revise prompts, which can improve a program on a task or move it to a smaller, cheaper model while retaining much of its performance.

## Summary
Kevin Madura presents DSPy as a way to build enterprise AI applications as ordinary, modular Python programs. Developers define signatures for typed inputs and outputs, compose them into modules, expose Python functions as tools, and let adapters turn those definitions into prompts for a chosen model. He argues this structure makes applications easier to test, change, and move between models than hand-written prompt chains. The talk includes examples for sentiment classification, document analysis, multimodal inputs, web research, file routing, contract summarization, and PDF boundary detection. Madura also explains DSPy's optimizers. Given a data set and metrics, an optimizer evaluates a program and revises its underlying prompts. He reports one example improving from 86 to 89, and describes using optimization to make smaller models more affordable. He is careful to say that DSPy is primarily a programming framework, with optimization as an additional capability.

## Key ideas
### DSPy turns LLM calls into typed program components
[01:18](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=78s)
Madura describes DSPy as a declarative framework for building modular software with LLMs as first-class components. A developer defines what a function should accept and return, then calls that function as part of a Python program. The framework handles the prompt construction and structured input and output. His examples include searching thousands of contracts for a clause and helping companies deploy AI internally. He says this lets his team iterate quickly while keeping business logic in code rather than repeatedly tweaking strings. The result is a program whose control flow and intent can remain stable while the underlying model changes.

### Signatures express intent while modules hold reusable logic
[07:12](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=432s)
DSPy signatures specify inputs and outputs, and both can have types. Modules organize one or more signatures together with ordinary business logic. Madura shows a time-entry correction module that sends text to an LLM, then applies additional Python logic to enforce formatting rules such as capitalization and sentence-ending periods. DSPy also includes modules such as Predict, ChainOfThought, ReAct, and ProgramWithThought. ReAct exposes Python functions as tools, while modules can run calls in parallel or compare outputs. Developers can create their own modules when they have a prompt or workflow that already works well.

### Field names and descriptions become part of the generated prompt
[10:32](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=632s)
In class-based signatures, the names of fields matter because DSPy passes them into the model prompt. Madura shows a typed object with fields such as text and patient information, where the field names act like small prompt instructions. Descriptions add more context. A shorthand signature can express a simple sentiment classifier with an input called text and an integer output called sentiment. The developer can add instructions explaining the sentiment scale later. Madura says this shorthand makes it fast to test an idea before turning it into a fuller module. Existing prompts can still be placed in a docstring or injected into the final string.

### Adapters change prompt formatting without changing application logic
[19:57](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=1197s)
Adapters sit between a signature and the model call. They translate typed inputs and outputs into a message format, such as JSON or BAML. Madura compares a nested patient-details object in a long JSON representation with a more readable BAML representation. He says the BAML adapter can be more token-efficient and improved performance by five to ten percent in some use cases. The rest of the program remains unchanged because only the adapter is selected differently. DSPy also supports multimodal inputs, including images and audio. Its attachment support can convert PDFs and other files into text and images suitable for LLM calls.

### A document can be processed with attachments without a vector database
[23:43](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=1423s)
Madura calls his form-processing example 'poor man's RAG.' An attachments library downloads an Nvidia Form 4 PDF, extracts text with OCR, and supplies the document and its images to the model. The signature only asks a question and requests an answer, such as how many shares were sold. There is no vector store or embedding search in this example. The model receives the extracted text and images and performs the rest of the work. DSPy's typed outputs can also describe a document with either a flexible dictionary or a specific schema containing fields such as filing date, form type, and transactions.

### Optimizers use metrics to revise prompts and move work between models
[24:24](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=1464s)
DSPy optimizers evaluate a program against a data set and metrics, then iteratively change the prompts used inside its modules. Metrics can be exact checks, such as whether a classification matches, or more subjective judgments from another LLM. Madura gives a model-transfer example: a task that works well on a larger model might be run on a smaller model, then optimized to recover some lost performance at lower cost. He reports a time-entry example moving from 86 to 89. The optimized result can be saved and loaded as a compiled-like DSPy program, while the underlying optimized prompt can also be inspected.

### One pipeline can route arbitrary files to different models and workflows
[51:13](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=3073s)
Madura builds a file-processing pipeline for a directory containing contracts, SEC filings, images, and unrelated files. The program classifies each file, then routes it according to its type. SEC filings use extraction logic, contracts go through summarization, and images can be sent to Gemini when that model is preferred for visual recognition. The classifier receives the first few page images and returns a document type from a fixed set. For contracts, the pipeline recursively summarizes document chunks and detects section boundaries. He describes this as a quick prototype, and says production systems would need stricter or repeated classification passes.

### Visual page classification can detect contract boundaries
[56:00](https://www.youtube.com/watch?v=-cKUW6n8hBU&t=3360s)
The boundary detector converts a PDF into page images and classifies the pages asynchronously. It passes the page classifications to another DSPy signature that returns section names and page ranges. A ReAct module can call a page-image function to inspect selected pages and check whether a proposed boundary is correct. In Madura's example, the system identifies a main document from pages 0 through 6, followed by several schedules and exhibits. The logic uses little manually specified context, yet produced plausible ranges in his tests. He presents this as a prototype with room for better metrics, optimization, and production controls.

## Notable quotes
- "It is building a proper Python program and DSPy is a really good way for you to do that." (01:59)
- "You are building a program first. It just happens to also use LLMs." (04:19)
- "DSPy is not an optimizer. I've said this multiple times. It's just a set of programming abstractions or a way to program." (27:28)
- "The output of the optimizers is basically just another, it's almost like a compiled object if you will." (1:03:28)
- "If nothing else, to transfer it to a smaller model to preserve the level of performance at a lower cost." (1:10:50)

## Tools & references mentioned
- DSPy
- AlixPartners
- LangChain
- Pydantic
- PydanticAI
- Agno
- LiteLLM
- Phoenix
- Arize
- BAML
- OpenRouter
- Gemini 2.5 Flash
- Claude
- OpenAI
- Anthropic
- GPT-4.1
- GPT-4.1 nano
- GPT-5
- MIPRO
- GEPA
- GRPO
- Omar Khattab
- Chris Potts
- Andrej Karpathy
- Dario Amodei
- A16Z
- Hugging Face
- SEC Form 4
- Nvidia

## Who should watch
- You are building an enterprise LLM workflow that needs typed data, reusable components, and more control than a chain of hand-written prompts provides.
- Your application needs to switch between large and small models, or use different models for text and image workloads, without rewriting its business logic.
- You have labeled examples and measurable evaluation criteria and want to test whether automatic prompt optimization can improve a working program.

## Related talks

- [Optimizing LLMs in Insurance with DSPy](https://aietalks.com/talks/optimizing-llms-in-insurance-with-dspy) (Jeronim Morina, AXA, 19:29)
- [The Unreasonable Effectiveness of Separating the Task from the Model](https://aietalks.com/talks/the-unreasonable-effectiveness-of-separating-the-task-from-the-model) (Maxime Rivest, DSPy & Isaac Miller, DSPy; cmpnd, 17:11)
- [Building with Anthropic Claude: Prompt Workshop](https://aietalks.com/talks/building-with-anthropic-claude-prompt-workshop) (Zack Witten & Jamie Neuwirth, Anthropic, 1:34:56)
- [Pydantic is STILL all you need](https://aietalks.com/talks/pydantic-is-still-all-you-need) (Jason Liu, Independent AI consultant, advisor, writer, and educator, 15:21)
- [On Engineering AI Systems that Endure the Bitter Lesson](https://aietalks.com/talks/on-engineering-ai-systems-that-endure-the-bitter-lesson) (Omar Khattab, Databricks, 19:12)