GPT 6 Astra、35時間で「価値あるものゼロ」——AIエンジニアリングは内巻に陥っている
Astra for Coding: Why Are We Doing This Again?
Armin Ronacher氏が、OpenAIの最新モデル「GPT 6 Astra」をソフトウェアエンジニアリングに使った経験を報告。同モデルは3D生成やロボット掃除機のリバースエンジニアリングで驚異的な能力を見せる一方、コーディングではトークン効率を優先するあまり、人間には判読不能なPython文字列操作や多段シェル呼び出しを多用。35時間の「ソフトウェアファクトリー」実験では、約40億トークンを消費しながら価値ある成果を生まず、タスク名も「8b2c2b2b checkpoint1」へと崩壊。同氏は、AIエンジニアリングが努力を増やしても成果が向上しない「内巻（Neijuan）」に陥っていると警鐘を鳴らす。
私はますます、AIエンジニアリングのすべてが内巻（Neijuan）だという確信を強めている。中国では、それは成果を改善することなく、ますます多くの努力と競争を要求するシステムを指す。
HNでの議論
312- taurath
コードがクソになると、モデルが変更を加えるのがどんどん難しくなり、進歩が完全に止まってしまう——これは「工場」を試して数ヶ月ごとに改良ステップを踏んでいる時の私の経験だ。
コードを一切読まなくなったと言う人たちが何をしているのか、本気で理解できない。何度も積み重なるこうした問題に真っ向からぶつからないのは、ある程度簡単なことなのだろう——そして人々は「もっと上手くプロンプトを書けばいい、自分にはその問題は起きない」と言うが、同じ人たちのコードを見ると恐ろしいもので、さらに彼らが概念実証の段階をほとんど超えていないことが分かる。チーム全体が這うように遅くなり、変更や本番障害に対応できなくなるのを目の当たりにしている。話をする多くの人々の間でこれは一般的なようだ。
個人的には、推進派は有言実行するか黙るべきだと思う——約束はあまりにも過剰だ。これらの手法の強力な提唱者として私が見てきた人は皆、ほぼ無制限のトークンを使える上に、解決策を売るビジネスをしているように見える。現在何かをマーケティングしていないエンジニアが、本番システムでこれらの手法を使って成功している例は、ごく単純なものか、より成熟したコードベースでの非常に特定的なタスクでない限り、ほとんど見つけられない。
- nojs
これはこれまでのAstraに関する私の経験とも一致する。
> トレーニングプロセスで何かが「おかしく」なっているのではないかと疑っている。モデルは長期的なタスクの成功に対して大きく報酬を与えられるが、おそらく「クソコード」に対する罰則はほとんどないのだろう。
私の推測では、OpenAIとAnthropicの両方がここ数ヶ月でRLの目標を「人間のフィードバックに基づいて有用と評価されること」から「長期的なタスクで成功すること」に移した結果、自律的なタスク完遂という意味ではAGIに近づいたが、コミュニケーションが奇妙に下手なエージェントが生まれた。
その結果、彼らは長期的なタスク、コンピュータ操作、難しい数学/ARC-AGIタイプの問題の解決において驚くほど優れているが、一緒に働くのはどんどん奇妙になっている。
- specproc
> 私はAIエンジニアリングのすべてが内巻（内卷、内側に巻き込むという意味）であるとますます確信している。中国では、成果を改善することなく、ますます多くの努力と競争を要求するシステムを指す。西洋で時々現れるのは996のナンセンスだ。Neijuanの英語訳は『Agricultural Involution』という本からの「Involution」である。農業のインボリューションは、一人当たりの生産性を変えずに平方メートル当たりの生産性を高める農業の集約化を描写している。
これは響くものがある
- codingisfreedom
Sonnetを使って素早く作ったプロトタイプ用のアプリをAstraに作ってもらうよう頼んだ。
2日経っても、実際のアプリは全く進歩していない。ドキュメント、スクリプト、ワークフローを作り、あらゆるPRで大量のレビューをしている。
私はただMVPが必要だと言った。
平均的なシニアエンジニアならもっとずっと早くそのタスクを終え、しかも間違いなくより読みやすく高品質なコードを書いただろう。一方で、私は何もないことにすでに10万トークンを軽く超えたと思う。
これが「SOTA」で「AGI」だなんて、なんて面白い世界だ。
OAIとA/のエンジニアたちがこれらのモデルをそこまで褒めるのは、一体何に取り組んでいるからなのか本当に好奇心が湧く。Opus 4.5以来、何の改善も見ていない。
また、世に出ている「ワンショット」デモには全く感心しない。真剣なソフトウェアエンジニアリングにとっては何の意味もない。
- buildbot
OpusやFableでも全く同じパターンを観察している——例えば、ファイルを編集できることを忘れて、代わりにPythonスクリプトをパッチツールとして使うなど…
- gps372
AIエンジニアリングから学んだ初期の教訓は、エージェントにきちんと整備されたエピックを与えることに代わるものはないということだった。単に「私の製品にテーマを実装して」と言うのではなく、具体的に、実際には通常よりもっと具体的にする必要がある。何がスコープ内で何がスコープ外かを、ボタン、イベント、レイアウトに至るまで正確に言わなければならない。
AIの助けを借りてエピックを整備することはできるが、最終レビューは仕様の責任を負い、何かが漏れた場合に責任を取れる人が行わなければならない。AIの応答はその特定のエージェントの出力トークンによって制限され、AIが自分の間違いを受け入れても何の罰則もない。
- _usefulcat
反論を提出したい。私は確立されたコードベースで新機能を構築し、バグを修正している。ストーリーボード、git、その他いくつかのMCPにアクセスできる。ストーリーが明確な要件と期待を持ってよく書かれている限り、常に高品質なコードを生成し、私は自動テストと手動テストの様々なテストで人間として検証する。コードをピアレビューする。同僚もそれをピアレビューする。
二つのことに気づいた——新機能は以前かかった時間の少なくとも半分で済み、バグはずっと少ない。バグ修正ではさらに速い。
私の結論は、堅牢な要件、明確なコンテキスト、そして主に計画時だけでなく検証時にも思慮深い人間の監督が必要だということだ。
- juancn
コンテキストウィンドウに入るクソみたいなものは何でも、全体をクソに変えてしまう。
これまでのところ、ほぼどのモデルでもこれが私の経験だ。
コンテキストは自分の出力を餌にする。
一度その道に入ると、止めて十分な反例と望むものの詳細を与えない限り（つまり、潜在空間でより良い地点に向かってナッジしている）、退化し続ける。
修正する機会を得る前にコンテキストウィンドウが圧縮されるとさらに悪化する。
長期的なエージェントは機械の速度で退化しうる。
それでも、短期的でよく仕様化されたタスクを与えた方がずっと良い結果が得られると思う。
- Gigachad
新しいモデルが、完全に読めず、存在するすべてのオプションフラグを利用する、とんでもないbashコマンドやPythonスクリプトを実行したがるのを同じように観察している。
レビューするのは不可能だ。これらのコマンドは正規表現よりも読みにくい。
- AmazingTurtle
gpt-6-astraは厄介で、あの忌々しい磨きをかけるために「また別のもの」と常にスコープを広げてしまう。結果は最終的に少し良くなるが、その代償は？計算してみよう。
gpt-5.6-sol: 1倍ベース
gpt-6-astra: サブスクリプションでベースの2.5倍
さらにgpt-6-astraはサブエージェントを頻繁に生成する傾向があり、しばしばgpt-5.6、5.3-codexなどあらゆるモデルを使う。これは素晴らしい。良いコーディネーターだが、コストはさらに増える。
そして、たった一つのテストが修正されたことを確認するためだけに、完全なテストスイートを何度も何度も実行する傾向がある（各回約15分かかる）。テストが修正されるまでそれを続け、最終的に2時間ほど蓄積する。
昨日、リポジトリの変更を最新のアップストリームの変更にリベースするタスクを割り当てた。gpt-5.6-solは一貫してエンドツーエンドで1時間ほどかかったが、astraは6時間以上実行してもまだ終わらなかった。頼んでいない金メッキの「もう一つ」を次々と見つけ続けた。