仕様書を先に書くな——開発しながら仕様を育てるAIエージェント構築術
I Use Development-Driven Specs, Not Spec-Driven Development
Bill Coxによる実行可能な教本『The Art of Building AI Coding Agents』のリポジトリ。仕様駆動開発ではなく「開発駆動仕様」を掲げ、設計を議論しながらAIとペアプログラミングし、つまずきや判断の理由を記録してから章本文を書く。完成コードの解説ではなく、別のエージェントが再構築できる知識を仕様として残すのが狙い。Ensemble V2が本書を実行してV3を構築した。
何を作るかを文書化するだけでは足りない。どう、なぜそう作るのかを教えよ。そのすべてを最初から学ぶことなどできないのだから。
HNでの議論
26- dromologist
私の日常業務は非常にレガシーなフレームワークを使っていて、最高の結果を得るためにはエージェントに大量のスキルや追加ツールなどを叩き込むことになり、今ではこのプロジェクト専用に設計されたハーネスになっていることに気づきました。
これは必要性から生まれた結果ですが、ハーネスを自分の特定の開発体験に合わせることは大いに役立つと思います。まるで欲しいプラグインを詰め込んだIDEのようなものです——ただしIDEではありません。なぜならIDEはもう終わっているからです。
- WaywardGeek
これにより実行可能な仕様が生まれます。それをEnsembleのようなAIコーディングエージェントに渡すと、仕様を自律的に実行し、コードの新しいバージョンを作成します。これは、私が「The Art of Building AI Coding Agents」を実行してEnsembleの新しいバージョンを作成するときに完璧に機能します。これほど成功した仕様を見たことがありません。
仕様はコードを構築しながら構築する必要があります。プロセスを分離することはできません。私はAIとの通常の事前設計会話を行い、次に次の章のTL;DRと演習セクションだけを書くように依頼します。その後、AIとペアプログラミングしてTL;DRに従って実装し、不明点を明確にするためのメモを随時書きながら、リアルタイムでAIを自分の設計に導きます。
新しいコードがすべての演習グレーダーに合格した後になって初めて、AIにメモとvoice.mdファイルを読ませ、章の本文を書かせます。次に、学生を起動して、章とグレーダーだけからコードを書けるかどうかを確認します。
このプロセスの終わりには、私は専門家であり、コードをレビューする必要すらありません。
コードは単に正しい仕様を実行した結果です。コンパイラのもう一つの成果物にすぎません。
バイブコーディングはやめましょう。コードを構築しながらAIとペアプログラミングして専門家になり、その後、コードを構築するために行ったことから仕様を構築しましょう。コードを構築するためにコードを文書化するのではありません。プロセス、学んだ教訓、そしてなぜこのように構築したのかを文書化するのです。それは事前にはできません。
ペアプログラミングの方法を知らなければ […]
- ozlikethewizard
「AIコーディングエージェントを構築する本。次の版を構築するエージェント。」
本当に？