James Shore のこの記事は、かなりストレートです。
要するに、
AI coding agent を使うなら、コードを書く速度を上げるだけでなく、保守コストを下げないといけない
という主張です。
ここでいう保守コストとは、ざっくり言えば
みたいな、「書いた後に払うコスト」のことです。
この視点、すごく大事だと思います。
AI開発の話はどうしても「何倍速くなった！」に目が行きがちですが、現実のソフトウェア開発って、書くより守るほうが長い。ここを無視すると、後でじわじわ苦しくなるわけです。
記事では、1か月分コードを書いたら、その後の1年、さらに翌年以降もずっと維持費がかかる、と考えます。
この考え方はかなり現実的です。
ソフトウェアって、家電みたいに買ったら終わりではなくて、むしろ「作ってからが本番」なんですよね。
たとえば、コードを書いた後にはこんなことが起きます。
つまり、新しいコードは未来の負債も一緒に連れてくる。
これ、地味だけど本当に重いです。
記事の面白いところは、AI coding agent を使って開発速度が上がっても、保守コストが変わらないか増えるなら、長期的には逆効果だとかなり強く言っている点です。
たとえば、AIでコードを2倍速く書けるようになったとします。
でも、その結果としてコードが読みにくくなったり、レビューが雑になったりして、保守コストも2倍になったらどうなるか。
答えは単純で、得した気分は一瞬だけです。
最初は「うお、速い！」となる。
でも数か月後には、
という流れになりやすい。
個人的には、ここがこの記事のいちばん痛いところだと思いました。
AIで爆速に見えても、そのぶん未来の自分やチームに請求書が回ってくるなら、あまり幸せではないですからね。
記事では、かなりざっくりしたモデルを使って説明しています。
ここで重要なのは、数字の正確さそのものではなく、方向性です。
著者も「この数字が厳密に正しいかどうか」より、
“ソフトウェアは時間とともに保守負債を抱える”という大枠が重要だと言っています。
これはかなり同意できます。
実務では、精密な理論よりも「だいたいこうなる」が当たっているほうが怖いんです。しかもソフトウェアは、その「だいたい」が高確率で当たる分野でもあります。
記事の核心はここです。
AIでコードを書くと、短期的には速くなる。
でも、そのコードが将来の保守コストを増やすなら、その負担は残り続ける。
しかも、AI利用をやめたあとも、
増えたコードは消えないんですよね。
ここがかなりイヤらしい。
「もうAIやめよう」と思っても、過去にAIで雑に増やしたコードはそのまま残る。すると、その後の開発は、AIを使っていなかった場合よりも苦しくなるかもしれない。
これはたしかに「永久ローン」っぽいです。
速度だけ借りて、返済は未来に押しつける感じ。
著者が “permanent indenture” と言っているのも、言い得て妙だと思います。
ここは誤解しないほうがいいポイントです。
この記事は「AIは悪だ」と叫ぶ反AI記事ではありません。
むしろ著者は、AIを使うこと自体は否定していないように読めます。
ただし条件がある。
それは、コードを増やす速度に見合うだけ、保守コストを下げることです。
つまり、
という発想です。
これ、かなり厳しい条件です。
でも逆に言えば、これを満たせないなら、AI導入の見せかけの勝利に酔っているだけかもしれない。そこをちゃんと疑え、という話なんでしょう。
著者は、少なくとも自分の見聞きした範囲では、coding agents が保守コストを大きく下げているとは見えない、と述べています。
むしろ、保守コストを上げているケースのほうが多いという見方です。
これはかなり耳が痛い人も多そうです。
AIが出したコードって、一見きれいでも、
みたいなこと、ありますよね。
もちろんAIが悪いというより、人間側がレビューをサボると一気に崩れるという面もあります。
私も、AIを使えば使うほど「読む力」「削る力」「直す力」がむしろ重要になると思います。速さだけ見ていると、あとで痛い目を見そうです。
この記事を読むと、AI導入の評価軸を変える必要があると感じます。
「何倍速くなったか」だけでなく、
「そのコードは半年後も安く直せるか？」を見ないといけない。
完全な数値化は難しくても、
みたいな指標を、ちゃんと見るべきだと思います。
記事の最後でも触れられているように、
AIは「コード生成」だけでなく、保守作業を効率化する方向でも使えます。
たとえば、
などですね。
こっちのほうが、長期的にはよほど価値が高いかもしれません。
個人的には、この記事はAI開発をめぐる議論の中でもかなり本質的だと思いました。
なぜなら、みんな「生成の速さ」には注目するのに、「生成したものを持ち続けるコスト」を軽視しがちだからです。
でもソフトウェア開発って、結局のところ
**“作る能力”より“壊さずに変え続ける能力”**のほうが効いてくる場面が多いんですよね。
AIはそのバランスを崩す危険がある。
だからこそ、導入するなら「速くなるか」だけでなく、
「未来の自分がちゃんと面倒を見られるか」まで考えないといけない。
この視点を持っているかどうかで、AI活用の成否はかなり変わるはずです。
この記事のメッセージを一言でいうと、
AIでコードを書くなら、保守コストを減らせ。速さだけでは足りない、です。
派手なデモや「2倍速！」の数字は魅力的ですが、ソフトウェアは長距離走です。
短距離のスプリントで勝っても、後半で脚が止まったら意味がない。
著者はそこをかなり強く警告しています。
AIは便利です。これは間違いない。
でも、便利さの裏で保守が苦しくなるなら、その成功はかなり危うい。
私はこの警告、かなり真っ当だと思いました。
