今、多くの企業がAI集団的狂気に陥っていると信じている
(twitter.com/mitchellh)- ミッチェル・ハシモト: "今、多くの企業が深刻なAI集団的狂気に陥っており、彼らと理性的な会話をすることは不可能だ"
- クラウドインフラ自動化時代の MTBF vs MTTR論争 がいまやソフトウェア開発業界全体へと拡大しており、AIエージェントへの盲信が新たな形の集団的狂気を生み出している
- "エージェントが素早くバグを修正するのだから バグを出荷しても構わない" というMTTR万能主義が横行しており、これはインフラ時代にすでに失敗が証明された考え方
- システムは 局所的な指標では健全に見えながらも、全体としては理解不能な状態へと変質しうる。バグレポートの減少やテストカバレッジの増加は、実際の安全性を保証しない
- この問題を直接提起すると、"テストカバレッジは100%だ"、"バグレポートは減っている" といった 即座の反論 で会話が遮断され、全体像が見えていない
- 変化の速度があまりに速く、誰も 基盤アーキテクチャの腐食 を認識しないまま、自動化された "回復力のある災厄マシン" を作り続けている
核心的主張: AI集団的狂気(AI Psychosis)
- 現在、多くの企業が深刻な AI集団的狂気 の状態にあり、彼らと理性的な会話を交わすこと自体が不可能
- 具体的な人物名を挙げられないのは、個人的に深く尊敬している友人たちが含まれているため
- この状況が今後どう展開するのかについて、深い懸念を示している
インフラ時代の教訓: MTBF vs MTTR
- クラウド移行およびクラウド自動化の時期に経験した MTBF(平均故障間隔) vs MTTR(平均復旧時間) 論争が再浮上
- 当時はインフラ領域に限られていたが、今では ソフトウェア開発業界全体（さらには世界全体）へと拡大
- AI盲信論者たちは、ほとんど絶対的な "MTTRで十分だ" という思考様式で動いている
- "エージェントが人間には不可能な速度と規模でバグを修正するのだから、バグを出荷しても構わない" という論理
- インフラ時代に学んだ教訓: MTTRは優れているが、回復力のあるシステムそのものを完全に捨て去ることはできない
対話の遮断と反論パターン
- この問題を個人的に知る人々に提起すると、即座の無視 につながる
- "いや、テストカバレッジは完璧だ" または "バグレポートは減っている" といった反応
- こうした反論は 全体像を示していない
- 直接個人的に懸念を伝えたが聞き入れられず、より広い範囲で共有することが重要だと判断
自動化された災厄マシン
- インフラですでに一度学んだ教訓: 自動化によって「非常に回復力のある災厄マシン」を作ることができる
- システムが 局所的な指標では健全に見えながら、全体としては理解不能になる現象が起きる
- バグレポートは減るが、潜在的リスクは爆発的に増大
- テストカバレッジは上がるが、意味論的理解は低下
- 変化があまりに速く進むため、誰も 基盤アーキテクチャの腐食 を認識できない
主な返信での論点
- @adamhjk: "純粋なバイブコーディングが最初に破壊するのは アーキテクチャそのもの" であり、そもそもアーキテクチャがなければ腐食を検知できない
- ミッチェル・ハシモトの補足説明: インフラではオンラインシステムを更新して合理的な時間内にすべてのユーザーへMTTRを適用できるが、ライブラリ・デスクトップソフトウェア・モバイルアプリ など、他者が統合したり直接実行したりするソフトウェアではこの方式は通用しない
- @tinygrad: AIが言ったことが完全に誤った情報かどうかを判別するのに、10秒ではなく 20分かかる時代 に入っており、組織は現実との接点を維持しなければならない
- @beyang: 現在のエージェントUXは "LGTM(Looks Good To Me)" を最も抵抗の少ない経路にしており、エージェントが生成するもっともらしいコードの速度が、コードレビューの検証問題を 差し迫った脅威 にまで引き上げている
- @beh_zod: 出荷の 報酬関数は短く、人々が蓄積している負債を認識するまでの時間は、大半の注意持続範囲を超えている
- @shipwithjay: エンジニアリングリーダーシップが 反事実的な問い（これを止めるには何が事実でなければならないか）に答えられず沈黙するとき、それが症状だ
- @chadfowler: この問題についての本を執筆中であり、核心は 厳密さ(rigor)をアーキテクチャと評価体系へ再配置すること、今こそ時間やコスト不足で実践できなかったベストプラクティスを実行する機会だ
人々の質問や意見に対するMitchell Hashimotoの回答
- Q: "代わりに何をすべきか?"
- A: "考えよ（AIを使っても、考えよ）"
- Q: "AIは過大評価されている" という考えのほうが、むしろより精神病的な症状である可能性が高いと思う
- A: あらゆる世俗的トレンドは過大評価されるが、それは 一律に無視してよい理由にはならない
- Q: "今あるものを守ることと、リスクの中へ飛び込むことのどちらかを選ばなければならないなら、私は後者を選ぶ"
- A: これは 二分法的なスイッチではない
1件のコメント
Hacker Newsの意見
AIアーキテクチャコンサルティングは、セキュリティ侵害対応やデータ復旧の専門家のような、高付加価値コンサルティングの大きな形態になる気がする
純粋にAIが書いたシステムは、人間が理解できない複雑さまで肥大化し、欠陥修正率は下がる一方で、欠陥あたりのトークン消費は増え、最終的にはAIによる変更が直す欠陥より多くの欠陥を生み出して、全体が不安定になる可能性がある
そうした混沌をクリーンルームのように整理し、中核となる設計原則を抽出したうえで、おそらくなおAIを使って新たに再構築する特殊な手順が必要になるだろう
未来のソフトウェア工学は、そもそもこうした事態を避ける原則が中心になるだろうが、既存のソフトウェア工学も安定した設計原則にたどり着くまで予想以上に時間がかかったように、それを学ぶのにも20年はかかりそうだ
病院側はIT部門のサーバーアクセス権まで渡したが、Claudeを接続できずデプロイ方法がわからなくてかなり迷走した末に連絡してきたし、アプリには興味深いデータ／状態関連の問題もあるようだ
まるでAmazonの商品を無制限に無料で自宅配送してもらう人のようで、理論上は豊かな暮らしだが、実際には繁栄ではない何かに埋もれてしまう光景が思い浮かぶ
その結果がどうなったかは、みんな知っているはずだ
数千行のGithub Actionsの中にKubernetesを半分実装していて、理解不能だった
AIマーケティングは嫌いだが、経験のある人がより速く動けるようにする道具としては有用だと思う
ただし専門家でないなら、AIはやろうとすることごとに複雑な解決策を作り出すようだ
彼はAIそのものの使用より、企業や人々が意思決定と思考をAIに外注する現象を言っているのだと思う
AIでコードを書くことがAI精神病というわけでも悪いわけでもないが、ただプロンプトを入れてAIの言うことを信じてしまうなら、それはAI精神病に近いと思う
Twitterの金融界隈の人たちやVCが、少し自分で考えれば済む話をChatGPTのスクリーンショットで思考や推論の代わりにしているのをよく見る
こうしたツールはアイデア、思考、助言にはひどく不向きで、パターンマッチングでそれらしく見えるパターンを出しているだけなので、アイデアを話させるとたいていは最もありきたりなたわごとを吐く
一方で、コード作成のようにパターンマッチングが実際に役立つ作業にはかなり有用だが、思考や意思決定まで任せるべきではない
概して上振れはより高く、下振れはより低くなっていて、上の描写は非常に正確だ
関連して書いた記事は次のとおり: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
最後の記事はAIのおかげで行った複雑な変更で、私がどう合理的にアプローチしているかも示している
ほぼ常に論理的に正しく見えるテキストを作るが、その中にはそのユースケースに合わない誤った暗黙の前提や判断が含まれていることがある
本当に正しい解法を作るには、問題定義がきちんとできていなければならず、それは解法を作ることより難しいかもしれない
あるいは適当なコンサルタントに任せるのとも似ている
「AIが良いアイデアだと言った」が「業界トレンドに従った」より本当に悪いのかと思う
一人でそうなる場合には、友人や家族が妙な行動や発言を指摘して、ある程度ブレーキがかかる
しかし雇用主がリーダーシップのレベルでそれを始めたら、どれほど悪化するか想像しにくい
同調するよう圧力を受けたり、解雇を恐れるようになったりし、考えを調整してくれる人は反対する同僚だけだが、そういう人たちは辞めるか解雇される可能性が高い
仕事を守るには合わせて振る舞うしかない
エージェントが代わりに判断を下すので、エージェントの速度で物事が進み、しばしば何も言わずに決定を下したあと「計画はこうだ」という最終出力だけを渡してくる
それを適切にレビューするには問題を深く理解しなければならず、また人間の速度に戻らざるを得ないので、結局ざっと眺めて承認してしまう
重要なのは、どの判断を外注するかを意識的かつ慎重に決めることだ
そのためには速度を落とす必要があり、誇張された10倍のバイブコーディング利益は減るが、その代わりより多く関与し、認知負債もあまり積み上がらない
配列をどう走査するか、ある呼び出しの出力を別の呼び出しの入力にどう合わせるかといった退屈な判断はエージェントに任せればよい
本当の判断は前もって行い、仕様に落とし込むべきだ。境界、API、主要データ構造、システムと責務、エラー処理、セキュリティとプライバシーの強い制約を定義しなければならない
曖昧なら止まるようエージェントに指示すべきで、良いエンジニアなら副作用なしで2〜3倍の速度向上を得られる
もしかすると、これがソフトウェア工学を本当の工学分野に変えるのかもしれない
今はプロンプターたちが会社全体のインフラを立ち上げている
個人的に知っているある人は、会社のデータベースをより新しいPostgresのバージョンへマイグレーションし、最終的には成功したが、その過程を説明するのを聞きながら歯ぎしりした
「サーバーにガソリンをぶちまけてタバコを吸ったけど心配するな、地下室で消火器を見つけた。ゲージは空を示しているが、振るとまだ液体の音がする」みたいな感じだった
彼が会社を去ったら、そのDBインフラを維持するには、さらに自信満々のプロンプターが必要になるだろう
この記事は、「バグをデプロイしても構わない、エージェントが人間には不可能な速度と規模で直せる」と言う人たちとは議論できないと指摘している
ところが最上位の返信自体が、まさに「でもエージェントはめちゃくちゃ速い」と主張する例になっている
コードベースと機能が2倍になる利益が、バグが2倍になる害より大きいと仮定しているのかもしれない
少なくとも今四半期の投資家向けニュースにはよく見えるだろうが
ひたすらさらに多くのゴミをデプロイし続けるだけかもしれないが、フィードバックループは顧客なのか？
返ってきた答えは「ゲーム理論だ。誰かはやるし、お前もやるしかない。そこまで悪いはずがない」だった
論理は有用だが、リスクを無視するのは別の話だ
とてつもない速度で動いてすべてをぶち壊せば、最終的に良い結果になると仮定するのは危険だ
このAIの流れはうまく進んでいないし、気に入らない
精神病なのは必ずしも「こちら側」だとは思わない
とても大きな会社で働いているが、うちの会社はいつも近代化と技術導入が氷河のように遅かった
ところが妙なことに、それが今や競争優位になるかもしれない
人生が芸術を模倣している
以前は、まだFAXが残っているなんて冗談を言っていたが、こういう熱狂のない文化圏で働けることが、これほどありがたいとは思わなかった
HNを読むと、トークン最大化主義者とAI精神病患者のAlice's Wonderlandに入り込む感じがする
ここでは、こういうやり方で働けと強要されている人を本当に一人も知らない
こういう感じなら、新しいCLIツール**Burn, Baby, Burn (those tokens)**が気に入るかもしれない: https://github.com/dtnewman/burn-baby-burn/tree/main
Show HNはこちら: https://news.ycombinator.com/item?id=48151287
Rich HickeyのSimple Made Easyと、Clojureを作るときのアプローチを思い出す
LLMがプログラム全体を生成する以前から、複雑なフレームワークは開発者にプログラムの初期バージョンを非常に速く作らせたが、その代償として理解しにくくなり、デバッグや修正も難しくなっていた
ある人たちは、AIがどれほど入り組んで複雑なプログラムを書いても、AIは常にそれをデバッグし、保守し、修正できるだけ十分に賢いはずだと賭けている
私にはそこまで確信が持てない
AI精神病はAI利用への反対ではない
AIコーディングツールは毎日使っているが、AIツールには未来という概念がない
「これが本番で壊れたら自分では直せないし、午前3時に呼び出されるんだろうな」と考えるエンジニアの利己的な思考に、私たちは安定したシステム構築を頼ってきた
CPANで完璧なライブラリを見つけて自分で作業したくないという普通の怠惰もあったし、時には自分で書くよりライブラリを探すほうに長く時間がかかることもあった
AIツールで数千行のコードを書いて本番に入れたことがあり、それは概ね自然に感じられた。というのも、2017年から人々に、コードは全部手で打たずに書かせて、テストの中に悪いコードを捕まえる罠を仕込めと言ってきたからだ
だがAIがしないことが一つある。それはコードを減らすことだ: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
バグ報告は、人々が修正されるという信頼を失っても減る
バグを報告するのはかなり大きな時間投資を要することが多いからだ
あるグループや会社への信頼が崩れると、こういうことはかなり頻繁に起こる
そのため誤報の可能性が高く、一部の内容は間違っているかもしれない
複数方向から攻撃されているようなものだ
敵対的戦術の話にすらまだ入っていない
倫理観がないなら、エージェントで競合他社に偽のバグ報告を浴びせる以上に良い方法があるだろうか
問題解決だ
Mitchellが観察したことのかなり多く、おそらく全部は、AIがなくても十分起こりうる
本当に奇妙な立場にいると感じる
AIがコード作成の経験と実践にもたらす変化があまりに嫌で、コンピュータを使う仕事以外なら何でもしたいくらいだが、同時にこれらのツールが非常に強力で、しかも改善し続けているとも思っている
Mitchellの要点はもっともだ。こうしたツールは腐った基礎を持ち込んでも、構造全体が崩れたあとでしか発見されないかもしれない
そのとき責任を負う立場にいながら、以前のようにコードベースを深く理解できていない状況は避けたい
しかし人間も昔から、微妙でありながら致命的なバグをコードに入れてきた
だから多くの部分は、まだ開かれた実証的な問いのように感じられる
以前にはなかった形でひどく崩壊するシステムをたくさん見ることになるのだろうか。ある程度はそうかもしれない
同時に、より仕様と検証の側へ移る必要があることを学ぶのではないだろうか。わからない
いずれにせよ、このやり方でシステムを構築する流れは、途中で衝突があっても避けられそうにない
反AI陣営にも独自の反動的な精神病があるように思える
AIとは関わりたくないが、このツールを使ってみた経験も否定できない
こういう現実的だが否定的なAI論をできる場がもっと増えてほしい
Mitchellが優れた開発者である理由もここにある