AI はオーバーエンジニアリングをなくさない。加速させる

オーバーエンジニアリングとは、単純な課題を複雑なやり方で解くことです。ランディングページをマイクロサービスで組む、ユーザー十人のために Kubernetes を入れる、トラフィックが小さいのに百万リクエスト向けの構成にする。課題そのものより桁違いに複雑な解に、お金と時間を払っていることになります。

インセンティブがそう出来ています。複雑な解はプロらしく見え、単純な解は手抜きに見える。Kubernetes を選んだせいで解雇された人はいません。解雇されたのは、スケーリングを考えなかった人です。この非対称性のもとでは、保険をかけるほうが合理的であり、開発者は実際に保険をかけます。

AI が学んだのは公開コードと記事であり、そこで優勢なのは大企業の解です。ブログを書き、フレームワークを公開し、流行を作るのは彼らだからです。しかし彼らの課題は別物です。数百万のユーザー、数百人の開発者、規制当局の要求。

「認証を書いて」という要求に対し、モデルは最も多く見てきたものを返します。抽象化とインターフェースの層構造、そしてあなたの手元では決して起きないシナリオへの対応です。それはインターネット上の平均的な要求に対する正しい答えです。あなたのプロジェクトはその平均には入りません。

以前は、複雑化の代金を時間で払っていました。抽象化の層を五つ書くのは一週間の仕事です。三日目あたりで、本当に必要なのかと疑い始める。その値段がブレーキとして働いていました。

いまは同じ五層が一分で生成されます。コードは読めるし、テストは通るし、機能も動く。見た目には問題ありません。しかし複雑さの主な代金は、書くときではなく保守にかかります。半年後にそのコードへ手を入れる必要が生じ、そのとき請求書が届きます。これは、意識的な判断を経ずに一瞬で背負った技術的負債です。

オーバーエンジニアリングの唯一の自然なブレーキが消えました。生成の質の問題ではありません。コードは優秀でありうる。問題は、それが安くなりすぎたことです。

AI を編集者として使う

よくある筋書きはこうです。開発者がモジュールをゼロから生成させ、500 行を受け取り、そのままプロジェクトに貼り付ける。どこが余分かを調べる人はいません。動いているのですから。こうしてオーバーエンジニアリングは、たった一回の生成でプロジェクトに入り込みます。

順序を逆にすると、別の結果になります。

1. まず自分で書く。三十行、単純な JWT、検証関数ひとつ。その代わり、一行残らず理解できています。
2. 次に AI に渡して簡略化させる。「これがコードです。これが無くても動き続けるものを全部取り除いてください。捨てられる部分を示してください。」
3. 提案を吟味する。的外れなものも混じりますが、このモードのほうがモデルはうまく働きます。必要なものを考え出すより、余分なものを見つけるほうが正確だからです。

編集には基準点があります。あなたのコードと、課題についてのあなたの理解です。生成には基準点がなく、モデルは平均値を当てはめます。

もう二つの手立て。

• プロンプトでの制約。ゼロから生成するなら、枠をはっきり指定します。「動く範囲でいちばん単純な解を。フレームワークなし、抽象化の層なし。SQLite、ファイル一つ。」
• プロジェクトの文脈。「ユーザーは 100 人、サーバーは十ドル」という一文は、どんな言い回しの調整よりも答えを変えます。

AI エージェントを最も深く導入した企業は、生成のまわりに制約の層をまるごと築いています。

Stripe は公開されている説明によれば、週に千件を超える pull request を AI に通しています。エージェントへの課題は狭く定義されます。「機能を作れ」ではなく、厳密に区切られた変更です。エージェントが使える道具は手作業で選ばれています。結果はすべて検証を通ります。同社は結果の予測可能性のために、課題の規模を意図的に犠牲にしました。

Google、Shopify、Airbnb では構成が異なります。業界に単一の標準はなく、それぞれが自社のリスクに合わせて組み立てています。共通するのは、エージェントを既存のプロセス（GitHub、Slack、Linear）に組み込み、検証で囲うことです。

どこも生成結果をそのままは使いません。価値は、生成を囲む枠から生まれます。

AI は、開発者の頭の中にすでにあるものを増幅します。複雑にしたがる傾向なら数秒で実現し、余分を削ぐ習慣もまた同じ速さで実現します。

このコードはこの課題には複雑すぎる、という判断を下すのは、いまも人間です。AI はそれをより速く実行するだけです。