2026 年 3 月 30 日付の Tim Rutte の記事は、多くの開発者は AI コーディングツールを使う際に間違ったものを最適化していると論じる。長いプロンプトや多くのコンテキストでより速い生成を追い求めているが、問題はモデルではなく、その周囲に構造がないことだというのである。彼が根拠として挙げるのは、よりよいプロンプトでは直らないと彼が言う失敗パターンである。コードは動き、テストとリントを通過してマージされるが、その後の数週間で、どの単一のコミットでも明らかにはならなかった境界違反によってアーキテクチャが少しずつずれていく。彼の答えは、よりよいプロンプトではなく、よりよいワークフローである。
彼が説明するワークフローは、オープンソースの Claude Code プラグインである Superpowers を仕様駆動開発と組み合わせるものである。記事の説明によれば、Superpowers は Claude に一連のスキルを与える。スキルとは構造化された Markdown ファイルで、関連するときにコンテキストウィンドウに読み込まれ、手元のタスクに対応するスキルが存在する場合、Claude はそれを使わなければならない。また Superpowers は Brainstorm → Plan → Implement という順序を強制する。著者の見方では、その順序を安定させるのが仕様駆動開発である。
要点
- 作業の種類によって伴うリスクが異なるため、記事では種類ごとに別の仕様テンプレートを用意している。機能仕様（課題、スコープ内、スコープ外、アーキテクチャ上の制約、成功基準、未解決の問い、マイルストーン）、バグ修正仕様（課題、根本原因、影響を受けるコンポーネント、再現手順、修正方針、回帰テスト、検証）、雑務仕様（動機、スコープ、スコープ外、方針、完了の定義）である。
- 記事が不可欠とする項目は種類によって異なる。機能では「Out of Scope」セクションである。何が除外されるかを伝えなければ、エージェントは隣接する機能へと逸れていくからである。バグ修正では根本原因の仮説である。仮説を持たないエージェントは、症状が消えるまで手当たり次第に変更を加えるからである。雑務では完了の定義であり、これによってエージェントはいつ止まればよいかがわかる。
- 仕様ディレクトリの README がワークフローを記述しており、それが CLAUDE.md から参照されているため、エージェントはセッションの開始時に毎回その構造を把握できる。
- 仕様が完成すると、エージェントは仕様の種類に由来するプレフィックスを持つブランチを作成する。計画スキルが仕様を 2〜5 分のタスクに分解し、それを計画としてコミットし、実装タスクはそれぞれ個別のコミットになる。レビュースキルは、一般的なベストプラクティスではなく、その特定の仕様に照らして各タスクをチェックする。
- TDD スキルは red/green/refactor のサイクルを厳格な制約として強制する（Red/Green TDD を参照）。失敗するテストより先に書かれた実装コードは削除しなければならず、エージェントはテストランナーの実際の出力を提示しない限り、あるステップをグリーンと宣言できない。テストは実装ではなく、仕様の受け入れ基準に対して書かれる。
- 著者は、アーキテクチャ上の制約はプロンプトではなく仕様に書くべきだと主張する。プロンプトで与えた制約は次のセッションでもう一度与えなければならないが、仕様に記述した制約はワークフローとともに読み込まれ、計画で尊重され、レビューでチェックされるからである。
- 記事はこの手法の限界も挙げている。環境やインフラのデバッグは対象外であること、質の低い仕様からは、仕様に対しては正しいが本当に必要だったものとしては間違った実装が生まれること、そして独自のアーキテクチャルールは、個人用のスキルや仕様のアーキテクチャ上の制約のセクションに、依然として書き出しておく必要があることである。
背景
これは著者自身が推奨するセットアップであり、計測された比較としてではなく、バックエンド開発における彼の経験から示されている。記事によれば、Superpowers は Jesse Vincent と Prime Radiant のチームによって開発され、2026 年 1 月から Anthropic の公式プラグインマーケットプレイスで提供されている。記事の結びの主張は、経験豊富な開発者が習慣として実践している規律（境界をわきまえること、テストを先に書くこと、まとまりのある単位でコミットすること、要件に照らしてレビューすること）が、プロンプトで指示されたからではなく、ワークフローがそれを要求するからこそ、エージェントのデフォルトの振る舞いになるというものである。