Hacker Newsの議論とIf DSPy is So Great, Why Isn't Anyone Using It?は、DSPyをめぐる期待と現実を同時に見せている。このHNスレッドは2026年3月23日 UTCに投稿され、集計時点で119 pointsと74 commentsを記録した。リンク先のSkylar Payneの主張は、すべてのチームが今すぐDSPyを導入すべきだというものではない。むしろ、AIシステムが複雑になると、多くのチームは結局DSPyがすでに整理している設計パターンを、自前で遅れて作り直すことになるという指摘だ。

ブログはその流れを抽象論ではなく、実務で起きる順番として説明する。最初は単純なAPI呼び出しで始まるが、すぐにデプロイなしでプロンプトを変えたくなり、prompt versioningが必要になる。次にPydanticのような道具を使った structured outputs を入れ、過渡的な失敗に備えて retries を足し、外部知識が必要になると RAG を組み込み、変更の良し悪しを測るために evals を整え、最後には GPT-4 や Claude を大きなリファクタなしで試せる model-swapping の層が欲しくなる。Payneが言いたいのは、これは特別な流行語ではなく、先送りされていたソフトウェアエンジニアリングの基本が AI 開発であとから再登場する過程だという点だ。

prompt versioning とアプリケーションコードからの分離
structured outputs と typed I/O
retries と失敗処理の集中化
RAG による文脈補強
evals による回帰確認
pipelineを書き直さない model-swapping

採用が伸びにくい理由についても、記事はかなり明確だ。DSPyの abstraction は多くの開発者にとってまだ馴染みが薄く、境界も分かりにくい。プロンプトはコードでもありデータでもあり、出力は確率的なので通常のコードのように追いにくい。しかも現場には早く ship する圧力があるため、inline prompt や場当たり的なロジックが先に増える。DSPyは signatures、modules、evaluation loop を早い段階で考えることを求めるので、学習コストが高く感じられる。記事は、その upfront な設計負荷こそ多くのチームが後回しにし、その結果として数か月後により大きな複雑さに直面すると見る。

HNの議論はこの主張を補強しつつ、論点も絞り込んだ。typed I/O、retries、プロンプト分離はすでに多くのチームの標準的な実践であり、DSPyの本当の差別化は prompt optimization だという意見があった。さらに複数のコメントでは、open-ended なAI製品では安定した自動 eval metric を作ること自体が難しいと指摘された。こうした反応は、DSPyの設計思想に共感しても、実際の導入は評価設計の重さに左右されることを示している。

実務的な結論は比較的シンプルだ。リンク先ブログは、チームがDSPyをそのまま採用してもよいし、使わなくてもその設計思想を最初から意識して実装すべきだと述べている。HNスレッドは、その提案がなぜ簡単には一致した賛同を得ないのかを示した。それでも、AIシステムが一定以上に複雑になると、prompt管理、typed interface、retrieval、evaluation、model abstraction がほぼ不可避になるという点では、ブログと議論の両方が同じ方向を示している。

#llm-engineering

DSPyの採用は遅いのに、なぜ同じLLMパターンを作り直すのか