AIでコードを書くのが当たり前になりつつある今、その便利さの裏で何が失われているのかを正面から書いた記事だった。著者は、AI/LLMを使うことで作業速度は上がっても、コードベースはむしろ脆くなると主張する。しかもこれは単なる抽象論ではなく、自分が大企業で働いていた経験と、実際に見かけた失敗をもとに話しているのが面白い。AI活用を称賛する記事は多いが、保守性や事故対応の観点からここまで強く疑う文章はそう多くない。
著者のEvan X. Merzは、5月にMetaを解雇された理由は推測しかできないとしつつ、同僚よりAI/LLMをコーディングツールとして受け入れる姿勢が弱かったことが一因ではないかと見ている。ただし、まったくAIを使っていなかったわけではない。Metaでの最後の数か月は、少なくとも自分のコードの90%はAIで生成していたと書いている。それでも、AIは作業量を10倍にしてはくれなかったし、せいぜい2倍にも届かなかったという。
一方で彼が気にしていたのは量ではなく品質だった。AIに頼る割合が高い同僚たちが書いたコードを見ると、ぱっと見は動いても、長期的には技術的負債になる細かな問題が多かったという。しかも、それは経験豊富な開発者でも見落とすことがあった。例として挙げているのが、mouse hoverの見た目をCSSの:hoverではなくJavaScriptのイベントで実装しようとしていたケースだ。こうしたやり方は、スケールしにくく、後から維持するのが面倒になりやすい。
その後、著者は別の大きなテック企業に移り、今では期待されている以上、コードを100% AIで生成するやり方に完全に切り替えたという。それでも、巨大なSaaSをこのやり方で作り続けるのは持続可能ではないと感じている。AIは、文脈窓の中に収まる問題はうまく解けるが、その外側にある長期的な問題には鈍感だ。そこで記事では、AIの利用が脆いコードベースを生む4つの経路を挙げている。
ひとつ目は、AIが浅いテストを書くことだ。AIはget/setのような単純な関数のテストを大量に作りがちで、人間にとって本当に重要な境界条件や利用シーンを十分に押さえない。e2eテストでも、すでにコードベースで想定されているケースばかりをなぞり、異なるタイプのユーザーや表面的でない操作は取りこぼしやすい。その結果、行カバレッジはそれなりに見えても、実際には大きな穴が残る。
二つ目は、AIが過剰に複雑なコードを書くことだ。必要なら1つで済む処理を、2つも3つもヘルパーメソッドに分けてしまう。DRYのようなコーディング原則を守ろうとするあまり、かえって人間には読みにくく、デバッグしづらい形になる。三つ目は、AI依存が進むほど人間の理解が薄れることだ。コードを人間が書かなくなると、データ構造やアルゴリズムを理解している開発者が減り、既存の構造と噛み合わない抽象化を見抜けなくなる。四つ目は、AIの生成速度が速すぎて、レビュー側が品質を保てなくなることだ。PRが次々に流れてくると、開発者は細部まで見切れず、命名ミスやテストの抜けといった小さな欠点が積み上がって、やがてスパゲッティコードになる。
後半では、脆いAIコードベースに見られる症状も挙げる。インシデントが増える、障害復旧に時間がかかる、実ユーザーにしか見えないエラーが増える、そして最終的にユーザー体験も悪化する、という流れだ。著者の結論は、製品が人間に向けたものである以上、人間の視点が必要だということだ。レストランで機械だけに注文するのが味気ないのと同じで、SaaSも人間の手触りを失えば価値が下がる。安さだけで競う製品ならAI主導でも成立するかもしれないが、高品質なソフトウェアは人間が面倒を見ることでしか守れない、というのが記事全体の主張だった。
この記事でいちばん刺さるのは、「AIがコードを書く」と「コードベースが健康である」は別問題だと、かなりはっきり切り分けている点だと思う。多くの議論は、AIが何行書けるか、どれだけ工数を削れるかに寄りがちだ。でも本当に重要なのは、誰がそのコードの責任を持ち、どの程度の理解を保てるかだろう。著者はそこを、速度の話に矮小化せずに書いている。
とくに納得感があったのは、AIが「文脈窓に入る問題」には強いが、「長期的な整合性」には弱いという指摘だ。これは単にAIの性能不足というより、ソフトウェア開発の性質そのものに関わる話だと思う。コードはその場で動けば終わりではない。あとから別の機能が重なり、別のチームが触り、障害対応が入り、設計思想が少しずつズレていく。人間の開発者は、そのズレを直感的に嫌がることがあるが、AIはそこに無頓着でも平気で進む。だからこそ、局所最適の積み重ねが全体を壊す。
ただし、この記事はAIそのものを全面否定しているわけではない。著者自身が90%や100% AI生成をしていると明かしているのが重要だ。つまり問題は「使うか使わないか」ではなく、どこまでをAIに任せ、どこを人間が握るかだ。私なら、この境界を曖昧にしたまま導入を進める組織ほど危ないと思う。AIで書くこと自体が悪いのではなく、レビューや設計の責任まで機械の速度に引きずられると、品質管理の歯止めが効かなくなる。
著者が挙げた「浅いテスト」の話も、今のAI開発の盲点をよく突いている。AIはテストをたくさん出すのが得意に見えるが、実際には「数があること」と「守るべきものが守られていること」は別だ。get/setのテストや、既知のパスだけをなぞるe2eテストは、安心感を与えるには十分でも、障害の予防には弱い。人間が見れば「このケースが抜けている」と気づくところを、AIはそれっぽい量で埋めてしまう。そこが厄介だと思う。
しかも、テストの不足は後から見えにくい。行カバレッジの数字があると、組織は「十分にテストしている」と思い込みやすい。だが著者の言う通り、実際に重要なのはカバー率の見た目ではなく、現実の利用パターンをどこまで押さえているかだ。ここでAIは、もっともらしいが浅いカバレッジを量産する可能性がある。レビューする側も、その数字に安心してしまう。結果として、失敗するのは本番になってからだ。
この問題は、単にAIのテスト生成精度を上げれば解決する話ではないと思う。むしろ必要なのは、テストを書く目的を人間側が再確認することだ。何を守りたいのか、どの失敗を先に潰すべきか、どのユーザー体験を壊してはいけないのか。AIはその問いを立ててはくれない。だから、テストが増えるほど、設計者やレビュアーの意図が薄まるなら本末転倒だ。速度の代償として、品質の定義まで外注してはいけない。
もうひとつ気になったのは、著者が「AIが作るコードは人間向けではなく、AI向けだ」と言い切っている点だ。かなり強い表現だが、言いたいことは分かる。AIは文法的には整ったコードを出せても、チーム内での読みやすさや、将来の保守のしやすさまでは自然に最適化してくれない。むしろ、抽象化を増やしすぎたり、命名を無難にしすぎたりして、文脈を知らない人間にはかえって追いづらい形になることがある。著者のいう「脆さ」は、バグの数だけではなく、理解コストの増加も含んでいるのだろう。
ここには、AI導入の責任が個人ではなく組織にあるという視点も見える。個々のエンジニアがAIを上手く使えるかどうかより、組織として「どこまでなら理解を失わずに回せるか」を決められているかのほうが大事だと思う。AIが速いのは事実だが、速さに引きずられてレビューを省けば、最後に残るのは誰も全体像を説明できないコードベースだ。そうなると、障害対応も改修も遅くなる。著者が警戒しているのは、まさにそこだろう。
私はこの記事を、AI開発への反対論というより、「便利さに慣れたあとで何を失うか」を先回りして書いた文章として読んだ。今後、AIを使う現場は増えるはずだし、それ自体は止められない。ただ、そのときに必要なのは、生成量を誇ることではなく、理解の密度をどう保つかを考えることだと思う。人間が読むこと、直すこと、責任を持つことを手放した瞬間に、コードは静かに壊れていく。
