9月19日、Towards Data ScienceにてAlex Mathers氏が「AI Made Me 5x Faster. It Also Made Me 5x Worse at My Job.」と題した記事を公開した。AIによって開発速度は上がったが、同時に仕事の質が下がるというトレードオフの実体験を軸に、AIコーディング時代における本質的な落とし穴を論じている。
「テストがパス」と「意図通り」は別の話だ
著者が経験した「ニアミス（near miss）」はこうだ。AIエージェントが新しいパーミッションセットを追加するコードを生成した。差分はきれい、命名も妥当、テストもグリーン。著者は6日間開いていたそのPRをスクロールしてうなずき、承認しようとした。
チームメートの一言が止めた。「このワイルドカード、意図的なもの？」
AIは「頼んだこと」を正確にやっていた。問題は、著者が曖昧にしか頼まなかったことだ。AIは空白を「最も許可範囲の広いオプション」で埋めた。テストは「パーミッションが存在するか」を確認しただけで、「それが安全か」は確認していなかった。
この経験から著者が得た教訓が記事全体の核心だ。
「テストがパスすること」と「自分が意図したことが実現されていること」は、別の話だ。
「4つ目のターミナル」という罠
3つのAIエージェントが並列で動いている。1つはリファクタリング、1つはテスト生成、もう1つは誰も手でやりたくなかったマイグレーションの途中だ。そしてふと思う。「4つ目を起動できるな」と。
著者はこの反射的な行動を「4つ目のターミナル」と呼び、AIコーディング時代における最大の失敗と位置づける。並列でエージェントを走らせること自体が悪いのではない。問題は、AIが生み出した「余剰の時間」を、立ち止まって考えるために使わず、さらに多くのAIで埋めようとする衝動にある。
著者自身、この過ちを約4ヶ月間続けた。
AIが速くした分だけ、迷子にもなれる
AIアシスタントの恩恵は本物だ。開発者がAIありで作業した場合、マージされたプルリクエスト数が約25%増加したという大規模フィールド実験の結果もある。1日かかっていた作業が昼前に終わる。四半期ずっと先送りにしていたマイグレーションが午後には完成した。
だが、速くなった分だけ問題も速く深みにはまる。
AIを多用するチームでは、プルリクエストのレビュー時間が約90%増加したというデータがある（1万人超の開発者のデータより）。レビューが慎重になったからではない。レビューに到達するコードの量が、レビューできる人間の処理能力を超えたからだ。
元記事によると、生産コードの大部分がAIと共同生成されるようになった一方、開発者の約75%がAIの出力を完全には信頼していないとも報告されている。著者はこのギャップを「検証負債（verification debt）」と呼ぶ。書く時間に節約した分が、後になって誰も理解していないコードの監査として戻ってくる。通常の技術的負債と違い、タスクボードには現れない。深夜2時に現れる。
ボトルネックは消えたのではなく、移動した
先述のニアミス（著者が「ニアミス」と呼ぶ修正前ギリギリの事例）は、一見すれば些細なコードレビューのエピソードだ。しかし著者はこれを、AIアシスト開発における構造的な問題の縮図と捉えている。
AIを使った作業では、ボトルネックが「書くこと」から「正しく頼むこと」と「検証すること」へと移動する。ニアミスのケースでは「ワイルドカードパーミッション禁止、アクションは明示的に列挙する」の一行を仕様に加えるだけで防げた。速度の問題ではなく、言語化の問題だ。
では、AIがコードを書いている間に何をすべきか
著者が「4つ目のターミナル」に代えて実践していることを4点挙げる。
1. ちゃんとドキュメントを読む クイックスタートではなく、エッジケースが書いてある部分を。読んだ内容が次のプロンプトの質を上げる。
2. コードが存在する前に仕様を書く チケットではなく、1ページの文書を。「何をすべきか」「何をしてはいけないか」「完了とはどういう状態か」「テストがグリーンでも人間がレビューする部分はどこか」を明記する。
3. 実際の人間と話す 「10分見てもらえる？」の一言でペアレビューをすることが、4つ目のターミナルより高いリターンを生む。AIを使った作業の失敗モードは「悪いコード」ではなく「検査されていないコード」だからだ。
4. 考えたことを書いて残す 意思決定とその理由を短くまとめて、チームが見える場所に置く。著者の場合、これが実際のアーキテクチャ変更につながった。
ジュニアエンジニアへの影響
これまでエンジニアが経験を積む仕組みは「悪いコードを書く→レビューで指摘される→少しマシなコードを書く→繰り返す」だった。AIは初日からそのミドルレベルのアウトプットを生成する。ジュニアは実際の理解の限界を超えて「生産的に見える」状態になれてしまう。そのギャップはプルリクエストには現れない。数ヶ月後、本番で何かが壊れて、その場の誰もシステムを説明できない状況として現れる。
7つのルール（抜粋）
記事では以下の実践ルールを提示している。
- 仕様を先に書く。 平易な言葉で書けないなら、まだAIに頼む準備ができていない。
- 説明できない差分はマージしない。 「自分が書いていない」ではなく「説明できない」ことが基準。
- セキュリティ・パーミッション・データ・金銭処理は必ず人間がレビューする。
- 小さいバッチで。 1エージェント、1タスク、1PR。
- 検証時間を見積もりに含める。
- AIに「なぜ」を聞く。 生成して受け入れるだけでなく、仕組みを問う使い方をした開発者のほうが、後でそのライブラリを理解していた、というパイロット研究がある。
- 週に1日はエージェントを使わない日を設ける。 AIの出力を評価する判断力は、使わないと錆びる。
コンパイラが登場したとき「プログラマーは不要になる」と言われた。DevOpsが登場したとき「DBAは消える」と言われた。実際に起きたのは、ハードルが下がり、より多くのソフトウェアが作られ、より難しいレイヤーを担える人材の需要が増えることだった。著者の結論はシンプルだ。「タイピング速度の価値は毎月下がっている。何を作るべきかを知ること、それを正確に言語化すること、できあがったものを証明することの価値は上がっている」。
詳細はAI Made Me 5x Faster. It Also Made Me 5x Worse at My Job.を参照していただきたい。
