ドメイン駆動エージェント：LLMをレガシーコードで機能させる

LLMはグリーンフィールドプロジェクトでは輝くが、レガシーコードベースでは崩壊する。失敗の原因はモデルではなく、コードにある。重複した概念と絡み合った依存関係を持つ4年前のシステムには、モデルが推論するための根拠となる真実がない。既に3回存在する概念の4つ目の綴りを発明し、直接呼び出しで問題なかった場所にアダプタを書き、アダプタがまさに要点だった場所で直接呼び出しを行う。すべての推測は、コードベースが決して答えなかった質問なのだ。

著者の解決策は、ソフトウェア作業を戦略的と戦術的の2つに分ける。戦略的作業とは決定すること—システムを読み、何を変えるべきか、なぜ変えるべきかを理解すること。戦術的作業とは、その決定をファイルに反映することだ。経済性は変化した：タイピングはほぼ無料だが、決定には依然としてコストがかかる。そこで著者は戦略的部分を行い、戦術的部分をAIエージェントに委任する。

スキルとサブエージェント

実装では、GitHub Issueを引き継ぎポイントとして使用する。著者はコードベースを分析し、Issueを作成し、AIシステムがスキルとサブエージェントを使用してそれに対処する。スキルとは、タスクが一致したときにモデルが読み込む指示のマークダウンファイルであり、「Issueに対処する」は毎回同じ方法で実行される。サブエージェントは、独自の新しいコンテキストと狭い仕事を持つ別のモデルセッションである：実装、セキュリティのレビュー、仕様に対するレビュー。彼らはトランスクリプトを吐き出すのではなく、結果を報告する。

PRはレビュー準備完了の状態で返ってくる。著者はレビューし、承認するか、改善を求め、テストカバレッジとシステムのどの部分が壊れる可能性があるかを確認する。節約される時間は現実的だ：エンジニアは調整と計画を行うが、実装をタイピングしない。

基盤としてのDDD

ドメイン駆動設計が背骨となる。ユビキタス言語と境界づけられたコンテキストは、ビジネスとモデルの両方に共有語彙を与える。エージェントがループに加わると、そのつながりはさらに重要になる—モデルにニーズを伝え、その推論を読み取る方法だからだ。

すべてのリポジトリはルートに.workflow.jsonを持つ。このマニフェストは、リポジトリが何であるかをツールに伝える：言語、エージェントが最初に読むべきディレクトリ、合格しなければならないチェック。1つのブロックがドメインを宣言する—プロジェクト名、境界づけられたコンテキスト、各コンテキストの用語集が置かれている場所、サブドメインタイプ、隣接コンテキストへのエッジ。同期がずれる2番目のレジストリはない。

例はjob-offer-boxで、Rustバックエンド（hyperion）とWebフロントエンドを持つ求人応募トラッカーだ。フロントエンドのマニフェストは単一のエッジに切り詰められているが、このパターンはどのコードベースにも拡張できる。

準備は買うものではなく、作るもの

核となる主張：アップグレードが必要なのはモデルではない。コードが準備できていないのだ。準備とは、少しずつ、コンテキストごとに、段階的に構築するものだ。1つの境界づけられたコンテキストから始め、その用語集を宣言し、エージェントに言語を教える。次に、次のコンテキスト。時間が経つにつれて、コードベースはLLMが実際に機能できる場所になる。

これは「AIがエンジニアを置き換える」と「LLMは実際のコードでは役に立たない」の中間にある実用的な立場だ。エンジニアは難しい部分—決定—のためにループに留まり、エージェントは安い部分—タイピング—を行う。結果は、コードベースの明確さに逆らうのではなく、それに合わせてスケールするワークフローだ。