DSPy 3.4.0

DSPy is the framework from Stanford NLP that asks you to program a language model rather than prompt it, read here at version 3.4.0, three days after that release shipped on 25 September 2026.

The sample is fourteen sources read on 28 September 2026: five of the project's own pages and one set of repository figures, one preprint, two Hacker News items and one search of its API, and five write-ups dated between April and September 2026. The repository showed 38,381 stars, 3,370 forks and 740 open issues that day, and the project's home page claimed more than five million monthly downloads. No established publication we could reach has reviewed the 3.4 line, so the editorial tier is the project's own 2023 preprint and nothing more. We ran nothing: no model was prompted, no library installed and no benchmark rerun.

Consensus

The writing we could read agrees on what the framework is and divides on which half earns its place. The typed declaration is the half that turns up in passing: the project's docs say signatures define tasks and enforce output types, and three of the five dated write-ups we read describe those typed fields as the contract a program is built on. The optimizers are the half that turns up in the headline, named in the title or the summary of three of the same five write-ups.

Our confidence is strongest on the project's own pages, which are claims about themselves before they are evidence, and thinner on developer discussion: one thread from March 2026 and one API search. No editorial review of this line was readable, no news reporting either, and the buyer tier is a single API call. Two things could date this reading quickly: the 3.4.0 notes replace the LM types introduced in 3.3 and set 3.5 as the migration deadline, and 3.4.0 arrived fifty-three days after 3.3.0.

Recurring strengths

The signature carries the shape. The docs describe signatures as typed inputs and outputs that replace hand-managed prompts, and three of the five dated write-ups describe that layer as a contract rather than a convenience. One sets the round trip out as declaration, compiled prompt, then a reply parsed back into the typed fields it calls parse targets. One says the declaration is what makes a pipeline portable and testable. One lists typed signatures as the framework's first primitive, and the project's own 2023 paper sets out the same model in place of hard-coded prompt templates.

The compiled prompt is a file. Two of the five write-ups and the project's own pages mention the same deployment detail in passing: the instructions are compiled into a JSON file loaded at runtime. One advises saving the compiled state so an application does not rerun the optimization loop at every start. The 3.4.0 release notes carry a section on saved state, and the project's worked example ends by saving its program to a file.

The interface holds while the model changes. One write-up says the signature stays stable while the predictor strategy adapts around it, and another describes the modular design as separating program logic from model parameters. The project's home page makes the same point in a control that swaps the model, one commenter in the March thread describes trying one with a one-line change, and the project's 2023 paper reports compiled programs running on open and small models.

Recurring complaints

Compiling wants a labelled set and a metric. One Hacker News thread from March 2026 raises it in two comments: one describes preparing training and test data as a reason it did not spread, another says the optimizers need datasets and tasks not every project has. One dated write-up calls an undefined metric the common first mistake, since without one the optimizer has nothing to improve against. The project's worked example compiles against 200 labelled examples.

Compiled prompts are hard to read. One dated write-up lists debugging compiled prompts as abstract and difficult, and says the string sent to the model sits behind layers of abstraction. No other source raises it, so it stands as one complaint.

The 3.x line moved its LM types. The release notes call 3.4 the LM transition release and set 3.5 as the migration deadline, replacing the experimental types from 3.3 and warning that custom adapters must not rely on a removed module. One dated write-up says the move from version 2 to version 3 changed the module API enough that older tutorials throw validation errors, and one piece read in September 2026 still reports 3.3.1 as current.

Extensions and the agent story trail the alternatives. One write-up says the documentation is thinner than a mature competitor's, and one commenter says the out-of-the-box agent loop is the weak part.

A compile is a billable run. The DSPy docs' own worked example reports a compile over 200 examples costing $2.18 and taking its own figure from 62% to 89%, and one dated write-up treats avoiding a rerun of the optimization loop as a reason to save it.

Where reviewers split

Whether the optimizers are the point. One comment in the March thread holds that the framework's real value is its prompt optimization. A later comment takes the other side, that the optimizers are not the point and the contribution is pushing programmers to design a system that can be optimized at all. Our read: one feature seen from two ends, the run you pay for and the structure it needs.

Whether it competes with the orchestration frameworks. One dated write-up sets DSPy against a large integration ecosystem and calls its optimizer the deeper engine. Another says it does not orchestrate communicating agents the way those frameworks do, and calls the two categories complementary. We read this as a difference of framing rather than of fact.

What to reach for it for. One dated write-up recommends it to engineering teams building multi-stage retrieval pipelines that need systematic evaluation. In the thread, one commenter says the only thing they would take it for now is automating the edges of an agentic pipeline. Both are single opinions.

Who it suits

You want the shape of a model's answer to be something you declared, not something you hope for. The docs say signatures define tasks and enforce output types, and the framework parses the reply back into those fields.

You have, or can label, a few dozen examples and a way to score answers. Every source here that describes compiling, the project's own example included, starts with examples and a metric.

You expect to change the model under a working pipeline, or to keep the prompt as an artifact you can save. The docs make swapping the model a control, two write-ups and the release notes describe the saved program, and one commenter describes a one-line model change followed by a rerun.

Who should pass

You need a single call to a single model and no evaluation. One dated write-up names simple wrapper applications as the case where the architectural overhead outweighs the benefit.

You need an interface that will not move between minor releases. The release notes replace the LM types in 3.4 with a deadline at 3.5, and one write-up reports older tutorials breaking on the move from 2 to 3.

You want a capable agent loop out of the box. One write-up and one thread comment both point elsewhere for it.

One verdict a week: the most useful Master Review we finished, the complaint that kept appearing, and who should skip it.

Sources

• DSPy docs overview (official, read 28 September 2026)
• stanfordnlp/dspy repository (official, read 28 September 2026)
• DSPy licence file (official, MIT, read 28 September 2026)
• DSPy 3.4.0 release notes (official, published 25 September 2026)
• dspy 3.4.0 on PyPI (official, read 28 September 2026)
• GitHub repository figures (tier 3, read 28 September 2026)
• arXiv 2310.03714: DSPy, compiling declarative LM calls (editorial, published 5 October 2023)
• Hacker News: If DSPy is so great, why isn't anyone using it? (forum, published 23 March 2026)
• Hacker News API search for DSPy (forum, read 28 September 2026)
• Stories from a Software Tester: DSPy, declaring not prompting (other, April 2026 address)
• DataAspirant: DSPy Explained (other, read 28 September 2026)
• PromptQuorum: DSPy Review 2026 (other, read 28 September 2026)
• nolist.ai: DSPy review (other, read 28 September 2026)
• DevSkrol: Stop Writing Prompts, Start Optimizing Them (other, published 27 June 2026)

On 28 September 2026 we read five of the project's own pages, one set of GitHub REST API figures, one preprint, two Hacker News items and a search, and five dated write-ups, by web search and plain page fetch, and synthesised them with AI; we ran nothing and tested nothing.