Carlos Azaustre が自身の個人ブログで公開したこの記事は、バイブコーディング と 仕様駆動開発 を対比し、ソフトウェアが本番環境に向かう場合には常に後者を選ぶべきだと論じている。著者はこの記事を、Apple Coding Academy の Swift Agentic Engineering Program で取った自身の授業ノートをブログ向けに書き直したものとして提示している。したがって記事が記録しているのは、独立した研究ではなく、1 人の受講生が書き留めた講座の内容である。
記事の中心的な主張は役割の変化である。エンジニアが仕様を書き、AI がコードを生み出す。記事の言葉によれば、仕様駆動開発においてはコードは信頼できる情報源ではなく、仕様こそがそれであり、コードは仕様の副産物である。AI に関数を自動補完させればタイピングは省けるが、エージェントが自律的に実行する完全な技術的契約を書くことは、記事によれば、より少ない思考ではなくより多くの思考を要求する。
記事の大部分は、これを機能させる環境についての実践的な説明である。エージェントに永続的なコンテキストを与えるファイル、コンテキストウィンドウの経済性、エージェントが破壊的な行動をとらないようにする制御、そしてエージェント型システムのセキュリティ上のリスクを扱い、最後に記事が GitHub Spec Kit に由来するとする 4 つの段階からなるサイクルで締めくくられる。
要点
- 記事の説明では、バイブコーディングはプロトタイプには問題ないが、本番環境では有害である。その理由として挙げられているのは、AI が悪いコードを書くというよりも、目にしたパターンと一貫したコードを書くという点である。コンテキスト内の悪い慣行や誤った設定は複製される。モデルはパターンが正しいかどうかを評価せずにそれを補完するからである。
- 記事の枠組みでは、AI はエンジニアリングの判断力を生み出すのではなく、それを増幅するにすぎない。精密なコンテキストと明確な仕様があれば素早く堅実な結果を生むが、曖昧なプロンプトと完全な自律性のもとでは、コンパイルは通るが本番環境で失敗するコードを生む。
- エンジニアの役割は「オーケストレーションアーキテクト」として説明されている。仕様を精密に書き、AI が何かに手を付ける前にその提案する計画をレビューし、明示的なチェックポイントで実装を検証し、エージェントが取るべきでない近道を取ったときにそれを見抜くことである。
- 曖昧なプロンプトは品質の問題であると同時にコストの問題としても提示されている。不正確な依頼はモデルに手探りでファイルを探索させ、仮説を立て直させる。記事の処方箋は CRISP プロンプトパターン、すなわち Context、Role、Instructions、Specifications、Polish/Criteria である。
- プロジェクトの契約ファイル（
CLAUDE.mdまたはConstitution.md）は最も重要なファイルとされている。スタック、コード規約、禁止事項を、その理由を示す具体例とともに記す。記事は、モデルはその言語での技術的な指示をよりよくカバーしているという理由でこのファイルを英語で書くこと、そしてFORBIDDEN、ALWAYS、NEVERのような断定的な大文字表記を使うことを推奨している。モデルは解釈の余地のない制約によりよく反応するからだという。 - Agent Skills は、エージェントが必要なときにだけ読み込む Markdown ファイルとして説明されている。各スキルは
/skillsディレクトリ内のそれぞれのサブフォルダに置かれ、YAML フロントマターを持つ必須のSKILL.mdを含む。著者自身の慣習は、スキルの説明はユーザー向けにスペイン語で、技術的な指示は英語で書くというものである。 Memory.mdファイルは、エージェントがユーザーとともに学んだことを保持する。記事は、200 行または 25 KB を統合が必要になる目安として挙げており、統合は通常、定期的にファイルを圧縮するサブエージェントによって行われる。それを超えるとエージェントがファイルを全部読まなくなるからである。- コンテキストは、呼び出しのたびに消費される予算として扱われている。記事は、コンテキストウィンドウが満杯になるずっと前から品質が低下し始めると述べ（コンテキストロット を参照）、作業のひと区切りの終わりには
/compactを、長い中断の後やタスクが根本的に変わったときには/clearを使うことを推奨している。 - 中断について、記事は KV キャッシュの TTL が 5 分であり、それを過ぎてから再開すると、続けていた場合よりもコストがかかると述べている。著者は、これを最も強く感じたのは OpenClaw を使ったときだと報告している。
- モデルのオーケストレーションについて、記事は推論、計画、アーキテクチャを Opus に、定型的な実装と検索を Sonnet に、単純なタスクと単発のサブエージェントを Haiku に割り当て、Opus は Haiku の約 19 倍高価だとしている。
- Plan Mode（コードを変更する前に計画を生み出す読み取り専用の調査）と エージェントフック（モデルの外にあってエージェントが無視できない Bash または Python のスクリプト。破壊的なコマンドや
.envの読み取りをブロックするPreToolUseフック、リンターの通過を必須とするPostToolUseフックなど）は、実際のプログラム的なガードレールの源としてまとめて提示されている。 - セキュリティについて、記事は プロンプトインジェクション、プライベートなデータ、制御されていない外部コンテンツ、外部への通信の組み合わせ（記事はこれを致命的な三要素と呼ぶ。致命的な三要素 と比較のこと）、そしてサードパーティの MCP サーバーやプラグインによるサプライチェーンのリスクを挙げ、サードパーティの MCP サーバーはインストールする前にそのソースを監査するよう助言している。記事が推奨する緩和策は、入力のサニタイズ、システムプロンプトの優先順位の明示、そしてエージェントに自由なテキストではなく固定のスキーマを埋めさせる型付きの応答である。
- 締めくくりのサイクルは 4 つの段階からなる。仕様、技術計画（Plan Mode で作成され、人間が承認する）、それぞれに受け入れ基準を持つ細分化されたタスク、そしてチェックポイントを伴う実装である。記事は、計画のレビューが最も頻繁に省かれるステップであり、かつ最も多くの技術的負債を回避するステップであるとしている。
- 記事は、仕様駆動開発によって技術的知識のない人が本番用のソフトウェアを作れるようになるわけではないと明言している。むしろその逆であり、もっともらしいが誤ったアーキテクチャや、保守を複雑にする近道を見抜ける有能なエンジニアが必要になると論じている。
背景
この記事は、専門家の手法ではなく学習ノートとして自らを位置づけている。記事が示す具体的な数値のうち、コンテキスト劣化の閾値や引用しているセキュリティ統計などは他の出版物へのリンクとともに示されているが、キャッシュの TTL やモデルの相対的なコストなど、出典なしに述べられているものもある。
記事はバイブコーディングの居場所も残している。著者は、バイブコーディングは週末のプロトタイプや、アーキテクチャを確定する前にアイデアを検証する用途では今後も役に立つと述べ、仕様駆動開発は、スケールし実際のユーザーのデータを扱うソフトウェアのためにとっておくとしている。