AI がコードを書くのはもう珍しくありません。けれど、その変化を見て「人間の仕事は終わった」と受け取るのは早すぎる、というのが今回の話です。Simon Späti は、問題は AI が出すコードそのものではなく、チームから「なぜそうなっているのか」という理解が抜け落ちていくことだと書いています。速さだけを追う現場ほど、その空洞化は深刻になる。この記事は、AI コーディングの賛否というより、ソフトウェアを誰が理解し、誰が保守するのかを問う内容です。
元記事は、まず「コードを書くことはもう死んだのか」という問いに触れつつ、論点はそこではないと切り出します。著者の見方では、問題は AI がコードを書けることではなく、システム全体や設計の意図を誰も分かっていない状態が広がることです。ある議論のコメントでは、AI は平均的なコードを書ける、そして元のコードベースが平均以下なら、AI はそれを平均程度まで引き上げられるかもしれない、と述べています。ただし著者自身は、そこで終わらないと言います。みんなが Claude に聞くだけになり、計画がなくなっていくからです。
記事の中盤では、急成長するスタートアップや、大企業でも中間管理職が AI 導入を強く押す現場の空気を、ある投稿を引用しながら描きます。その投稿では、新しい職場に入って半月ほどで、仕様書、コード、テスト、PRD、チケット、その解決結果、レポートまで、あらゆるものが Claude Code で作られていると嘆かれています。チームの誰もそれを好んでおらず、上からは「コードを push するのはボトルネックではないのだから、なぜ遅いのか」と急かされる。人々は enter を押すために12時間から13時間働き、誰も読まず、誰も自分で考えない。L1 から L7 まで全員が Claude に相談し、達成感もなく、バグを直すこともなく、ただ LLM に任せているというわけです。投稿者は、せめてコードを見て流れを確認する時間があればまだましだが、実際には「とにかく ship する」ことだけが目的だと書いています。
著者は次に、Data Engineering は少し違うのではないか、という見方にも触れます。データ系の人は、最初から製品やビジネスをかなり深く知る必要があったので、AI はむしろ摩擦を減らすだけだという意見です。これに対して著者は、AI 登場前に育ったデータ人材は、実際に多くを知るか、ドメインの専門家を巻き込まないと仕事にならなかったはずだと認めつつ、いま新しい領域に入る人は AI に頼ってしまうぶん、知識が抜け落ちる危険があると見ています。さらに、プロダクトマネージャーについても話を広げます。コードが書けない PM でも、欲しいものを言語化し、チームを動かしてソフトウェアを作らせるのは昔から難しかった。今なら「欲しいものが分かる人」は何でも作れてしまうかもしれないが、基礎を知らないままでは土台の悪いプロダクトになりやすい、と釘を刺しています。
最後に著者が強調するのは、保守こそが最終ボスだという点です。AI で簡単に pipeline や app、BI dashboard を作れるほど、後から面倒を見るものも増える。しかも誰も中身を知らなければ、その維持は一気に難しくなる。AI は自分で自分を指示できないのだから、人間が intent、taste、design、architecture を握っていなければいけない。そこが失われると危ない、というのが著者の結論です。彼は、これは採用の問題でもあり、もし junior をもっと雇っていたら状況は違ったかもしれないとも書いています。
この記事で一番刺さるのは、「AI がコードを書くこと」そのものより、「説明できる人がいなくなること」のほうが怖い、という視点です。実際、現場ではコード生成が便利になるほど、レビューや設計確認が省かれやすい。ここは単なる気分の問題ではなく、責任の所在が曖昧になる問題でもあります。誰がその設計を選んだのか、なぜそのデータ構造なのか、失敗したらどこを見るのか。そうした問いに答えられないチームは、速度が出ても運用で詰まるはずです。著者の不安は、かなり現実的だと思います。
一方で、この記事は少し「AI が知識を奪う」側に寄りすぎてもいる気がします。私は、AI のせいで知識が消えるというより、もともと薄かった知識が可視化されただけではないかとも感じます。以前から、仕様を理解していないまま手を動かす人や、上流の意図を確認しないまま作るチームはありました。AI はそれを加速させたが、原因そのものではない、という見方です。つまり問題の本体は、AI 導入ではなく、理解より納期を優先する組織文化のほうにあるのではないでしょうか。
ただ、AI があることで「知っているふり」が以前より通りやすくなったのは確かです。昔なら、分からない人は分からないままでも、少なくともレビューや相談の段階で露見しました。今は Claude や ChatGPT がそれらしいものを返してくれるので、空白が埋まったように見えてしまう。ここが厄介です。言い換えると、AI は無知を隠すのが上手い。しかも速い。だからこそ、設計レビューやテスト、運用ログの読み解きのような「人間が立ち戻る場所」を残さないと、チームはあっという間に自分たちの作ったものを理解できなくなると思います。
Data Engineering の話も面白いところです。著者は、データ系はもともとビジネスを知る必要があったので AI の恩恵を受けやすい、としながら、その知識が若手や新規参入者には伝わりにくくなると見ています。これはかなり重要です。AI は経験者の摩擦を減らす一方で、初心者にとっては学習の足場を省いてしまう。以前なら「なぜこの指標を見るのか」「なぜこの join が危ないのか」を身体で覚える機会がありましたが、今は答えだけが先に出る。そうすると、作業はできても判断が育たない。著者の懸念は、単なる懐古ではなく、育成の問題として読むべきだと思います。
PM についてのくだりも、実はかなり鋭いです。コードが書けない人でも、何を作りたいかを定義する力は重要です。ただし、AI があるからといって「定義だけできれば何でも作れる」と考えるのは危うい。プロダクトは見た目だけ整っても、データの流れや失敗時の挙動が雑だとすぐ壊れます。だから今後は、コードを書く能力そのものより、何を捨てて何を残すかを判断する力が価値になるのだと思います。AI で作れる世界では、作ることより選ぶことのほうが重い。この記事は、その重心の移動をかなりはっきり言語化しています。
保守が最終ボスだ、という一文も印象に残りました。これはソフトウェア業界では昔から言われてきたことですが、AI 時代に入ると重みが変わります。作るコストが下がるほど、壊れたときの総量は増えるからです。しかも「誰も分からない」状態で増える。派手なデモや短期の成果が評価されやすい環境ほど、あとからの修復費用は見えにくい。だから本当に必要なのは、AI を止めることではなく、知っている人が設計に居続けること、若手を育てること、そして読めるコードを残すことだと思います。便利さに流されるほど、その地味さが効いてくるはずです。
参考: The Problem is not the AI Code, but Nobody Knows Anything Anymore
