ノーコードライブラリから得た教訓: スペック駆動開発は方程式ではなく三角形

AIコーディングエージェントの時代において、スペック駆動開発（Spec-Driven Development） を単なる「スペック → コード」という直線的な方程式として捉えるのは誤った見方だ、という内容。

核心的な主張

スペック駆動開発は 静的な方程式ではなく動的な三角形。
3つの軸が絶えず相互に影響し合うフィードバックループ:

• スペック (Spec)
• コード (Code)
• テスト (Tests)

この3要素が互いに同期されて初めて正しく機能する。

主な事例と実験

• Drew Breunigが作ったコードのないライブラリ whenwords
  → コードなしで、スペック（Markdown）+ 750個のテスト（YAML）だけを置き、AIエージェントにコードを生成させた
  → Andrej Karpathyの関心を集め、GitHubで1k超のスターと活発なコントリビューションが発生

しかし、こうした実験で繰り返し現れる問題:

• 実装は速いが、複雑さが少し上がるだけで一部分を直すと別の部分が壊れる
• 結局、ほとんどのプロジェクトが未完成のまま埋もれる
• スペックがどれだけ良くても、実装方法をめぐる議論が続く

なぜ三角形なのか?

コードを作っていくと → スペックの曖昧さや誤りを発見 → スペック修正 → 新しいテストが必要 → コードを再修正 → …
→ このプロセスが絶えず繰り返される ループ だから。

解決の方向としての提案: Plumbツール

Drewが作ったCLIツール Plumb

• Gitコミットのたびに、エージェントの対話ログとコード変更を分析
• エージェントが暗黙的に下した決定を抽出 → 開発者が承認
• 承認された決定 → スペックを自動更新
• スペック/テストのカバレッジギャップレポートを提供
  → 「コミット失敗モード」で重要な決定は必ず人間レビューを通すよう強制

歴史的文脈

今は1960年代の「ソフトウェア危機」を再び経験している最中。
当時はコードが大きくなりすぎて頭の中に収まらなかった → ウォーターフォール・アジャイル・CI/CDが誕生
今は コードを読むことすら不可能 になりつつある → 新しいプロセスが必要
→ Plumbのようなツールがその方向性を示す、という主張。

結論を一言で

AIがコードをものすごい速さで生み出す時代だが、
本当に難しいのは スペック・コード・テストの三角形を継続的に同期する ことだ。

https://aisparkup.com/posts/9837