今、AIに「集団幻覚」を起こしている企業が多すぎる件

現在、多くの企業がAIの可能性に過度に入れ込み、冷静な判断力を失っているのではないかという指摘が話題になっています。mitchellh氏の投稿によると、AIが何でも解決してくれるという幻想に支配され、技術的・経営的な意思決定が歪められている現状があるようです。詳細はこちらのリンクをご覧ください。

・Twitterでの議論: https://xcancel.com/mitchellh/status/2055380239711457578
・Hachydermでの投稿: https://hachyderm.io/@mitchellh/116580433508108130

俺が働いているかなり大きな会社は、モダナイゼーションや新しい技術の導入が常に極端に遅いんだけど、奇妙なことに、今となってはそれが競争上の優位性になるかもしれないな。

この投稿は、こういう人たちがいかに議論にならないかを指摘しているよね。「AIエージェントがすぐに修正してくれるし、人間には不可能な規模で対応できるから、バグをリリースしても大丈夫」なんて平気で言うんだから。

それに対するトップの返信が、まさにその「でもエージェントはこんなに速いんだぜ！」っていう典型的な議論で笑える。

バグ報告が減るのは、報告しても修正されないと人々が思い始めた時だ。バグ報告ってそれなりに時間がかかる作業だからね。グループや企業への信頼が崩壊していく中で、そういう光景はよく目にするよ。

もしそう感じるなら、俺が作った新しいCLIツール「Burn, Baby, Burn (those tokens)」(https://github.com/dtnewman/burn-baby-burn/tree/main) を気に入ってくれるかも。

Show HNの投稿はこちら: https://news.ycombinator.com/item?id=48151287

彼が言っているのは、AIそのものの是非というより、企業や個人が意思決定や思考をAIに丸投げしている現状についてだと思う。

AIを使ってコードを書くこと自体はAIサイコシスでも何でもないし、悪いことだとは思わない。でも、AIにプロンプトを投げて、その回答をそのまま鵜呑みにするなら、それはAIサイコシスだ。金融関係者やTwitterのVCでよく見る光景だよ。彼らは自分自身で少しも考えずに、ChatGPTのスクリーンショットを自分の考えや推論として投稿しているんだから。

アイディアや思考、アドバイスに関しては、こういうツールはゴミ同然だ。単なるパターンマッチングの機械だから、見たままのパターンを返すだけ。少しでも議論すれば多くの人が気づくはずだよ。たいていの場合、最高に凡庸なゴミみたいな回答しか返ってこないからね。

とはいえ、コードを書くといったパターンマッチングが実際に役立つタスクにおいてはかなり有用だ。ただ、繰り返すけど、思考や意思決定までAIに任せちゃダメだよ。

AIサイコシスは、AI利用に対する反対意見ってわけじゃないんだよ。

俺も毎日AIコーディングツールを使っているけど、AIには「未来」という概念がない。

「もし本番環境でこれが壊れたら直せないぞ。夜中の3時に呼び出されるのは自分だ」というエンジニア特有の利己的な考えこそが、これまで堅牢なシステムを築く頼みの綱だったわけだ。

CPANで完璧なライブラリを探して、自分で実装する手間を省こうという怠惰さ（実際には探す時間の方が、自分で書くより長くなることがよくある）。

AIツールを使って数千行のコードを書き、それが本番環境に入ったことも何度もある。2017年頃から、自分ですべてタイピングするんじゃなくてコードを書くように指示を出したり、テストでバグを捕まえる罠を仕掛けたりしてきたから、使い勝手は自然に感じている。

ただ一つ、AIには「コードを減らす」ということができない[1]んだよね。

[1] - https://xcancel.com/t3rmin4t0r/status/2019277780517781522/

AIレスキューのコンサルティングは、セキュリティ侵害やデータ復旧の専門家のように、高価値なコンサルティングの重要な形態になっていくと思う。

AIのみで書かれたシステムは、人間には理解不能な複雑さへとスケールするだろう。バグの修正完了率は徐々に低下し、修正1件あたりのトークン消費量は増大する。最終的には、AIによる修正が、修正した数以上のバグを生み出し、システム全体が不安定になるはずだ。壊滅的な崩壊を避けるための設計原則を抽出して、クリーンルームでメスを整理し、ゼロから（たぶんまたAIを使って）再構築するという特殊なプロセスが必要になるだろうね。

将来的に、ソフトウェアエンジニアリングは、最初からこうした事態を避けるための原則が中心になるはずだ。ただ、本来のソフトウェア工学が安定した設計原則に到達するまで長年かかった（そして今でも議論されている！）のと同様、20年はかかるんじゃないかな。

自分の状況がすごく奇妙に感じるんだ。コードを書くという体験や実践がAIのせいで台無しになることへの嫌悪感は半端なくて、コンピュータを使う以外の仕事なら何でもいいとすら思う一方で、ツール自体は非常に強力で進化し続けていることも認めている。

Mitchellの指摘はもっともだと思う。こうしたツールは、後になって構造全体が崩壊した時にしか気づけないような腐った基盤を作り出しかねない。そうなった時に、昔のようにコードベースへの深い理解を持たず、責任を取らされるような立場にはなりたくないな。

でも、人間だって昔からコードに微細で壊滅的なバグを紛れ込ませてきたわけだし……。今の状況の多くは、実証的な疑問として残るね。以前にはあり得なかったような恐ろしい崩壊の仕方をするシステムが続出するだろうか？ひょっとしたらあるかもしれない。でも、私たちは仕様策定や検証にもっとシフトする必要があると学ぶだけかもしれない。正直わからない。ただ、多少の混乱はあるにせよ、こういうシステム構築のスタイルは避けられない運命のように思える。

AIアンチ勢の中にも、一種の反動的なサイコシスがあるように感じるよ。AIとは関わりたくないが、使った経験自体を否定することもできない。こういう現実的かつネガティブなAI議論ができる場がもっとあればいいんだけど。Mitchellが優れたデベロッパーなのはまさにその点だね。

もしかすると、これこそがソフトウェアエンジニアリングを「工学」という分野に変えるきっかけになるのかもしれない。

今、プロンプターたちが会社のインフラ全体を構築している。知り合いに一人いるんだけど、彼は会社のデータベースを新しいPostgresのバージョンに移行させた。最終的には成功したけど、そのプロセスを説明するのを聞いている間、歯ぎしりしたくなるほどだったよ。

話を聞くと、「で、タバコを吸いながらサーバーにガソリンを撒いたんだ。でも心配ない、地下室に消火器を見つけたからさ。ゲージは空だけど、振るとまだ液体が入っている音が聞こえるから……」みたいな感じだったんだ。

彼が会社を辞めたら、DBインフラを維持するために、さらに自信満々なプロンプターが必要になるだろうね。

これはRich Hickeyの「Simple Made Easy」と、Clojureを作る彼のアプローチを思い出すな。

LLMがプログラム全体を生成するようになる前でさえ、複雑なフレームワークのおかげで開発者は初期バージョンのプログラムを非常に素早く書けていた。でもその代償として、コードが理解しにくくなり、デバッグや修正が困難になっていたんだ。

中には、AIがどれほど複雑で難解なコードを生成しようとも、AIならそれをデバッグし、維持し、修正するのに十分な賢さを持ち続けるだろうと期待している人たちもいる。俺はそこまで確信が持てないけどね。