DSPy 3.3.0b1 turns prompts into a compile target

DSPy shipped 3.3.0b1 on July 14 with a new ReActV2 module, turning prompts from hand-tuned strings into a target you compile and re-run for any model. Anyone who's shipped a prompt-based feature knows this pain: you upgrade the model, the carefully-tuned prompt regresses, and nobody can say why. DSPy's fix is to stop treating the prompt as a precious artifact and treat it as a build output instead.

You declare a task as a typed Input to Output signature and pick a reasoning strategy. MIPROv2 then searches instructions and few-shot examples using Bayesian optimization against your own metric, per DSPy's documentation.

Swap models, re-run the optimizer, get a prompt tuned for what you're actually deploying on.

Willison used DSPy to tune the Datasette Agent's SQL prompts. The optimizer surfaced a real bug: schema listings without column names caused the agent to guess columns and loop on retries.

That's a failure mode you'd normally burn an hour chasing by hand. The optimizer found it as a side effect of optimizing against the metric.

The catch

There's a learning curve. The signatures-and-modules abstraction takes a beat to click if you've only written raw strings. Budget an afternoon to port one real task before judging it.

Start with something that has a clean metric, a classifier, an extractor, a SQL generator, so MIPROv2 has an actual target. If you've got a prompt you keep re-crafting every time a new model drops, that's the one to convert first.