HN 日本語サマリー

← 一覧へ戻る
プログラミング

開発駆動型仕様、仕様駆動型開発ではない

I Use Development-Driven Specs, Not Spec-Driven Development (github.com)

8 pointsby WaywardGeek5 コメント

要約

この記事は、AIコーディングエージェント「Ensemble」の開発手法について解説しています。従来の仕様書を作成してから開発するのではなく、開発を進めながら仕様を生成していく「開発駆動型仕様」を提唱しています。このアプローチでは、AIとのペアプログラミングを通じて専門知識を深め、その知識をAIが実行可能な仕様として保存することを目指します。

全文翻訳

開発駆動型仕様、仕様駆動型開発ではない

コードと仕様を同時に構築する。開発が仕様を獲得する。 目標は、詳細な計画を事前に作成してAIに渡したり、システムを適当にコーディングしてからソースコードを文書化したりすることではありません。目標は、AIとペアプログラミングすることで専門家になり、その専門知識を別のエージェントが実行できる形式で保存することです。

Billのワークフローは具体的です。

  1. 設計について議論し、次の章のTL;DRと演習のみをドラフトします。
  2. 実装をペアプログラミングします。AIをリアルタイムで誘導し、アイデアを試行錯誤し、間違いを修正し、何が不明瞭だったか、なぜ重要な決定が下されたのかを記録します。
  3. 実装が演習採点機を通過したら、それらのメモを使用して、章の本文を作成します。これは完成したソースコードのツアーではなく、構築プロセス、教訓、トレードオフ、および理由です。
  4. 新しい学生エージェントに章と採点機を与え、教育が実装を再構築するのに十分かどうかをテストします。その試みから明らかになったことを章にフィードバックします。

結果は実行可能な仕様です。システムを構築するために必要な判断を伝達するコードブックであり、単なる要求機能のリストではありません。Ensemble V2はこの本を実行してV3を構築しました。その後、BillとCadenceはV3内で作業して、エージェントと教育の両方を改善しました。個々の章は、文書化された検証制限を保持しています。

人間の専門知識は、見慣れない生成コードの最終検査に依存するのではなく、開発中に成長します。コードは出力であり、再利用可能な資産はそれを再度構築するために必要な知識です。何を構築するかを文書化するだけではありません。その方法と理由を教えます。すべてを事前に学ぶことはできません。

ここから始める

ビルドと実行

既存の.NET 10 SDKを使用します(ランタイムのみではアプリケーションをビルドできません)。ここにあるものは何もSDKをインストールしたり、ビルド用の認証情報を読み取ったり、サーバーを自動的に起動したり、インストール済みのアプリケーションを置き換えたりしません。

まず、シェルがSDKを見つけられることを確認してください。

dotnet --list-sdks # 10.x SDKが含まれているはずです

dotnetが見つからない場合、またはmakeがdotnet: No such file or directoryを報告する場合、ビルドはコンパイルに到達していません。SDK実行可能ファイルがシェルのPATHに見つかりません。すでにSDKをお持ちの場合は、現在のシェルのPATHにそのディレクトリを追加します(例のパスを実際のSDKディレクトリに置き換えてください)。

export PATH="/absolute/path/to/dotnet-sdk:$PATH"
dotnet --list-sdks

またはPATHを変更せずに、Makeに実行可能ファイルのフルパスを提供します。

make DOTNET=/absolute/path/to/dotnet
make cli DOTNET=/absolute/path/to/dotnet
# 他のターゲット(make testなど)でも同じオーバーライドを使用します。

例えば、SDKを$HOME/.local/share/ensemble-dotnet10にインストールした場合、make DOTNET="$HOME/.local/share/ensemble-dotnet10/dotnet"を使用します。これは例の場所であり、必須のレイアウトではありません。もし.NET 10 SDKがインストールされていない場合は、Microsoftの.NET 10ダウンロードからインストールし、新しいターミナルを開いて再度確認してください。

dotnetがPATHにある場合:

make # C# GUIをビルドし、./ensembleランチャーを書き込みます
make cli # C#ターミナルクライアントをビルドします
./ensemble --help # 明示的な起動。使用前にオプションを確認します。
# make cli の後のターミナルクライアント:
dotnet agent/Cli/bin/Debug/net10.0/ch04.dll --help

明示的なSDKオーバーライドを使用した場合は、ターミナルクライアントの起動時にもdotnetの代わりにそのフル実行可能パスを使用してください。

実際の起動には、独自のデータディレクトリ、ワークスペース、資金調達構成、および未使用のポートを選択してください。ソースをリフレッシュするためだけに実行中のホストを置き換えないでください。GUIはビルド時にアセットを埋め込みます。アプリケーションの動作と適格なテスト証拠については、クロスオーバーの章とソースREADMEを参照してください。

make testはC#回帰実行可能ファイルとルートGoツールテストを実行します。make test-goは後者のみをテストします。Goは、再利用可能な採点機、ローカルの偽プロバイダー、および公開ツール用にルートに残ります。アクティブなランタイムとしては使用しません。

実装の採点

各章で文書化された実行可能なコマンドとスコープを使用します。C#はGoソースコンシューマー採点機に送信してはなりません。例えば、第5章は明示的なgrade-edition3 -ch 5 -executable-onlyルートとその65のスコープ付きポイントを文書化しています。make grade CH=5 DIR=/path/to/CLI-wrapper GRADEFLAGS='-executable-only ...'は明示的なターゲットを必要とし、そのEdition 3コマンドに転送します。

実行可能な採点機番号と保存されたchNNスナップショットは元の意味を保持します。章のマッピングは、後続の原稿の番号変更を説明しています。履歴のEdition 2の採点はedition-2/から実行できます。Edition 1はedition-1/に残っています。どちらのアーカイブも現在のレイアウトのために書き直されていません。

書籍のビルド

make bookは現在の原稿を組み立てます。make ebookはEPUBをビルドします。make printは印刷用および読み取り用のPDFをビルドします。これらは既存のローカル出版ツールを使用し、それらをインストールすることはありません。前提条件と分離された出力については、ローカルでのビルド手順を参照してください。生成された出版物はソース編集とは異なります。ソースのプロモーションだけでは、新しい本を公開したりアップロードしたりしません。

パフィンブック

パフィンブックは、Gateway、Connections、Agenda、Puffin、および関連するWatchtower/セキュリティ作業の作業場所です。そのノートは開発駆動型仕様に従っています。アウトラインは暫定的なものであり、完了した機能ではありません。コーディングエージェントブックはbook/の下にあります。