Why Teams Rebuild DSPy Patterns Even as Adoption Lags

Hacker News discussion about If DSPy is So Great, Why Isn't Anyone Using It? turned a familiar LLM engineering frustration into a blunt question. The HN thread was posted on March 23, 2026 UTC and had 119 points and 74 comments at capture time. The linked post by Skylar Payne does not argue that every team must adopt DSPy immediately. Its narrower claim is that once AI systems mature, many teams end up rebuilding the same engineering patterns that DSPy already packages.

The blog walks through that progression as a practical sequence rather than a theoretical framework. A team starts with a direct API call and then adds prompt versioning so prompts can change without a deploy. Next come structured outputs with tools like Pydantic, then retries for transient failures, then RAG when the model needs external context, then evals to measure whether changes help, and finally model-swapping so GPT-4, Claude, or another model can be tested without a full refactor. Payne's argument is that these steps look like ordinary software engineering, but they arrive late and painfully when teams treat prompts as one-off glue code.

• Prompt versioning and separation from application code
• Structured outputs and typed I/O
• Retries and centralized failure handling
• RAG for context retrieval
• Evals for regression checking
• Model-swapping without rewriting the pipeline

The post says DSPy adoption still lags because the abstractions feel unfamiliar before the pain is obvious. Engineers are pressured to ship, probabilistic outputs are harder to debug than normal code, and the boundary between prompt, code, and data is blurry. DSPy asks teams to define signatures, modules, and evaluation loops earlier than many are comfortable with. That upfront design cost is exactly what the author thinks most teams postpone until their system becomes harder to manage.

The HN discussion sharpened that point instead of simply agreeing with it. Some commenters said typed I/O, retries, and prompt separation are already standard practice and argued that DSPy's real differentiator is prompt optimization. Several comments also focused on evals, noting that open-ended AI products often lack a stable automated metric. That response shows why teams may agree with DSPy's architecture while still hesitating to adopt the framework directly.

The practical takeaway from the linked blog is straightforward: teams can adopt DSPy directly, or they can borrow its patterns intentionally from day one. The Hacker News thread shows why that recommendation is still debated. Even so, the blog and the discussion both suggest that once an AI system becomes complex enough, prompt management, typed interfaces, retrieval, evaluation, and model abstraction stop looking optional.