If DSPy is so great, why isn't anyone using it?

Original Article ↗ Hacker News Discussion ↗

Despite strong praise from some early adopters, the DSPy framework for large language model applications sees relatively low uptake because it feels heavyweight, Python-centric, and demands upfront work on evaluations and training data. Commenters say many teams either hand-roll simpler equivalents or turn to alternatives like Pydantic AI, LangGraph, BAML, or vendor SDKs that offer more ergonomic integration and language support. A recurring theme is that DSPy’s core ideas—typed I/O, composable prompts, and optimization via evals—are valuable, but developers prefer to adopt those patterns without fully committing to the framework.

Adoption and Awareness

  • Many perceive DSPy adoption as low; several had never heard of it.
  • Common reason: teams are reluctant to add or switch to a Python-only framework, especially if their main stack is another language.
  • Some tried it in production and later removed it due to friction and limited perceived benefit.

Core Value Proposition & Patterns

  • Several commenters argue the true value is not just optimization, but the engineering patterns DSPy encourages:
    • Typed inputs/outputs, composable units, separation of prompts from code, and explicit model abstractions.
  • Others see these as “table stakes” that can be implemented directly with tools like Pydantic, LiteLLM, or homegrown wrappers.

Prompt Optimization & Evaluations

  • DSPy’s optimizer (e.g., GEPA) is viewed by some as the main differentiator and very powerful.
  • Others report spending money on evals with no measurable improvement and find it easy to “hold wrong.”
  • A major barrier: building good eval datasets and automated metrics is hard, especially for open-ended or subjective tasks.
  • Some say you can’t iterate seriously without evals; others argue eval-building can slow teams more than it helps.

Ergonomics and Integration

  • Complaints: awkward ergonomics, dynamic typing, bundling input/output signatures, opaque compiled prompts, and a weak default agent loop.
  • DSPy can make precise control over context and provider-specific features harder.
  • Extracting optimized prompts or mixing DSPy with other tools is described as confusing or restrictive, though community adapters help.

Comparisons and Alternatives

  • Alternatives mentioned: LangChain/LangGraph, Pydantic AI, BAML, ADK, Semantic Kernel / Agent Framework, TensorZero, LiteLLM, and others.
  • Some see DSPy as analogous to sklearn: great for experimentation/optimization, but not necessarily what you ship to production.

Docs, Productization, and Positioning

  • Several criticize DSPy’s Python-centric story and lack of multi-language examples.
  • Others say DSPy under-invests in “whole product” aspects (docs, onboarding, clarity about what it is), which hurts adoption.
  • Consensus from multiple comments: even if you don’t use DSPy, its methodology and patterns are worth understanding.