永遠のスロプテンバー

23時間前原文(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/

└

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

└

「今は「しばらくコードを書いてない」状態なんだけど、どれくらいの期間で練習不足でコードが書けなくなると思う？エンジニアリングマネジメントの危険の一つは、もうそのことができない人になってしまうことだよね。それって重要なのかな？」

└

比較的簡単なことでも、フロンティアモデルは90%くらいまでは行けるんだよね。でも、その90%がどれくらい良いかは評価してないけど。最後の10%が本当にクソなんだ。しかも、しばしば一番簡単なことがそう。AIを説得してその最後の10%を動かすのには、たくさんのトークンと時間がかかるんだよね。それでも、もう諦めて、自分でスラップを読んでバグを直さなきゃいけなくなるくらいイライラする。

現在のAIの能力を考えると、個人的にはそれを既存の知識を非常に良く検索するものとして考えるのが役立ってる。参考書やStack Overflow、GitHubなどの検索性がさらに一歩進んだ感じだね。プログラマーは同じ技術を他の職業よりも頻繁に書き直したり再発明したりしてるから、過去の技術に対する良い検索ができる準備が整ってたんだ。AIがその過去の技術を特定のユースケースに適応できるのも、さらに強力にしてるよ。ただ、Stack Overflowからコピー＆ペーストしたコードを寄せ集めて成功することはないように、現状のAIもプロジェクト全体を構築することはできないんだ。

└

「AIがその過去の技術を特定のユースケースに適応できるのも、さらに強力にしてる。」まあ、これはみんなが言ってることだけどね。

└

うん、特に重要なことは言えないけど、このコメントには100%同意だな。今のAIは、まるでスタックオーバーフローとGoogleがステロイドを打ったみたいな感じ。でも、俺の経験では、フルスケールのアプリケーションを作るのはあまり得意じゃないと思う。初期のスキャフォールディングくらいはできるかもしれないけどね。レガシーであまり良く書かれてないコードベースに対して使ったら、理解するのが難しいかもしれない。AIエージェントにコードを読ませることはできるけど（例えば、アプリケーションXはYをどうやってやってるのか）、機能をどんどん作らせたりリファクタリングさせたりはしたくないな。それだと、コミットが増えすぎて開発チームが混乱しちゃうから、今の状態よりもさらにひどくなると思う。コメントを残しておくのは、後で見返すためだよ。最近AIにちょっとがっかりしてたけど、これが俺の経験をうまくまとめてると思う。

└

プログラマーは他の職業よりも同じ技術を再構築したり再発明したりすることが多い。これに対する答えは、実際に使えるライブラリをパッケージするよりも、再構築や再発明を安くするツールだね。

俺の仕事の一部は、こういうモデルを大企業で生産的に使えるようにすることなんだ。壁にトマトを投げるような感じで、彼が言ってる出力に一定の限界がある問題は理解できる。でも、彼の投稿には「ここでモデルがうまくいかなかった」とかのコードスニペットが全くないのが気になる。この手の批判は「LLMは絶対にうまくいかない」っていうブログやツイッターの投稿によく見られるパターンだよね。彼らは明らかにオートコンプリートよりも良いパフォーマンスを発揮できるし、俺の普段の開発では、ジュニアや中堅エンジニアがやるべきだと思ってた大部分のコードベースを構築できてる。具体的にどんな間違いをしているのか誰も指摘しないから、彼らの実際の能力をどう理解すればいいのか分からないよ。

└

「実際に彼らの能力を理解するには、誰も具体的にどんなミスをしているかを指摘しないから難しいよね。彼らのミスは結構微妙なんだ。LLMでのコーディングは、映画『Whiplash』のシーンみたいなもので、テンポが合わない、18でビートがずれてる、急ぎすぎ、引きずってる…みたいな感じ。ほとんどいつも動くコードを生成するし、コードは大体要求した通りに動くんだけど、微妙に正しくないから椅子を投げたくなるようなイライラ感がある。しかも、どう間違っているのかすら分からないんだよね。」

└

それ、めっちゃいいポイントだね。LLMを使って以前は夢にも思わなかったプロジェクトに取り組んでる初心者として、エージェントが具体的に何を間違って書いているのか、そして人間ならどうやってもっと良くできるのかを探してる。そういう例がどこかにあるはずだから、誰か良いコンテンツを紹介してくれないかな。トップクラスのコーダーたちはClaudeやCodexの周りを軽々と回れるだろうけど、平均的な人と比べてどれだけ劣っているのかは気になる。

└

この記事は、悪いアーキテクチャを示すコードスニペットを含む詳細な例がたくさん載ってるよ：https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

└

誰かがLLMが特定のタスクで失敗したってブログに書くと、ブースターたちの反応はいつも「別のモデルを使えばいい/プロンプトをこう変えればいい/君がスキル不足なだけだよ—具体例を挙げてAIについて根本的な議論はできない」って感じ。具体例を挙げて議論できないし、挙げないと議論もできないってことか。うーん、これが現実ってことだね。（はいはい、グループ帰属エラーを犯してるけど、それでも）

現在の議論の多くの問題は、白黒はっきりしすぎていることだと思う。ルダイトか「AIに夢中」かのどちらかだね。ほとんどの場合、LLMは80-95%のところまで行けるけど、時にはそれ以下、時にはそれ以上のこともある。時には、全然違うところに行っちゃうこともあるし。でも、みんなLLMが完璧なソフトウェアエンジニアになれるかどうかを議論してるけど、それが他のシナリオでのLLMの大きな可能性を否定する理由にはならないと思う。時々、インターネットが私たちに与えてくれたものから、ほとんどの組織がどれだけ生産的になれるかを想像するのが好きだ。ほとんどの会社は、実際に可能なことのほんの一部もやってないから。それがLLMに対する俺の見方を固める助けにもなってる。問題は、親愛なるブルータス、私たちの言語モデルにあるんじゃなくて、自分たちにあるんだ。

└

そうそう、AIじゃなくて「私たち」なんだよね、それが素晴らしい。なんで「ツール」を「ソフトウェアエンジニア」と比べる必要があるの？「大きな幻想」は「AIがコードを書けない」ことじゃなくて、明らかに書けるし、かなり上手い。問題は「擬人化」とか、AGIのナンセンスだよね。「確率的メカニズム」って呼んで、プロンプトを「パーソナライズ」せずに「チャット」って呼ばず、個性を持たせなければ、比喩が判断を曇らせることはないと思う。AGIについては哲学者たちに議論させればいい。

└

「今の議論の多くの問題は、白黒はっきりしすぎてることだと思う。合理的な議論ができるほどお金が絡んでる。」

└

それってgeohotの言いたいことでもあると思う。彼らは完全に「AIに依存する」ことに反対してるんだよね。AIは道具として使うべきで、ラッダイトになるためじゃないって。

└

大抵の場合、LLMは80-95%のところまで行ける、時にはそれ以下、時にはそれ以上。私もそう思うけど、私の場合は60-95%の解決策で、必要なコードの行数は120-140%くらい。変更すべきコードをマスクできるハーネスがあればいいのに、プロンプトベースのリファクタリングは同じように過剰に反応しちゃうから。1. まずは速くて小さいモデルを試してみる。

└

面白いことに、本当のラッダイトについて知れば知るほど、彼らの視点が理解できるようになる。「元々のラッダイトたちは、劣悪な商品を「詐欺的かつ欺瞞的に」製造するために使われる機械に抗議していたんだよね。労働基準を回避し、熟練工の生計を奪うために。」

現在、グレー市場のペプチドを買って、「人間の消費には適さない」と書かれたものを注射してる人たちがいるんだ。疑わしい逸話や雰囲気を元に、肌をきれいにしたり、筋肉を増やしたりするためにね。彼らは突然ゾンビになってるの？いや、そうじゃない。数年後に自分の体に何が起こるか本当に理解してるの？それもない。壊滅的な結果になる可能性はある？多分！このことを考えると、ここ6ヶ月くらいで業界がAIをコードの主要生成者に急激にシフトさせたことが思い浮かぶ。AIはペプチド、君のコードベースは体。維持可能性については誰も知らない、なぜなら調べる時間が全然足りてないから。大丈夫かもしれないし、完全に混乱するかもしれない。君のエンジニアチーム全体が運転中に寝てしまって、何が作られているのか理解していると思い込んでいるけど、実際にはそうじゃなくて、LLMがもう使えなくなった時に修正や維持が全くできなくなるかもしれない。[1] https://www.bbc.co.uk/news/articles/cdr268m5pxro [2] まあ、彼らのコードベースね。自分の個人のコードベースでは、維持可能性や長期性を気にしない限り、もうやめた。

└

賢い開発者は孤立したモジュールを作ると思うから、もしAIが生成したモジュールがずっと失敗するなら、切り捨てて新しいのを作ればいいんだよね。

人々はアーティファクトを見ると、それを作るために使われたプロセスについて仮定をする。考えもせずに、創造者は基本的に人間の心の状態を持っていると仮定する。この仮定はもはや真実ではない。物事は以前には不可能だった方法で壊れることがあり、文法や構文のような古い品質の代理指標は役に立たない。AIが生み出したアーティファクトは、人間が作ったものとは同じプロセスで作られていなくて、この違いは統計的には非常に微妙だけど、人間的な方法でアーティファクトとやり取りしたり、構築しようとすると明らかになる。昔は人間は口頭言語だけを持っていて、言葉を使ってアイデアを一つの人間の心から別の人間の心に伝えていた。それから書き言葉ができて、アイデアは空間や時間で近くない心にまで伝わるようになった。そしてこれによって、私たちは複雑なグローバルな文明を築いた。言葉がただのノイズになってしまったとき、どれも他の人間の心から来ているのか、ただの統計的プロセスなのか疑わしくなる。この文明は果たして生き残れるのかな？

でも、毎回手動でやった方が早くて上手くできたんじゃないかって疑ってしまうんだよね。手動では早くできないタスクの種類があって、色の匂いが鶏肉のようで数字に味がある天才じゃない限り、無理だと思う。それとは別に（今のところの私の疑念は、非標準のタスク＋フレームワークかな）、エージェントを使うより遅いタスクもある。だから、USBハッキングみたいなタスクでは、君が優れた経験を持っていて、LLMより早くできるのは想像できる。一方で、私にとっては、Java開発者として、USBハッキングがLLMのおかげでやっと可能になった。そうじゃなければ、しばらく学ぶために時間を取らなきゃいけないし、そんなことはしたくないから、要件を満たす高価なハードウェアを買うか、USBリバースエンジニアリングのプロジェクトを100エーカーのやることリストに放り込むしかないね。

こういうブログがトピックに関して完全に白か黒かになると、ちょっと疑っちゃうんだよね。人生において0か1なんてないから。AIもそう。良い面もあれば明らかな問題もある。どれもそんなに大したことじゃないし。人は会話を盛り上げるために極端な立場を取ろうとするけど、それが対立を生んで、話を引きつけるんだよね…。

ハクソク