AIはエンジニアの仕事を奪ったのではなく、やったふりをするのを簡単にしただけだ
著者は、問題は人々がAIを使うことではなく、「動くものを手に入れた」ことがいつの間にか「なぜ動くのかを理解している」と見なされていることだと言う。彼は読書会アプリを作り直した経験と、2台目のモニターにしか現れない通知バグについて語り、その線引きをレビュー、デバッグ、そして自分が何を作ったのかを本当に知るという段階に置いている。
日本語
コピー
AIはエンジニアの仕事を奪っていない。ただ、やったふりをするのを楽にしただけだ
9月15日はインドの技術者デーで、スリランカとタンザニアも同じ日に祝う。M. Visvesvaraya 卿の誕生日だ。彼は Krishna Raja Sagara ダムを含む複数の大規模灌漑・水資源管理プロジェクトを指揮し、自動放流ゲートシステムを発明して Khadakvasla 貯水池に最初に設置した。自分を創業者と呼んだことは一度もない。彼は、実際に水をせき止められるものを作るのに忙しかった。
彼を持ち出したのは、AI コーディングツールと「公開ビルド」の時代のあいだのどこかで、多くの人が「何がエンジニアリングか」の基準を静かに下げてしまい、それがそろそろ表に出てきたからだ。
新しい錯覚
このパターンは見たことがあるだろう。誰かが AI ツールにプロンプトを投げ、動くランディングページを受け取り、無料枠のホストにデプロイし、その日の夜には「創業者」を名乗っている。アーキテクチャの判断は一度もしていない。無料枠のレート制限にぶつかったら何が起きるかも知らない。モデルが実際に何を書いたかも読んでいない。あるのは URL 一本と、「公開ビルド」の投稿だけだ。
問題は、彼らが AI を使ったことではない。
問題は、動くものを手にしていることが、なぜ動くのかを理解していることの同義語に、いつのまにかすり替わったことだ。
自動販売機にジュースを頼んでおいて、バーテンダーを名乗るようなものだ。
怖いのは、AI が数分で動くアプリを生成できることではない。そこは本当に素晴らしい。怖いのは、多くの人の頭の中で「何かを生成する」と「何かを理解する」が静かに交換可能になってしまったことだ。素早く出すのは構わない。ただ、それをエンジニアにしてくれる部分と混同しないでほしい。
違いは実際どんな形をしているか
今年の初め、私はこれについて身をもって学んだ。
作り直し
ShelfTalk はもともと大学の課題だった。MERN の読書会アプリ一式を、1学期かけて一人で作り、単位が取れる最低限の出来で提出し、そのまま GitHub で数か月放置した。GitHub の Finish-Up-A-Thon（AI 支援の作業を途中で投げ出さず、きちんと終わらせることに焦点を当てたチャレンジ）が締め切りを与えてくれたので、私は戻ってそれをプロダクション品質に作り直した。REST ポーリングを本物の Socket.io チャットに置き換え、リアルタイム同期の読書室を作り、MongoDB Atlas と GridFS に移行し、Create React App から Vite に移って HMR 時間を約80%削った。
500以上の応募の中でトップ10に入った。
ShelfTalk：本は語らない、私たちが語る（復活した大学のプロジェクト）
すべてを説明してくれたバグ
これらから学んだことより、数週間後に本番環境で出たあるバグのほうが多くを教えてくれた。
私は我ながら賢いと思った通知の最適化を入れていた。タブが表示されているならデスクトップ通知を出さない。もう見ているメッセージの通知ほど嫌なものはないからだ。UX としてクリーンだと思っていた。ところがユーザーがダイレクトメッセージを見落とし始め、自分のテストでは再現できなかった。コードは私が設計したとおりに動いていた。
このバグは、コードの一行ではなく、ある仮定の中に住んでいた。
私のコードは「OS がこのピクセルを描画できる」と「人間がそれを見ている」を静かに同一視していた。ShelfTalk をセカンドモニターで開いている人は、すべての通知を黙って取りこぼしていた。全画面で表示されているタブは、20分誰も見ていなくても、技術的には「表示中」だからだ。修正は、私が誇りに思っていたその最適化を消すことだった。余計な通知が一度出るのは少しうるさいだけだが、黙って消えたメッセージは壊れたプロダクトだ。
出来すぎた最適化：なぜ私たちのプッシュ通知は、あなたが見ていないときだけ効いていたのか
このバグはデモでは絶対に出ないし、プロンプトを打ち続けてプロジェクトを終わらせるやり方では見つけられない。見つけるには、ユーザーが文句を言って、私が「設計どおりに動いている」という言葉と十分長く向き合い、この設計の核となる仮定そのものが間違っていると気づく必要があった。
ShelfTalk の作り直しのかなりの部分は Copilot と一緒に書いた。socket イベントハンドラの骨組みを作り、Vite への移行中に import エラーを拾い、私が調べることになった UI の書き方を補完してくれた。それでも私はそのどれも「vibe coding」とは呼ばない。私が批判している vibe coding は、自分のプロジェクトが壊れたと気づき、プレッシャーの中で直す、あの区間を飛ばすからだ。
その区間、つまりレビューし、デバッグし、自分が何を作ったかを本当に知ることは、この仕事のすべてだ。しかも一人で、自分が見落としたものを誰も補ってくれない状態で。コンクリートと鋼鉄を扱っていた Visvesvaraya にとってもそうだった。今、Copilot が文字の一部を打っていても同じだし、セカンドモニター上の馬鹿げたブール値にとってもまったく同じだ。
では、線はどこにある？
AI が問題だとは思わない。問題は、エンジニアにしてくれる部分を飛ばしながら、エンジニアのように聞こえさせる部分だけを残すのが、あまりに簡単になったことだ。
AI はエンジニアの仕事を奪っていない。ただ、やったふりをするのを楽にしただけだ。
だから率直に聞く。AI で何かを作ることと、AI が代わりに作るのをただ眺めること、あなたはどこで線を引く？
自分が間違った側に立っているのに気づいたことはある？ 👇