ほとんどのチームが数週間でAIコーディングを諦める理由

AIコーディングを試すほとんどのチームは、同じ軌跡をたどる。

最初は興奮している。モデルが数分で機能を生成し、それをリリースする。QAがバグを見つけ、修正をリリースする。QAがさらに別のバグを見つける。今度は無関係であるはずの別のmoduleだ。修正は14ファイルに及び、QAはさらに3つの問題を発見する。

チームは怖くなり、モデルは本番環境に耐えられないと結論づけ、手動でコードを書くやり方に戻る。AIは自動補完のおもちゃになる。

これが本番環境でのAIコーディングの最も一般的な結果だ。リリースの高速化でもなければ、10倍のエンジニアでもない。撤退で終わる短い実験にすぎない。

モデルは問題ではない。問題は、モデルがコードを生成するよう指示された対象だ。

本番codebaseはAI以前からすでに脆かった

ガードレールのない本番codebaseは常に混乱していた。unit testなし。アーキテクチャenforcementなし。module boundaryなし。ただ、楽観主義だけでつなぎとめられた、誰も完全には理解できない方法で互いにimportし合うファイル群があるだけだ。

AI以前は、この混乱は人間の速度で成長していた。エンジニアはゆっくりとコードを書いた。バグはゆっくりと持ち込まれた。QAはゆっくりとそれを捕捉した。システムは徐々に劣化した。腐敗に気づく時間があった。

そのコストは依然として現実のものだった。脆いcodebaseは人材を燃え尽きさせる。エンジニアは問題を解決するのではなく、スパゲッティコードをかき分けるのに日々を費やすからだ。士気は下がる。離職率は上がる。最も優秀なエンジニアが最初に去る。

しかし、被害は人間の速度によって上限が決まっていた。

AIコーディングの速度が無防備なシステムを破壊する理由

AIが変える変数は一つだけだ。速度だ。モデルは人間の10倍の速さでコードを書く。機能、エンドポイント、マイグレーションを数分で生成する。codebaseは機械の速度で成長する。

しかし、そのcodebaseが成長する先は、同じ脆く無防備なシステムだ。同じ暗黙の依存関係。同じboundariesの欠如。同じ、スケールできない手動QAプロセス。

こうしてパターンは加速する。より多くのコード。より多くの結合。より多くのバグ。より多くのQA不合格。より多くの手動修正。より多くの恐怖。チームが諦めてAIを「我々のユースケースにはまだ早い」とレッテルを貼るまで。

QAの失敗がAI生成コードへの信頼を破壊する仕組み

AI生成コードがQAに不合格になると、エンジニアはモデルに修正を依頼しない。手動で修正する。

モデルは信頼できないと、すでに学習しているのだ。最初のバグは機能の中にあった。2つ目のバグはモデルが間接的に触れたmoduleの中にあった。3つ目のバグは、2つ目の修正中にモデルが持ち込んだリグレッションだった。4度目のQA不合格までに、エンジニアは手動でデバッグしている。

これが本当のボトルネックだ。生成速度ではない。信頼だ。チームはAIの速度を活用できない。生成されたものを信頼できないからだ。そして生成されたものを信頼できないのは、モデルがmoduleを跨ぐ混乱を作り出すのを防ぐ構造的フレームワークが存在しないからだ。

ガードレールがなければ、AIが生成した変更はすべて賭けだ。ほとんどのチームはギャンブラーではない。

ガードレールが手動修正よりも安価になった理由

実際に変わったのはこれだ。AI以前は、包括的なcontract testの作成、アーキテクチャenforcementの設定、module boundaryの構築は高コストだった。人間の時間が必要だった。チームはその時間が捻出できず、ガードレールを省略していた。

今やモデルは数分でテストスキャフォールドを生成する。Semgrepルールを書く。adapterのボイラープレートを生成する。CIパイプラインチェックを構築する。モデルは機能を構築するのと同じ速さでガードレールを構築できる。

ボトルネックは「ガードレールに手が回らない」から「どのガードレールを最初に構築すべきかわからない」にシフトした。

これを見抜いたチームは賭けをやめる。リリースを始める。

AIコーディングのガードレールとは何か

AIコーディングのガードレールとは、生成されたコードを境界内に留める構造的ルールだ。lintルールやスタイルガイドではない。アーキテクチャ上のcontractsだ。明示的なmodule interface。composition rootを通じた依存関係の配線。外部サービス向けのadapterレイヤー。そしてそれらのboundariesに違反するコードを拒否するCI enforcement

ガードレールがなければ、AIモデルはどこに触れてよいかの地図を持たない。moduleを跨いでimportし、ビジネスロジックの中で依存関係をインスタンス化し、ベンダーSDKをdomain codeの奥深くに埋め込む。生成セッションのたびに、レビューするエンジニアにとって宝探しゲームになる。ガードレールがあれば、モデルはコードを1行も書く前にシステムの形状を把握し、コンパイラまたはCIパイプラインが違反をQAに届く前に拒否する。

AIコードを信頼できるものにする5つのガードレール

AI生成コードが一貫してQAを通過することを望むなら、これらはオプションではない。これらが信頼レイヤーだ。

  • すべてのmoduleに明示的なinterfaceを持たせる。例外は許さない。
  • すべての依存関係をcomposition rootを通じて配線する。ビジネスロジック内での直接インスタンス化は禁止。
  • すべての外部サービスを、アプリケーションが所有するadapterでラップする。domain codeにベンダーSDKを入れない。
  • すべてのboundaryをCIでenforceする。警告はenforcementではない。
  • すべてのcontractに、型シグネチャだけでなく振る舞いを検証するテストを持たせる。

これらのルールは提案ではない。AIが生成した変更が局所的であり続けるcodebaseと、宝探しゲームになるcodebaseの違いだ。

AIがboundaryを越えるコードを生成したとき、スケールにおいて人間のレビュアーはそれを捕捉できない。スケーラブルな唯一の防御は、違反をマージ不可能にすることだ。

Autotomyが本番環境でのAIコーディングにとって意味すること

Autotomyは動作原理だ。生物が死ぬことなく故障した部位を切り離せるように、システムを構築すること。

実際には、それはあるmoduleのバグがシステム全体を理解しなくても診断可能であることを意味する。統合の失敗は単一のboundaryを指し示す。リグレッションは変更があった表面に隔離される。

Autotomyはバグゼロを約束しない。モデルは幻覚を見る。エッジケースは潜んでいる。統合表面はトレーニングデータが捕捉しなかった振る舞いをする。一部のバグは常にすり抜ける。

しかしAutotomyは高くつくバグを排除する。高くつくバグとは、単一のmodule内部のロジックエラーではない。module同士がどこで触れてよく、どこで触れてはいけないかを誰もenforceしなかったためにboundariesを越えて拡散する障害だ。誤ったロジックではなく、構造的な不注意によって生み出されるバグだ。

表面積を排除すれば、チームがAIへの信頼を失う原因となる種類のバグを防ぐことができる。境界づけられた障害はモデルが修正できるものだ。分散した障害はモデルが悪化させるものだ。

信頼のテスト:あなたのチームは自信を持ってAIコードをリリースできるか

本番システムの評価基準は欠陥数ではない。チームがAIを使い続けるほどシステムを信頼しているかどうかだ。

厳格なboundariesを持つシステムは、AI生成コードを安全に吸収できる。認証adapterが壊れれば、認証adapterを修正する。boundaryが明確でcontractが明示的だから、モデルはそれを再生成できる。QAは通過する。チームは再びリリースする。

boundariesのないシステムにはそれができない。何かが壊れると、障害は暗黙の依存関係全体に分散する。モデルはそれを修正できない。構造のないシステムについて推論できないからだ。QAは不合格。エンジニアは手動で修正する。信頼は浸食される。

それがテストだ。AIがコードを書けるかどうかではない。AIが、チームがリリースするに足ると信頼できるコードを書けるかどうかだ。

選択:機能の速度か、構造的安全性か

AIコーディングツールを使うチームは、二者択一の選択に直面する。

同じ脆いシステムの中で、より多くの機能を生成するために速度を使うことができる。より多くのコード。より多くの結合。より多くのQA不合格。チームが諦めて人間の速度に戻るまで。

あるいは、まずガードレールを構築するために速度を使うことができる。厳格なboundaries。包括的なcontracts。決定的なCI enforcement。その上で、違反を不可能にするシステムの中で機能を生成するためにAIを使う。

明白な代替案は、QAの人員を増やすか、プロンプトエンジニアリングにより多くの時間を費やすことだ。これらは限界的には役立つが、構造的問題を解決しない。手動QAは線形にしかスケールしない一方、AIの出力は指数関数的にスケールする。より良いプロンプトはmodule内部のエラー率を下げるが、モデルが存在を知らないboundaryを越えるのを防ぎはしない。スケーラブルな唯一の防御は、違反をマージ不可能にすることだ。

最初の道は、QAが差し戻すまでは進歩のように感じられる。2番目の道は、最初の1週間だけオーバーヘッドのように感じられる。

違いは、3ヶ月目にチームがまだAIを信頼しているかどうかだ。

これらのガードレールがすでに組み込まれた本番対応の基盤が必要なら、Autotomy Expoスターターキットから始めよう。