そのパターンが繰り返される理由は何か？市場がそれを促進しているからだ。企業は株主価値が多くの人に信じられることに依存しているから、AIを全能で無敵な仕事の殺し屋として押し出している。実際にツールが機能するかどうかは関係ない。ジェンセン・ファンのような人が、AIに対する人々のネガティブな反応が進展の最大の障害の一つだと言っているのは興味深い。まるで彼らが批判から免れるべきだと言っているかのようだ。彼らは実際に製品を宣伝通りに機能させるために努力するよりも、反対意見を貶めようとする。市場がこの現実に目覚めたら、本当に厄介なことになるだろう。

逆に、開発者の夢は、ITに関係ない人たちを置き換えることだ。通常は100%オンラインの自動化された自己宣伝型SaaSでね。AIもその最新の形だ。

開発者を置き換えるというより、開発者がより複雑な問題に取り組めるように、抽象度を上げることが大事なんだ。最初の電子コンピュータは、回路を手動で配線し直してプログラムされていた。それからパンチカードで機械命令をエンコードできるようになったからといって、開発者が置き換えられたわけじゃない。生の機械命令からアセンブリコードに移行したときも同じだし、手書きのアセンブリからCやFORTRANのようなコンパイルされた低レベル言語に移行したときもそうだ。低レベル言語からJava、C++、Pythonのような高レベル言語に移行したときも、機能を実装するためにライブラリやフレームワークに頼るようになったときも、開発者は低レベルの問題を心配する必要がなくなり、高レベルの問題に集中できるようになった。メルの知性は、メモリドラムの位置を最適化する必要がなくなったから、彼が解決しようとしている問題の高レベルの論理やアルゴリズムを最適化することに集中できる。結果として、ソフトウェアはより複雑になったけど、同時により能力が高まり、一般的になった。（生成AIがこれまでの抽象度の増加の例と異なるのは、それらが決定論的で、しばしば正式に検証可能な高い抽象から低い抽象へのマッピングであるのに対し、生成AIはそうではない。）

中堅管理職やC-suiteの人たちから聞いた話だと、スタッフが最大のコストで、技術部門が最大のコストセンターだって。私はそれに反対だ。製品がなければ営業は成り立たないから。でも、それはどうでもいいポイントだ。だからこそ、同じ中堅管理職やC-suiteの人たちがAIに夢中になって、すべてのプレスリリースで言及しているんだ。実際には、コストが米国のチームをオフショアのチームに置き換えることで削減されている。そして、レイオフはAI導入の結果として捉えられている。ソフトウェア開発のためのAIツールはこれからも存在し続け、今後数ヶ月や数年で加速するだろう。進展もあるだろうけど、コスト削減は主にオンショア/オフショアの置き換えによって実現されている。残ったオンショアのチームは、もっと多くの余裕や修正を吸収し、結果的により生産的になる。

科学は、その習得には多くの努力が必要だから嫌われている。そして同じ理由で、その実践者である科学者たちも、その力から嫌われている。 - ダイクストラ '1989

この議論で見落とされがちなパターンは、「ノーコードが開発者を置き換える」波が実際には開発者の仕事を減らすどころか、増やすということ。COBOLはマネージャーがプログラムを書くためのものだったし、VBはビジネスユーザーがアプリを作れるようにした。Squarespaceはウェブ開発者の必要性を減らしたし、今はAIがある。実際に起こることは、ツールが参入障壁を下げることで、もっと多くの人が何かを作ろうとするようになり、その人たちがツールの限界にぶつかったときに、実際の開発者が必要になるってこと。つまり、「作る必要があるもの」の全体的な範囲はどんどん広がっていく。置き換えられるのは、すでに明確に定義された機械的な作業をしている開発者たち。でも、最初に何を作るべきかを理解する仕事や、自動化されたものが期待通りに動かない理由をデバッグする仕事はまだ残ってる。むしろ、その仕事は増えてる。

このパターンをシステム管理の分野で20年間見てきた。いつも同じセールストーク：高い抽象化が専門的な仕事を民主化するって。SREは「根本的に異なる」って言われてるし、Kubernetesは「複雑さを抽象化する」って。でも実際には、高いコストでの再発明を見てる。開発者たちは、ファイルシステムのセマンティクスを理解せずにポッドの再起動後にデータベースの破損をデバッグしてる。彼らはCNIの上にモニタリング戦略やネットワーキングパターンを再構築してるけど、これらの抽象化が基づいている基本を学んでないから。彼らは早く学んでるわけじゃなくて、同じ運用の教訓を何倍ものコストで再学習してる。各「民主化」の波は専門家を排除するわけじゃなくて、新しい専門家を生み出して、彼らはその抽象化とそれが何を抽象化しているのかを学ばなきゃいけない。専門知識を得るのがもっと高くつくようになっただけで、不要になったわけじゃない。Excelがその例を証明してる。客観的に見てひどいもので、30%のゲノム論文にはオートコレクトによる遺伝子名のエラーが含まれてるし、JPモルガンは数十億ドルを数式エラーで失ったし、イギリスの公衆衛生はCOVIDのケースを16,000件もロウ制限で失った。それでも、適切なシステムが許容しないような壊滅的な失敗を受け入れることで民主化に成功した。このパターンは繰り返される。私たちはExcelのアクセスの良さをエンジニアリングの信頼性と両立させたいから。両方は無理だよ。民主化のために災害を受け入れるか、専門知識が必要だと認めるかのどちらか。

半技術者が開発者を置き換えられるのは、彼らが開発者を避ける代わりに、システム全体の複雑さを最小限に抑えることを約束するならば？もちろん、半技術者はトラブルシューティングができる。それはほとんどの仕事の一部だからね。（中には得意な人もいるけど。）でも、トラブルシューティングを促進するシステムを設計できる半技術者はどれくらいいる？私のエンジニアの知り合いの中でも、できない人がたくさんいるよ。

会計士向けのツールを作っていて気づいたパターン: 自動化は仕事を奪うことは少ない、仕事の内容が変わるだけ。私が関わっている簿記の人たちは、以前は手動でデータ入力に何時間もかけてたけど、今はその時間をクライアントへのアドバイザリー業務に使ってる。全体の作業量は変わらないけど、より価値の高いタスクにシフトしてる。80年代のスプレッドシートでも同じことが起こった。会計士が消えたわけじゃなくて、新しい仕事のカテゴリーが生まれて、1人が扱える仕事の期待値が上がった。面白いのは、開発者が置き換えられるかどうかじゃなくて、新しいツールを使った開発者の役割が給料が下がるかどうかだよ。初期の兆候では、そうなるかもしれない。もしLLMがコーディング部分を商品化したら、プレミアムは問題理解やシステム思考に移るんじゃないかな。

雇用主がもっと選り好みして、トレーニングに投資してたら、たくさんの開発者を入れ替えられたのにね。今は、ほとんど役に立たない開発者がたくさんいる。記事に出てたウェブフレームワークがその例だよ。これらのフレームワークは、開発者や雇用主の生産性を上げるためにあるんじゃなくて、トレーニングを軽減して、雇用主が選べる候補者の幅を広げるために存在してるんだ。