永遠のSloptember
(geohot.github.io)- AIエージェントはプログラミングを行うというより、プログラミングの分布を模倣しており、壊れた出力はますます見分けにくくなっている
- tinygradの一部の作成とUSB <-> PCIeチップのリバースに使ってみたが、自分でやったほうがより良く、より速かったかもしれないという疑いが残る
- エージェントは序盤の進捗を速めるが、仕上げの段階ではスロットマシンのレバーのように反復試行に頼らせ、最後まで到達できない
- 大規模組織は遅いフィードバックループと自己点検のない10倍の産出のため、高成果の個人よりも大きな品質被害を受ける可能性がある
- AIは検索と高速プロトタイピングには有用だが、実際のソフトウェアエンジニアと見るのは難しく、いつ使わないかを知ることが重要である
AIエージェントに対する核心的な批判
- AIエージェントをソフトウェア開発に導入する流れは非常にcostlyな失敗になる可能性があり、エージェントはプログラミングそのものではなく、プログラミングの分布を模倣する精巧な統計モデルに近い
- 生成物は壊れているが、ますます検出しにくい形で壊れており、統計モデルがより正確になるほど、こうした問題はさらに見抜きにくくなる
- 過去6か月の間、エージェントでtinygradの一部を書き、USB <-> PCIeチップをリバースしたが、自分でやったほうがより良く、より速かったかもしれないという疑いが残る
- エージェントは初期の進捗を前倒しするが、仕上げ段階ではスロットマシンのレバーを引くように結果が良くなることを何度も期待させ、最後までたどり着けない
- 複数のモデル、ハーネス(harness)、プロンプトを試したため、「使い方が間違っていた」という反論には説得力が乏しく、スロットマシンでは特定の賭け方をすれば勝てるという話に近く見える
- AI自体は有用で、多くの検索ではより良いGoogleのように機能し、完成度を気にしない高速プロトタイプには非常に速い
- ただしソフトウェアエンジニアと見るのは難しく、一緒に働いたどの会社の基準にも近くなく、重要なのはいつ使い、いつ使わないかを知ることにある
組織と品質に及ぼす影響
- AFLはLLMよりも多くのバグを見つけたが、開発者たちは地位の喪失を恐れなかったし、チェスやGoもAI以後さらに人気を得たため、AI批判を単なる地位不安としてだけ見るのは難しい
- 信頼できるロボット補助者がコードを整理してくれる未来には期待できるが、大企業を動かそうとするやり方として喪失への恐怖がエージェント販売に利用されているように見える
- 高成果の個人や小規模組織よりも大規模組織のほうが、エージェントによってより大きな被害を受ける可能性が高い
- 高成果者は誤りを修正でき、産出物が粗いときにそれと気づきやすく、限定された領域でない限り各行を注意深く読み理解するやり方を維持する
- 大規模組織はフィードバックループが遅く、アラインメントが弱いため、低成果者が自己点検なしにエージェントで10倍の産出を生み出すと、平均的な産出品質が下がる可能性がある
- エージェントは以前よりも多くのコード、アプリ、機能を生み出すだろうが、高品質な宝石よりも大量の粗い産出物が積み上がる時代になるかもしれない
- AppleがすべてのエンジニアにAI利用を強く推しているという話は、抽象的な期待よりも「今後2年間でmacOSが良くなるのか悪くなるのか」のような具体的な問いとして見るべきである
- 人々は産出物に対して、作り手が人間的な心の状態と過程を経たのだと暗黙に仮定するが、AI産出物ではこの仮定がもはや当てはまらない
- 文法や構文のように、過去には品質の代理指標として使われていた要素は、AI産出物の前では有用性が薄れ、人間的なやり方で相互作用したりその上に何かを作ったりするときに違いが現れる
- LLMについてはLeCun/Marcus寄りの立場に近づいており、この種のモデルではプログラミングはできず、過程が重要だという結論につながる
- ディープラーニングは依然として解決策になり得るが、実際のプログラミングエージェントには、failing testをコメントアウトしたうえですべてのテストが通ったと言うようなRLVRではなく、世界モデルが必要である
- この時代の核心は、AIに対する集団的な過熱の中で、誰が自分自身を傷つけずに持ちこたえられるかになるかもしれない
1件のコメント
Hacker Newsの意見
現在の議論における大きな問題は、あまりにも二項対立になっていることだ。LLMに懐疑的ならラッダイト、信じるなら“ai pilled”という具合だ
たいていの場合、LLMは80〜95%のところまでは連れて行ってくれるし、ときにはそれ以下だったり、それ以上にうまくやることもある。たまに完全に間違った方向へ連れて行くこともある
それなのに皆、LLMがクローゼットの中で一人で完璧なソフトウェアエンジニアになれるかどうかだけを巡って争い、それを根拠に他のシナリオでの巨大な可能性まで否定しているように見える
インターネットがもたらしたものだけを考えても、ほとんどの組織が今よりどれだけ生産的になれたかを思えば、実際の企業は多くの場合、可能なことのごく一部すらできていない。LLMもそういう観点で見ている
問題は言語モデルではなく、私たち自身にある
もともとのラッダイトは主に、粗悪な商品を「詐欺的かつ欺瞞的」に作り、労働基準を回避し、熟練職人の生計を奪う機械に抗議していた人たちだった
私はエージェントは使わず、単純なチャットインターフェースと継続する対話を通じて、関数単位でソフトウェアを作っている。結果のワークフローはかなり“キメラ的”だが、私の経験と専門性から大きな恩恵を受けている。LLMはそのプロセスを滑らかにしてくれるだけだ
私の場合はうまく機能していて、以前には戻りたくない
今日の議論で「ラッダイト」と呼ばれる人たちは、だいたい「AI」誇張をあえて疑う人たちだ。たいていそういう人たちは活動家でもない
今のAIの能力水準では、既存知識の上で動く非常に優れた検索に近いと考えるのが、個人的には役に立った。リファレンス、Stack Overflow、GitHubへと続く検索可能性の次の段階のように見える
プログラマーは、私が思いつくどんな職業よりも同じ手法を再利用し再発明することが多いので、先行技術を非常にうまく検索する道具に向いていた。AIがその先行技術を特定のユースケースに合わせて調整できる点は、さらに強力にしている
ただし、Stack Overflowからコピーしてきたコード片をつなぎ合わせても大きな成功にならなかったのと同じように、現在のAIもプロジェクト全体をまともに作ってはくれない
古くてあまり使われていないレガシーコードベースなら、たとえば「アプリケーションXはYをどうやっているか」のように、AIエージェントにコードを読ませることはできる。だが、機能を片っ端から作らせたり、リファクタリングを任せたりはしないだろう
そうするとコミットが多すぎて開発チームに混乱が生じ、すでに抱えていた寄せ集めよりもさらにひどい結果になる可能性が高い。最近のAIには少し失望していたが、この説明は私の経験をよく要約している
ソフトウェアエンジニアリングで最も難しいのは、正しい問題を解くことだ。どの問題を解くべきかを見極める能力が、上位のシニアエンジニアを分けるのだと思う
ここでは単純化して、解決したときに製品にもたらす価値が、複雑さや付随コストに比べて最も大きい問題のことだとしよう
昔、あるWeb製品で働いていたとき、もともとジュニアデザイナーが、バックエンドをLDAPツールで管理できたら格好いいと考えていた。そこで製品のデータベーススキーマと構造はOpenLDAPを模倣し、複合CNキーを使っていて、コードベース全体がDBを読み書きするたびにその構造を扱わなければならなかった。DBスキーマを設計するとき、LDAP互換性は解くべき正しい問題ではなかった
正しい問題を解くソフトウェアは、見分けにくいことがある。たいていは動作の仕方があまりに当然に見えるため、別の設計を選べたという事実が見えにくいからだ
時間がたっても、間違った問題を解く設計の爆発半径を制限してくれるのは、たいていその設計が生み出す摩擦だ。開発は遅くなり、間違った問題をさらに多く解く開発も遅くなる。自己制限的な現象だ
LLMコーディングエージェントで強く懸念しているのは、まさにここだ。その摩擦を覆い隠してしまう。修正するのではなく、コストを先送りする
その結果、提供する価値に対して複雑さが無制限に膨らむコードベースが生まれ、それを制御する仕組みがなくなる
ジュニアたちは、特定の設計においてどんな問題が解くべき正しい問題なのかを判断するエンジニアリングの勘やセンスを育てるフィードバックループを経験できなくなる
分野全体の規模では、正しい問題を解くという概念が存在していたこと自体を忘れてしまうかもしれない
どうすべきかは分からない。早期リタイア計画でも立てるべきなのかもしれない
今、グレーマーケットのペプチドを買って、「人体摂取用ではありません」と書かれた物質を、怪しい体験談や感覚だけを頼りに注射している人たちがいる。肌をきれいにしたり筋肉量を増やしたりしたい、というわけだ
彼らが突然みんなゾンビになっているのか？ いや。数年後に自分の体に何が起きるのかをきちんと理解しているのか？ それも違う。破滅的な結果になりうるのか？ ありうる
この比喩を思い出すのは、ここ半年ほどで業界がAIをコードの主な生成手段へと激しく切り替えたことを考えるときだ。AIがペプチドで、コードベースが身体だ。このやり方がどれほど保守可能なのか、文字どおり誰にもわからない。確かめるのに十分な時間がまだ経っていないからだ
うまくいくかもしれないし、完全な大混乱になるかもしれない。エンジニアリングチーム全体がハンドルから手を放して眠り込み、実際には理解していないのに自分たちは何を作っているのか理解していると思い込み、LLMがもう対処できなくなった瞬間に修正や保守を行う力が完全に失われる可能性もある
https://www.bbc.co.uk/news/articles/cdr268m5pxro
自分の個人的なコードベースでは、保守性や寿命に本当に関心がない場合でない限り、もうそうはしていない
今の自分は「しばらくコードを自分で書いていない」側にいる。手作業のコーディングに戻るほど深刻な問題の例を見てみたい
自分の主な問題は、モデルのリリースごとに品質がばらつくことと、特にコマンドラインツールで古いAPIやドキュメントを紛れ込ませる傾向があることだ
10年分の澱が積もった100万行のモノリシックなコードベースでモデルが苦戦するのは理解できる。だが、新しいコードベースでなぜそこまでつらくなるのかはあまり思い浮かばない
コーディングはそれほど難しくないので、英語を読んだり書いたりするより、ただコーディングしたほうが簡単なことも多い。もっとも、自分はHaskellしか使わないので偏っているかもしれない
エンジニアリング管理のリスクの一つは、その仕事がもうできない人間にしてしまうことだ
それは本当に重要なのだろうか？
それでも筆者よりは少し楽観的だ。その事態が起きないようにプロセスを管理することは可能だと感じる
エージェント実行環境は登場してまだ1年少々で、かなり信頼できるようになったのも半年ほどなのに、もう疲労感が大きい。これはLLMが実際にプログラミングできるかどうかというより、AI支援プログラミングの精神的消耗をよく示していると思う
エージェントがコードベースに何をしているのかをきちんと追うには意思決定の頻度が高くなり、天文学的な量のコードと散文を読まなければならない
この個人的・心理的な疲労や否定的感情が、技術そのものの発展可能性に対する悲観的な見通しへと不正確に転写されている
きちんと使っている人がみなフラストレーションを抱え、それを好む人たちが保守不能なごった煮を山のように作り出すのなら、私たちは近いうちにそれを歴史のゴミ箱に捨てることになるだろう
「潜在力」があるものは多いが、結局は何にもならないものも多い
LLMはこれからも使うだろうが、私の考えではエージェント型コーディングの有用性はすでに頂点を過ぎている
私の仕事の一部は、勤務先の大企業でこうしたモデルをどうすれば生産的に使えるかを探ること。壁にトマトを投げつけるような感じに近く、ある程度は彼の言う通り、出力に特有の限界があるような問題も見ている
同時に、彼の文章のどこにも「モデルはここでひどく失敗していて、本来はこうすべきだった」と掴めるようなコード断片や具体物がない。こういう批判の仕方は、ブログやTwitterの「LLMは絶対にダメだ」系の投稿で繰り返されるパターンに見える
モデルは明らかに単なるオートコンプリート以上のことができるし、私の日常的な開発でも、ジュニアや中堅エンジニアが書いたようなコードベースの大部分を作り出してくれる
実際にどんなミスをするのかを誰も具体的に引用しないなら、私たちはどうやって実力を把握すればいいのか？
ほとんどいつも動くコードを作り、たいていは頼んだこともやってくれる。だが、ものすごくもどかしい形で少しずつ間違っていて、椅子を投げたくなる。しかも、何がどう間違っているのかに気づくセンスすらない
すると具体例を出してもダメ、具体例を出さなくてもダメになる。ならもうゲームセットだ
集団帰属の誤りを犯しているのは分かっているが、それでもそういうことだ
そういう資料は確実にあるはずで、良い例を示しているコンテンツがあれば誰か教えてほしい
上位数パーセントのコーダーがClaudeやCodexよりはるかにうまく書けることは疑っていない。ただ、平均的な普通の開発者よりどれほど劣るのかは気になる
私の推測では、モデルは今後も良くなり続ける
1〜2年前にエージェント型コーディングを始めた頃は、オートコンプリート程度にしか役立たないと確信していた。今年の初めに何かが起きて、モデルは新しい能力水準に達した
今では私の知っている人はみんなエージェント型コーディングをしていて、本当に驚くべきことだ。行けるところまで押し進めるべきだと思う。人類の加速が目の前に来たように感じる
この2年間で約6GW規模の新しいデータセンターが発表されたが、実際に稼働してサービスを始めたのは1GW未満だ。残りの納期はずっと先延ばしになっている
しかも、データセンターは中のチップが6年は持つかのように語るが、それも無理だということが明らかになりつつある
「人類の加速」みたいな話はもうやめてほしい。LLMでがんや気候変動、不平等、そのほか重要な現実の問題を解決している人など誰もいない
この技術が生産性を上げるのに十分まともだとしても、それはあなたが新しいことも最先端のことも革新的なこともしていないからだ。LLMがあなたの仕事をできる唯一の理由は、そのコードが学習データに十分多く現れるほど、すでに文字通り書かれているからだ
LLMでC++26やHDL、あるいは非常にニッチなスタックを書いてみれば、現実を思い知るはずだ
AFLがLLMより多くの脆弱性を見つけたわけではない。AFLと熟練した実務者たちが脆弱性を見つけたのだ
AFLは不具合を引き起こし、そのかなりの部分、あるいは大半は悪用可能ではない。人間が、今ではエージェントも含めて、それらを選別し評価しなければならない
しかもその作業は、AFL以前のメモリセーフでないソフトウェアのコーパスで行われていた。AFLの全盛期は10年前で、今では対象はどれもずっと難しくなっている
文脈を補うと、筆者はGeorge “geohot” Hotzだ。長いエクスプロイト歴があり、最もよく知られているのはおそらく、実際のAIバイブコーディングが登場するよりずっと前に、少ない予算で自動運転車向けのcomma.aiをほとんどバイブコーディングのように作ったことだろう
https://en.wikipedia.org/wiki/George_Hotz