Hacker Newsのひとりの開発者が、「仕様主導」から「開発主導」の仕様への転換を提唱しています。これは、ドキュメントの執筆プロセスとコードの執筆プロセスを不可分なものとする手法です。ソフトウェアと並行してリアルタイムに仕様を構築することで、開発者はAIコーディングエージェントがコードベースの新しいバージョンを自律的に生成・反復処理するために使用できる「実行可能な仕様」を作成します。

開発主導のワークフロー

投稿者のWaywardGeekは、AIエージェントと事前の設計に関する対話を行うプロセスを説明しています。その後、AIに対して、本の章のようなプロジェクトの「TL;DR（要約）」と演習セクションのみを生成するよう依頼します。

実装フェーズでは、開発者はAIとペアプログラミングを行い、実際のコードを執筆します。作業を進めながら、曖昧な点を明確にし、意図した設計へとAIを誘導するために、リアルタイムでノートを書き込みます。

コードが特定の「演習グレーダー」を通過すると、開発者はAIに対し、蓄積されたこれらのノートと「voice.md」ファイルを読み取って、章の最終的な本文を執筆するよう依頼します。これにより、ドキュメントが最終的な実装を正確に反映することが保証されます。

実行可能な仕様とAIの自律性

このアプローチの核心的な革新は、「実行可能な仕様」の作成にあります。WaywardGeekは、コードが書かれるのと同時に仕様が構築されるため、それがAIエージェントにとっての高精度な指示セットになると主張しています。

実際には、これにより「Ensemble」プロジェクトのようなAIコーディングエージェントが、仕様を自律的に実行できるようになります。エージェントは、各ステップでの手動介入なしに、更新された仕様に基づいてコードの新しいバージョンを生成できます。

開発者は再帰的な例を挙げています。彼らはこの手法を用いてAIコーディングエージェントの構築に関する本を作成し、そのエージェントがその本自体の次版を構築するためにその本を使用したのです。

コミュニティのフィードバックと拡張性の疑問

Hacker Newsのコメント欄では、このアプローチの仕組みに対する関心が示される一方で、実用的な適用に関する疑問も提起されました。defenestrationというハンドルネームのコメント主は、「通常の」チケットベースのソフトウェア開発ワークフローに依存する大きなチーム内で、この手法がどのように機能するのかを問いかけました。

別のコメント主であるgrugagagは、最終的な結果をよりよく理解するために、標準的なビジネスアプリケーションを構築するために使用されているプロセスの具体的なデモを要求しました。この議論では、この手法を個人のワークフローから共同作業の環境へとどのように移行させるかについて、より明確にする必要があることが浮き彫りになりました。

投稿者は、この手法が個人のプロジェクトにおいて非常に成功していると主張していますが、チーム全体での採用に関する具体的なトレードオフや制限については、議論の中で未解決の課題として残っています。

チーム統合における不確実性

「開発主導」の仕様がどのようにスケールするかについては、依然として大きな不確実性が残っています。この手法は人間とAIエージェントの間の密接で反復的なループに依存しているため、JiraやGitHub Issuesのような標準的なプロジェクト管理ツールとどのように統合されるのかは不明です。

ソースには、複数の開発者がバージョニングの競合やコミュニケーションのボトルネックを生じさせることなく、単一の「動的な」仕様にどのように貢献できるかについての詳細なフレームワークは提供されていません。