二つの結果、同じツール

同じAIモデルを使う二つのチームを観察すれば、まったく異なる二つの結果を目にするだろう。

最初のチームはモデルに画面の構築を指示する。出力は近いが、合っていない。スタイリングはFigmaファイルから逸脱する。状態管理は触るべきでないファイルにまで手を出す。ビルドはローカルでは通るが、CIでは誰も理解できない理由で失敗する。健全性チェックが落ちる。エンジニアはモデルが3分で生成したものを3時間かけて修正する。もう一度試す。同じ結果。彼らはAIコーディングは本番環境に耐えられないと結論づけ、実験は終わる。

二番目のチームもモデルに画面の構築を指示する。出力はやはり完璧ではない。しかし彼らは、モデルがどのファイルに触れるべきで、どのファイルを放置すべきかを正確に把握している。逸脱を即座に見抜き、修正を指示し、リリースする。本番環境でバグが表面化しても、慌てない。モデルに障害の追跡を指示し、パッチを生成させ、デプロイする。全サイクルは数分で済む。Redditに不満が投稿される。それらも同じ速さで、公の場で修正する。

同じモデル。同じプロンプト。まったく違う結果。

格差の正体はモデルではない

最初のチームはツールを責める。出力は信頼できない。モデルは幻覚を見る。生成されたコードは脆い。これらの不満は間違っていない。モデルは確かに幻覚を見る。生成されたコードは確かに脆い。しかし二番目のチームも同じ幻覚と同じ脆さに対処している。彼らはただ、立ち直りが速いだけだ。

格差の正体は自信だ。二番目のチームは単にcodebaseを十分に理解しており、モデルが崖に向かっている瞬間がわかる。どのboundaryが重要で、どれが重要でないかを知っている。彼らは十分な規模で十分な数の壊れたものをデプロイしてきたため、本番バグの修正は日常作業であって、存亡の危機ではない。彼らにとってAIはタイピングとボイラープレートを排除した。判断力を排除したわけではない。判断力はすでにあったのだ。

最初のチームにとって、AIはタイピングを排除したが、不確実性を増幅させた。モデルが正しいファイルに触れたかどうかがわからない。生成された状態管理が別の画面を壊すかどうかがわからない。CIの失敗が本当の問題なのか、不安定なテストなのかがわからない。AIが生成した変更はすべてサイコロの目だ。ほとんどの人は本番環境でサイコロを振りたがらない。

二番目のチームの正体

これは理論上の原型ではない。二番目のチームは、Claude Codeを構築した人々にかなり似ている。

Anthropicのエンジニアは世界最高クラスだ。彼らは分散システム、MLインフラ、ユーザー向け製品を大規模にデプロイしてきた。あらゆる障害モードを見てきた。AIがバグのあるrefactorを生成したとき、彼らは数秒で問題を見抜く――以前にまったく同じ失敗をしたことがあるからだ。本番環境が壊れても、どこを見ればいいかを教えてくれるguardrailは必要ない。彼らの直感がguardrailなのだ。

これが彼らが驀進できる理由だ。バグのあるコードをリリースし、記録的な速さで公に修正し、進み続ける。彼らの製品への不満はインターネット中に溢れている。彼らは減速しないし、エンジニアたちは眠れない夜を過ごしたりしない。安定性は重要だが、バグのコストは、それをリリースしたのと同じAIで数分以内に修正できるならば低い。

彼らにAutotomyは必要ない。Autotomyがルールにエンコードする判断力を、彼らのエンジニアはすでに持っているからだ。

99%の問題

業界の残りはAnthropicではない。

ほとんどのエンジニアリングチームには、大規模デプロイを何十回も経験したエンジニアはいない。AIが生成した悪いrefactorを数秒で見抜く直感もない。既知のバグをリリースしてライブで修正する自信もない。コードが本番環境で壊れれば、上司が質問してくる。QAが差し戻せば、締切がずれ込む。デモでリグレッションが表面化すれば、信頼が蒸発する。

これらのチームにとって、本番バグは5分の修正作業ではない。それはストレスに満ちた一日だ。利害関係者との会話だ。信頼性への傷だ。

彼らに必要なのは、エリートチームには必要ないもの――エリート級の判断力を必要とせずにAIの出力を信頼できるものにするフレームワークだ。boundary違反をマージ前に捕捉するguardrailが必要だ。振る舞いを独立して検証するcontractsが必要だ。AIが生成した変更すべてを再確認しなくて済むように、ルールをenforceするCIが必要だ。

彼らがAutotomyを必要とするのは、悪いエンジニアだからではない。彼らがAutotomyを必要とするのは、安定性が重要でミスに結果が伴う、普通の組織で働く普通のエンジニアだからだ。

エリートチームにもAutotomyは必要か？

おそらく。

エリートチームが驀進できるのは、エンジニアがどんな状況からも立ち直れるからだ。しかし、立ち直りにも時間はかかる。Anthropicのエンジニアでさえ、厳格なboundaryがあれば防げたはずのバグの修正に何時間も費やす。最高の直感でさえ、codebaseが十分に大きくなればエッジケースを見落とす。

問題は、予防のコストが回復のコストより低いかどうかだ。あらゆるバグを数分で修正できるチームにとって、予防はオーバーヘッドに感じられるかもしれない。違反を修正できるのに、なぜboundaryをenforceするのか？統合を目視で確認できるのに、なぜcontract testを書くのか？

しかし、チームは永遠にエリートのままではない。エンジニアは去る。codebaseは成長する。1年目にあらゆる悪いrefactorを見抜いた直感は、3年目には薄れてしまう。あらゆる暗黙の依存関係を知っていたエンジニアは別のチームに異動する。1万行で機能した驀進戦略は、10万行で負債になる。

Autotomyはエリートチームを減速させない。彼らの速度を持続可能にする。判断力を、異動や規模拡大に耐えるルールにエンコードする。個人の専門知識をチームのインフラに変える。

これがあなたのチームにとって意味すること

もしあなたが最初のグループ――AIを試して痛い目に遭い、自信を失ったグループ――にいるなら、あなたは一人ではない。あなたが多数派だ。AIコーディングをめぐる言説は、エリートオペレーターの仕事ぶりを見て、彼らのワークフローが自分の状況にそのまま適用できると思い込むことで歪められている。適用できないのだ。

あなたのチームはAnthropicになる必要はない。必要なのは、AIの出力を信頼できるほど安全にするシステムだ。つまり、厳格なboundaries。つまり、決定論的なenforcement。つまり、違反がQAに届く前にビルドを失敗させるフレームワークだ。詳しくは「AI Coding in Production: Why Most Teams Quit」で説明している。

これが真実だからだ。本番環境でのAIコーディングは、モデルが十分に優れているかどうかの問題ではない。モデルが高くつくミスを犯せないほど、システムが十分に構造化されているかどうかの問題だ。エリートチームは判断力によってそれを達成する。それ以外の全員にはguardrailsが必要だ。

目標はシンプルだ。AIを使って機能をリリースする。夜通し眠る。上司からの怒りのメッセージなしで朝を迎える。

AIコーディング格差に関するよくある質問

AIコーディングが一部のチームでは機能し、他では機能しないのはなぜか？

エリートチームは深いシステム直感を持っており、AIが生成したミスを即座に見抜き、立ち直ることができる。ほとんどのチームはその直感を持っていない。guardrailsがなければ、AIが生成した変更はすべて賭けに感じられる。賭けが失敗すれば、チームは自信を失い、AIの使用をやめる。

エリートチームは本当にバグのあるコードを生み出すのか？

そうだ。トップクラスのエンジニアリング組織でさえバグをリリースする。違いは回復速度だ。普通のチームなら診断と修正に1日かかるバグが、エリートチームなら数分で済む。彼らはバグを作業上のノイズとして扱い、存亡の脅威とは見なさない。

厳格なguardrailsはエリートチームを減速させるか？

当初はそうだ。boundariesとcontract testsの設定には時間がかかる。しかし、いったん存在すれば、enforcementは自動化され、数秒で実行される。長期的な利点は、codebaseの成長とエンジニアの入れ替わりに伴って、チームの速度が持続可能になることだ。

普通のチームが最初にすべきことは何か？

コードを生成する前にmodule interfacesを定義する。ビルドを失敗させるルールで、それらのinterfacesをCIでenforceする。システム全体から独立して振る舞いを検証するcontract testsを追加する。この3ステップにより、AIの出力はQAが何もかも差し戻さなくなるほど予測可能になる。より深い解説は「Deterministic Guardrails for AI Codebases」を参照。

目標はゼロバグか？

違う。目標は信頼できるAIコーディングだ。つまり、バグは局所的であり、診断可能であり、それを持ち込んだのと同じモデルで修正できるということだ。チームが3週目にAIを放棄するのではなく、6ヶ月目も使い続けるということだ。