DSPy is the only framework in this space that made me change my mind about something. The pitch is that hand writing prompts is a bad way to build software, because you are hard coding a string that you tuned by feel, cannot version meaningfully, and have to redo entirely when you change model. Instead you declare what you want in a signature, compose modules that use those signatures, define a metric that says what good looks like, and let an optimiser generate and select the prompts for you. Once you have seen it work, going back to editing prompt strings by hand feels like editing assembly.
The documentation teaches this well in the getting started sequence. Signatures first, then modules, then composition, then metrics, then optimisation. That order is right, because the metric is the part people want to skip and the part that makes the whole thing function. If you cannot say numerically whether one version of your program is better than another, no optimiser can help you, and the docs are firm about this in a way I appreciated.
The tutorial library is the strongest asset. There are over sixty of them now, grouped into building programs, optimising programs, the newer reflective optimisation work, and deployment concerns like caching, streaming and debugging. They are notebooks, they run, and they cover things people actually build. Multi hop retrieval, entity extraction, classification, tool use, code generation, financial document analysis.
Working through three of them gives you a real feel for the workflow rather than an abstract understanding of it. The deeper material on optimisers is unusually honest for framework documentation. It tells you what each optimiser is doing, roughly how many calls it will make, and when a cheaper one is sufficient. That matters because the first time you run a serious optimisation and watch your bill you will want to have understood it beforehand.
I still think this section understates cost. The examples use small datasets and small models, and the jump to a real task with a real model is expensive enough that it deserves a page of its own with concrete numbers. Now the problems. The conceptual barrier is genuine.
Someone whose entire experience is writing prompts into a chat window and copying them into code will read the signatures page and not understand why any of this is necessary. The docs explain the how before establishing the why, and I think that is backwards. The motivating case, which is that your carefully tuned prompt breaks when you switch model and you have no systematic way to fix it, should be the first thing you read. Instead you get an architecture.
Version churn has hurt this project. DSPy has been through significant API changes and there is a large volume of tutorials, blog posts and Stack Overflow answers written against older versions. Worse, language models will confidently produce old style DSPy code, because that is what most of their training data contains. Trust the official site and check the version on anything else.
The organisation is reference first. Getting started, diving deeper, tutorials, API reference, community. That is a sensible structure for someone who already knows the framework and a poor one for someone learning it, because nothing tells you what order to read things in or when you know enough to start building. I ended up constructing my own path and I suspect most people do.
The community is small relative to the alternatives. Eight thousand or so on Discord is healthy for a research adjacent project and tiny next to LangChain. When you hit something odd, expect to read source code. The source is readable, which softens this considerably.
My three point nine is for teaching an idea that genuinely improves how you build, with a tutorial library that is both large and functional, marked down for a learning path that has to be assembled yourself, version churn that pollutes everything outside the official docs, and cost guidance that does not match what real optimisation runs actually cost. If you build anything non trivial with language models, spend a weekend on this even if you decide not to adopt it. The way of thinking is worth more than the library.