エージェント型コーディングのためのミザンプラス: コンテキストエンジニアリングの方法論としての入念な準備 で提唱されたミザンプラス（mise en place、MEP）は、 「すべてを所定の位置に」を意味するフランス料理の用語を借りた、エージェント型コーディングのための構造化された 準備の方法論である。その前提は、著者の言葉によれば、エージェント型コーディングにおけるアラインメントの問題は 本質的に準備の問題だというものである。すなわち、エージェントがコードを書き始める前に、ドメインの専門知識、 設計意図、タスクの境界を構造化された成果物として外在化しておけば、得られる実装はよりアラインしていて一貫性が 高く、検証のコストも低くなると論じられている。MEP はこの準備を、コンテキストの基盤づくり、協働的な仕様策定、 タスク分解という、フェーズごとにゲートで区切られた 3 つの逐次的なステップとして形式化する。各ステップは次の ステップの入力となる成果物を生み出し、すべてが実装開始前に完了する。その後、並列のエージェントが分解された 作業を実行し、その出力は統合検証で合流する。
用法
コンテキストの基盤づくりでは、実践者がドメインの専門知識と暗黙知をブリーフィング文書——ドメイン知識、 競合分析、設計思想を記述した Markdown ファイル——として外在化し、これがエージェントが実装の全過程を通じて参照 する永続的なコンテキスト層となる。逆向き設計（backward design）に従い、機能からではなく成果から出発する。 協働的な仕様策定では、構造化された人間とエージェントの対話（実践者が意図を説明し、エージェントが詳細を 提案し、実践者がそれを受け入れ、却下し、あるいは修正する）によって設計文書を作成する。その鍵となる仕組みは、 何を除外するかも含めて価値判断を仕様の制約として符号化し、「何を」だけでなく「なぜ」も記録することで、 エージェントがエスカレーションせずにアラインした細かな判断を下せるようにすることである。タスク分解では、 仕様を、優先度と受け入れ基準を備えた依存関係を考慮したタスク記録へと変換する——著者は Beads を 用いた——ことで、複数のエージェントが同時に作業できるようにする。協調の負担は実行時から準備時へと移る。
同論文は MEP を 仕様駆動開発 と プロンプトエンジニアリング に対して位置づけて いる。仕様駆動開発に対しては、暗黙的で価値判断を含む知識のためのフェーズを加えて拡張するものとし、 プロンプトエンジニアリングとはスコープが異なるとする。プロンプトエンジニアリングが個々のモデル呼び出しを調整 するのに対し、MEP はそれらに先行し、それらを制約するワークフローレベルの成果物を構造化する。また MEP を バイブコーディング とはスペクトルの反対端に位置するものとして提示しており、反復的な流れが手戻りとして 少しずつ支払うアラインメントの作業を前倒しで行うとしている。
適用される場面
著者は、エージェントには人間の協働者が持っている暗黙のコンテキストが欠けており、高コストな再生成なしには安価に 反復できないため、エージェント型のワークフローにはこの種の準備が必要だと論じている。MEP は、関連するドメイン 知識を言語化でき、明示的な依存関係を持つ独立に実行可能な単位へと作業を分解できる実践者を前提としており、 複数のエージェントが並列に実装する構成を対象としている。同論文は誤用のパターンを挙げていない。未解決の問いと して、何をもって「十分な」コンテキストとするのか、準備をいつ止めるべきか、そしてこの方法がプロトタイピングから 数か月に及ぶ開発へとスケールするかどうかを挙げている。
その証拠の基盤は、著者自身も認めるとおり薄い。実践者 1 人、対照群なしの 5 時間のハッカソン 1 回のみであり、 そこでは約 2 時間の準備の後に 4 つのエージェントによる並列実装が行われ、その後に構造的なリファクタリングは 必要なかった。著者は、これでは因果関係を立証できないこと、また教育とソフトウェアエンジニアリングという自身の 二重の経歴が結果の交絡要因になっていることを認めており、MEP を検証済みの手法ではなく、経験豊富な実践者が それぞれ独立にたどり着く実践を形式化した出発点のフレームワークとして位置づけている。