永遠のSloptember：なぜAIエージェントはソフトウェアエンジニアリングにおける最も高くつく間違いとなる可能性があるのか

ソフトウェア開発におけるAIエージェントの約束は、しばしば完全な生産性への飛躍として語られます。エンジニアが機能を説明するだけで、エージェントがそれを実装するという世界です。しかし、George Hotz (geohot) は、この軌道は前進ではなく、高くつく間違いであると主張しています。彼は、AIエージェントは実際には「プログラミング」をしているのではなく、プログラミングの分布を模倣する洗練された統計モデルであると断言しています。

この区別は極めて重要です。モデルがプログラミングを模倣するとき、出力は正しく見えます。構文は有効で、文法はプロフェッショナルですが、人間が検出することがますます困難になっている方法で根本的に壊れています。Hotz はこの現象を「slop（スロップ）」と呼び、生成されたコードの量が人間の検証能力をはるかに上回る「永遠のSloptember」に突入していると警告しています。

進歩の錯覚

多くの人々にとって、AIエージェントとの最初の体験は陶酔的なものです。ボイラープレートやプロトタイプを、ありえないほどのスピードで粉砕し、即座に前進している感覚を与えてくれます。しかし、Hotz が観察しているように、この進歩は前倒しされています。初期構造が整った後は、プロセスがしばしば「スロットマシン」へと退化します。開発者は、エージェントが最終的にプロダクション級のソフトウェアに必要な磨き上げと正確性を実現してくれることを期待して、レバーを引く（プロンプトを再入力する）ことになります。

これは危険なパラドックスを生み出します。ツールは、数日かかったであろうプロトタイプを数分で構築できるほど高速ですが、品質の最後の5%に到達することに苦戦します。つまり、安定性、エッジケース、および長期的な保守性が存在する部分です。

組織的リスク：ハイパフォーマー vs. 平均的な層

この議論の中で最も刺激的な主張の一つは、AIエージェントが個人や小規模で高パフォーマンスなチームよりも、大規模な組織に大きな害を与えるというものです。その理由は、エラー修正のフィードバックループにあります。

High Performers: 通常、強力なエラー修正能力を持っています。彼らはAIを外骨格（exoskeleton）として扱います。つまり、意図を加速させるためのツールであり、批判的思考を代替するものではないと考えています。彼らはエージェントが生成するコードの全行を読み、理解します。
Large Organizations: 多くの場合、フィードバックループが遅く、アライメント（整合性）が低くなります。このような環境では、パフォーマンスの低い層が、必要な自己チェックなしに、エージェントを使用して10倍の量のコードを生成してしまう可能性があります。

その結果、組織の平均的な出力は「slop」へとシフトする可能性があります。下位層が、もっともらしく見えるが脆弱なコードを大量に生成すると、たとえ「生産性」指標（コード行数や機能の速度）が上昇しているように見えても、組織全体の技術的負債が指数関数的に増大します。

「正しい問題」と「センス（Taste）」の侵食

技術的なバグを超えて、より深いアーキテクチャ上のリスクがあります。コミュニティの議論で繰り返し現れるテーマは、「正しい問題を解決する」という概念です。

解決すべき正しい問題を特定する能力こそが、トップレベルのシニアエンジニアを分かつものだ... AIエージェントは、間違った問題のデザインによる摩擦を覆い隠してしまいます。それらはそれを修復するのではなく、単にそのコストを先送りにしているだけなのです。

従来のエンジニアリングでは、不適切な設計の選択は開発を遅らせる摩擦を生み出し、設計を見直すべきであるという自然な信号として機能します。AIエージェントはこの摩擦を取り除いてしまいます。彼らは、設計が欠陥していることに開発者が気づかないうちに、非常に効率的に悪い設計を実装してしまうため、システムが破滅的な規模に達したときに初めて問題が露呈します。これは、設計の選択の結果に苦しむことがないため、エンジニアの世代が健全なアーキテクチャに対する「センス（taste）」や本能を育むことができなくなるリスクを孕んでいます。

反論：「10x」のギャップとドメインの特異性

誰もがこの悲観的な見通しに同意しているわけではありません。多くの開発者は、AIの有用性はユーザーのスキルレベルとタスクのドメインに完全に依存すると主張しています。

Bridging the Gap: 「10x」の達人ではないエンジニアにとって、エージェントはギャップを埋めることができます。例えば、Debian package caching proxy のような複雑なシステムを、時間の制約がある中で実装することが可能になります。
Domain Variance: 低レベルのシステムプログラミング（USB reverse engineering のようなもの）と、高レベルのアプリケーション開発（Node.js CRUD apps のようなもの）の間には、大きな違いがあります。パターンが非常に反復的でボイラープレートが多い後者では、AIエージェントはしばしばかけがえのないものと見されています。
The Review Process: 問題はAIではなく、規律（discipline）の欠如であると主張する人もいます。チームが厳格な diff レビューを diff レビューを厳格に維持し、各エージェント・セッションの範囲を厳格に定義すれば、コードベースの品質は、誰（あるいは何）が最初のコードを書いたかに関わらず、安定した状態をままにします。

結論：プロセスが重要である

結局のところ、議論の焦点は、プログラミングが統計的な演習なのか、それとも推論のプロセスなのかという点にあります。もしプログラミングが単なるトークンの分布であるならば、LLM はほぼそこに到達しています。しかし、もしプログラミングが「世界モデル（world model）」を必要とするならば、つまり、物理的または論理的な環境においてシステムがどのように振る舞うかを理解することであれば、現在の RL-based モデルは根本的に限界があります。

AI支援開発の時代がさらに進むにつれ、真の課題は、モデルの能力ではなく、それを使う人間の規律（discipline）です。目標は、「AI psychosis（AI精神病）」を回避することです。つまり、速度への欲求が理解の必要性を上回り、偶然によって動作し、設計によって壊れるソフトウェアの世界へと向かうことを防ぐことです。