「コードがAIに追いついていない」——レガシーコードにエージェントを導入するためのDDD戦略
Domain-Driven Agents
LLMはグリーンフィールドでは威力を発揮するが、レガシーコードベースでは、モデルが既存の概念の別綴りを発明したり、不適切なアダプタを書いたりして、品質が急落する。著者はその原因を「コード自体が質問に答えられないこと」とし、戦略的作業（意思決定）と戦術的作業（実装）を分離し、後者をAIエージェントに委譲する方法を紹介。DDDのユビキタス言語と境界づけられたコンテキストを基盤に、`.workflow.json`マニフェストと`CONTEXT.md`用語集を各リポジトリに配置し、コンテキストマップを自動生成。エージェントが正確に動作するための仕組みを具体的に解説する。
モデルが推測し、しばしば間違う。その失敗は、システムがどこにも答えていないシステムについての質問なのだ。
HNでの議論
20- stephen
私も「小さなd」のDDDファンで、エンティティごとの`md`ファイルを使って、言語に依存しない形でドメインの動作や癖、使い方を文書化してうまくいっています。つまり、`Author.ts`には`Author.md`、`Book.ts`には`Book.md`がある感じです。エージェントには、それらの`md`ファイルを読み書きするスキルを与えています：https://github.com/joist-orm/joist-orm/blob/main/packages/co... そして、エージェントが書いた`md`の更新がPRに現れています。今のところ有用そうです（私たちのメインリポジトリは35万行のTypeScriptモノリスです）。確かに、これは元記事の「各境界づけられたコンテキストへの出入りするエッジのグラフ」よりはるかに洗練されておらず（複雑でもなく）、おそらくまた私の「小さなd」DDDの好みが反映されています。私は「大規模なDDD」のパターンのいくつかは、過剰エンジニアリングにつながると感じています。
- owaiswiz
最初の方の段落で、LLMはグリーンフィールドプロジェクトで扱いやすいというのを読みましたが…私の経験は逆です。既存プロジェクトではうまく機能しますが、新しいプロジェクトではあまり良くありません（単純なものを雰囲気でコーディングしている場合を除いて）。既存プロジェクトでは、長年にわたって確立された構造や規約に依存できるので、私の経験ではより良い結果が出るのだと思います。
- scotty79
仕事の面接でDDDについて聞かれたとき、冗談で「デバッグ駆動開発（Debug Driven Development）」と言いました。空のディレクトリから始めて、最初のバグ「アプリが何もしない。〜すべき」を提出するんです。皮肉ではなく、今はまさにそのやり方でAIエージェントと仕事をしています。