デモは常に動く

すべてのAIコーディングデモは同じ流れをたどる。誰かがモデルにプロンプトする。動くアプリが現れる。聴衆は感心する。

当然そうなるべきだ。速度は本物だ。能力は本物だ。バージョン1はAIがループに入ることで確実に速く出荷される。

問題は、バージョン1は決して難しい部分ではなかったということだ。

コストが実際にかかる場所

ソフトウェアエンジニアリングのコストは初期作成に集中しない。反復の4回目、5回目、6回目に集中する：

  • 価格が変わったため認証プロバイダーを変更する必要がある。
  • ベンダーが買収されたため分析基盤を移行する必要がある。
  • 最初の生成が想定しなかった3つの画面にまたがる機能を追加する必要がある。
  • デザイナーが方向転換したためスタイリングシステムを置き換える必要がある。
  • プロダクトが新市場に拡大したため決済連携を切り替える必要がある。

これらはいずれも初期生成の失敗ではない。すべて通常のプロダクト開発だ。問題は、codebaseがこれらの変更を安くするか高くするかだ。

変更圧力下のAI生成codebase

大半のAI生成codebaseは最初の変更を問題なく処理する。2回目の変更は居心地が悪い。4回目の変更までに、チームは同じ症状を報告し始める：

  • 「AIに認証プロバイダーの切り替えを頼んだが、14ファイルに影響した。」
  • 「refactorが、無関係なはずのmoduleのテストを壊した。」
  • 「システムのどの部分が分析SDKに依存しているかわからない。」
  • 「すべての変更にcodebase全体の再理解が必要だ。」

これらの症状はモデルの失敗ではない。アーキテクチャの失敗だ。モデルが境界のないシステムを生成し、今やすべての変更の爆発半径が予測不能になっている。

AI生成codebaseがより速く劣化する理由

従来のcodebaseも劣化する。しかしAI生成codebaseは特定の理由でより速く劣化する：

共有メンタルモデルがない。 人間のチームは数ヶ月かけて構造的直観を構築する。AIは、過去の決定がなぜ行われたかの記憶なしにコードを生成する。

目前のプロンプトへの最適化。 モデルは現在のリクエストを解決する。次の5つのリクエストに対しては最適化しない。すべての生成は、局所的には正しいが大域的には非一貫な決定を行う。

量が結合を増幅する。 AIはより多くのコードをより速く生成する。弱い境界を持つ多くのコードは、より多くの結合をより速く意味する。速度の優位性が劣化の加速器になる。

refactorにはグローバルなコンテキストが必要。 コンテキストウィンドウは有限であり、アーキテクチャの意図は暗黙的であるため、モデルはcodebase全体にまたがるrefactorに苦労する。

本当のエンジニアリング上の課題

AI-native開発における本当のエンジニアリング上の課題は「より良いコードをどう生成するか？」ではない。

「AI生成部分を独立して変更できるようにシステムをどう構造化するか？」だ。

それは以下を意味する：

  • 爆発半径を予測可能にする境界。
  • 変わるものと変わらないものを分離するinterface。
  • 依存関係グラフを明示的にするcomposition root。
  • 完全なシステムを必要とせずに結合点を検証するcontract tests。
  • 連鎖的な障害なしにどのmoduleも削除して再生成できる能力。

長期保守は構造の問題である

すべてのmoduleが他のすべてのmoduleに手を伸ばすcodebaseを、より良いプロンプトで修正することはできない。アーキテクチャの結合からプロンプトで脱出することは不可能だ。

AI codebaseの長期保守には、常に必要だったのと同じ規律が求められる：境界、contracts、分離。違いは、AIの速度がこれらの規律の不在をより速く可視化することだ。保守不能なモノリスを作るのに2年かかっていたチームが、今では2ヶ月で同じことができる。

速度は贈り物であり罠でもある。構造なしには、保守の危機により早く到達するだけだ。

AI-Nativeアーキテクチャとの関連

これはStanford CS146S Is Right About AI Coding — The Missing Subject Is Architectureで述べた核心的な主張だ。アーキテクチャの規律なきツール習熟は、作成は速いが保守にコストがかかるcodebaseを生み出す。

現代のソフトウェア開発者は両方を必要としている。速く出荷するためのAIツール。バージョン1以降も速く出荷し続けるためのアーキテクチャの規律。

バージョン1は決して問題ではなかった。問題は、バージョン5がまだ安いかどうかだ。

FAQ

AI生成codebaseが保守しにくくなる理由は？

AIモデルは目前のプロンプトに対して最適化し、将来の変更に対しては最適化しない。これは動くが独立した修正に必要な境界を欠くコードを生み出す。明示的なアーキテクチャ上の制約がなければ、AIがより多くのコードをより速く生成するため、結合は手書きのcodebaseよりも速く蓄積する。

AI codebaseの経年劣化をどう防ぐか？

3つの構造的プラクティス：アプリケーションが所有するinterfaceでmodule境界をenforceすること、composition rootに依存関係の接続を集中させること、結合点を独立して検証するcontract testsを実行すること。これらによって、コードがどう生成されたかに関わらず変更コストが予測可能になる。

AI生成コードは人間が書いたコードよりrefactorしにくいか？

本質的にはそうではない。しかしAI生成コードは、モデルが自発的に将来の変更に対して最適化しないため、refactorを安全にする構造的境界を欠く可能性が高い。修正方法は、モデルが自ら境界を生成することを期待するのではなく、生成前にそれらの境界を課すことだ。

長期プロジェクトにとってAIコーディングの最大のリスクは？

最大のリスクは速度の罠だ。初期フェーズであまりに速く出荷するため、チームが気づく前にアーキテクチャ上の負債が蓄積する。保守が高コストになった頃には、codebaseは結合が強すぎて段階的に修正できない。