世界を動かす技術を、日本語で。

永遠のスロプテンバー

2026年5月25日原文(geohot.github.io)

概要

  • AIエージェントのソフトウェア開発導入は、業界史上最大級の誤りになる可能性
  • AIはプログラムを「模倣」するだけで、本質的な理解や品質保証ができない
  • 高パフォーマンスな個人や小規模組織はAIの限界を認識しやすいが、大組織はリスクが高い
  • AI生成物は人間の思考プロセスを持たず、従来の品質指標が通用しない
  • 真のプログラミングAIには「世界モデル」が不可欠で、現状のLLMでは不十分

AIエージェント導入の過大評価とその危険性

  • AIエージェント のソフトウェア開発導入は、業界史上最も コストのかかる失敗 になる可能性
  • AIはプログラムを「 模倣」する高度な統計モデルに過ぎず、本質的な 理解や創造性 を持たない
  • 出力されるコードは一見正しくても、 見抜きにくい破綻 が潜んでいる傾向
  • これは統計モデルの精度向上により、 表面的な品質 が上がる一方で、根本的な問題が見えにくくなる現象
  • AIが本当にプログラムできるのか という疑念は、自己評価や地位不安から来るものではなく、実際の体験に基づく問題意識

実体験から見るAIエージェントの限界

  • 6ヶ月間、 tinygradの一部やUSB⇔PCIeチップのリバースエンジニアリング をAIエージェントと共に実施
  • 毎回「 手作業の方が速く高品質」という感覚が拭えず、AIは初期進捗は早いが 仕上げができない
  • さまざまなモデル・プロンプト・ツールを試しても結果は同じ
  • 使い方が悪いだけ」という指摘は、ギャンブルの勝ち方指南と同じで本質的な解決にならない
  • AIは検索やプロトタイピングには有用 だが、エンジニアとしての水準には到底及ばない

AI活用の適切な判断と組織規模のリスク

  • 重要なのはAIを使うべき場面と使わない場面を見極める力
  • 高パフォーマンスな個人や小規模組織は、 自己修正能力 が高く、AIの出力も慎重に検証
  • 大組織では フィードバックが遅く、自己チェック機能が弱い ため、AIの「スロップ(粗雑な出力)」が大量生産されるリスク
  • 下位パフォーマーほどAIに依存し、 組織全体の平均品質低下 を招く可能性
  • 世界全体でも、 量産される粗悪なコードやアプリ が増え、「質の時代」から「量の時代」への転換

AI生成物の本質的な違いと今後の展望

  • AI生成物は 人間的な思考プロセスを持たず、従来の 品質指標(構文や文法など) が通用しない
  • Appleのような大企業がAIを全面導入した場合、 macOSなどの品質悪化 が懸念
  • 「AIが作ったもの=人間が作ったもの」という 無意識の前提 が既に崩壊
  • AIの出力は 統計的には正しく見えても、人間が拡張・修正しようとすると破綻 しやすい

真のプログラミングAIに必要な要素

  • LeCunやGary Marcusらの「 LLMは本質的に限界がある」という意見に賛同
  • 現状の RLVR的なアプローチ では限界があり、真に有用なエージェントには 世界モデル が不可欠
  • 自己欺瞞的なAI活用 に陥らず、冷静にリスクと可能性を見極める姿勢が重要

Hackerたちの意見

AFLはLLMsよりも多くの脆弱性を見つけたわけじゃないよ。AFLと熟練の実践者が脆弱性を見つけたんだ。AFLはバグを引き起こすけど、その多く(ほとんど?)は悪用できないもので、人間(今はエージェントもね)がそれを選別して評価しなきゃならない。彼らはAFL以前のメモリ安全でないソフトウェアのコーパスでそれをやったんだ。AFLの全盛期は10年前だったし、今はどのターゲットも難しくなってる。

僕の予想では、モデルはどんどん良くなっていってるね。1、2年前にエージェントコーディングに入ったときは、オートコンプリートだけが得意だと思ってた。でも、今年の初めに何かが起こって、モデルが新しいレベルの能力に達したんだ。今知ってる人たちはみんなエージェントコーディングをやってて、本当にすごいよ。これをできるだけ押し進めていくべきだと思う。人類の加速が始まってる感じがするね。

もうすでにいくつかの物流的な限界に達してるよ。トランスフォーマーが本質的な能力の停滞を持っていなくても、GPUの数やそれを改善するためのパワーには限界があるし、そのインフラを拡張するのがすごく難しいことがわかってきた。過去2年間で6GWの新しいデータセンターが発表されたけど、実際に稼働したのは1GWにも満たないし、残りの納期もどんどん遅れてる。データセンターは、そこにあるチップが6年持つかのように話してるけど、それもかなり無理があるみたいだね。

もし我々が壁に向かって加速しているとしたら?

... 俺もオートコンプリートだけが得意だと思ってた。今年の初めに、モデルが新しいレベルに達したみたいなことがあったよね。そう、何かが起こって、オートコンプリートが良くなった。ほかに何があるっていうの? 基本的なモデルは変わってないし。 >人類の加速 もうこのクソみたいな話はやめてくれ。誰も癌や気候変動、不平等、その他の重要な問題をLLMで解決してるわけじゃない。誰もね。この技術があなたをもっと生産的にするのは、ただ新しいことや最先端のことに取り組んでないからだよ。LLMがあなたの仕事をできるのは、そのコードがトレーニングデータに何度も出てきたからに過ぎない。C++26やHDL、ニッチなスタックを書くのにLLMを使ってみなよ。そうすれば、LLMについての現実をしっかり理解できると思うよ。

人類の加速って、今年読んだ中で一番の言い訳だわ。

今は「しばらくコードを書いてない」状態だよ。手動コーディングに戻るほど大きな問題の例を見てみたいな。僕の主な問題は、モデルのリリース間での品質の不一致と、特にコマンドラインツールで古いAPIやドキュメントが挿入される傾向だね。モデルが10年分のクルフトを抱えた百万行のモノリシックコードベースに苦労するのは理解できるけど、新しいコードベースでそれがそんなに面倒になる理由が思いつかないな。

どんなプロンプトも千行のPRを生み出すと、また百万行のモノリスに近づいてるよね。でも、著者よりはちょっと希望を持ってるかな。そうならないようにプロセスを管理することは可能だと思う。

AIが自分で作った複雑なバグや問題を解決できてないみたいだね。18ヶ月間、MAUIプロジェクトで全然役に立ってない。ゲーム開発におけるネットコードの一貫性やパフォーマンスに関しては、まったく期待できない感じ。ユニークなゲームメカニクスも苦手みたいだし、特定のUIスタイルの変更を頼むのは、的にダーツを投げて当たることを願ってるようなもんだね。

手動コーディングに戻るほど大きな問題の例を見てみたいな ああ、君の組織はまだ悪いLLMコードのプッシュでダウンしたことがないみたいだね。

最近フロントページに載ったやつだよ: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

どんなプロジェクトに取り組んでるの?特に新しさや、ググれないデータポイント、業界標準からのプロジェクト特有の逸脱がどれくらいあるのか気になる。

Hacker Newsで議論の続きを見る