小さな変更すべてに blast radius があるとき

最初の Vibe coding フェーズは、信じられないほど生産的に感じられます。Cursor と Claude Code は login、dashboard、settings、push notifications まで一気に生成できるので、solo founder でも数日で MVP を live にできます。

問題が出るのは 2 回目、3 回目の変更です。settings の小さな tweak で auth が壊れる。profile の更新で notifications が乱れる。bug は無関係に見えるのに、コードには強制された boundary がないので、app のどの部分も別の部分に波及してしまいます。

レガシーは初日から始まる

コードはコミットされた瞬間にレガシーになります。問題はレガシー化するかどうかではなく、そのレガシーが辿れるものか、地雷原のようなものかです。

従来の開発では、コードレビューやアーキテクチャ判断記録、そして「それは違う」と言えるシニアエンジニアがこの役割を担います。しかし AI で 10 倍の速度で出荷するなら、人間をすべての検証ループに置くことはできません。

宣言的な制約が答え

有効なのは O(1) ガード、つまりミリ秒で走る決定論的で宣言的なチェックです。

  • 型システム がコンパイル時にインターフェース違反を見つける
  • dependency-cruiser のルール がモジュール境界を強制する
  • JSON Schema 検証 が契約の充足を確認する
  • pre-commit hooks がコード着地前にすべてのチェックを走らせる

これらは提案ではなく、交渉不可のゲートです。人が書こうが AI が書こうが、通らなければ出荷しません。

なぜ LLM を検証ループに入れないのか

LLM を検証役に置くのは一見よさそうですが、実際には破綻します。

  1. 非決定的：同じコードでも今回通り、次回落ちることがある
  2. コンテキストウィンドウの限界：コードベースが大きくなるほど前提を落とす
  3. 速度：LLM レビューは秒単位、決定論的チェックはミリ秒単位
  4. コスト：毎回 token と費用が発生する

ガードレールは退屈なくらいでちょうどいい。毎回同じであることが価値です。

はじめ方

Autotomy の Expo Starter には、このガードレール一式が最初から入っています。各モジュールは明確なインターフェースを持ち、依存ルールは pre-commit で強制され、型カバレッジも必須です。つまり AI の速度と、アーキテクチャの安全性を同時に得られます。