- 最近、AIコーディングエージェントの普及によって開発速度は上がったが、ソフトウェア品質の低下と不安定性が深刻化している
- エージェントは反復学習能力なしに同じエラーを蓄積し、大規模コードベースでは検索再現率の低下と複雑性の爆発が起きる
- 人間の統制なしにシステム全体を任せると、重複コード、誤った設計パターン、保守不可能なコードベースにつながる
- 現時点では、エージェントは非中核タスクや実験的な領域に限定して活用し、人間が最終的な品質ゲートであり続けるべきだ
- 速度を落とし、人間の主体性を取り戻すことが、学習、成長、そして持続可能なソフトウェア生態系のための核心である
すべてが壊れた状態
- この1年でコーディングエージェントは実際のプロジェクトを完成させられる水準まで進化したが、その結果としてソフトウェア品質の低下が目立っている
- 大規模サービスでも98%の稼働率が一般化し、UIバグが頻繁に発生
- AWSのAI関連障害事例や、MicrosoftのAIコード比率の増加に関する発言などが言及されている
- 一部企業は製品コードの100%をAIが作成すると主張しているが、成果物はメモリリーク、UIエラー、機能の不安定さなどで品質が低い
- 多くの開発者が、エージェント中心の開発によってコードレビューの欠如、設計不足、不必要な機能の過剰などから保守不可能なコードベースに陥ったと報告している
エージェントと一緒に働いてはいけないやり方
- 開発者は速度とコード量に中毒し、品質と統制権を手放した状態にある
- 「分散・自律・自動化」を掲げて大規模エージェントオーケストレーションを試みるが、実際には不安定な成果物を量産している
- 一部のプロジェクトはまともに動かすことさえ難しく、人間の介入なしには維持できない
- 個人プロジェクトの規模では可能かもしれないが、実際のユーザー基盤を持つ製品では失敗事例がほとんどである
-
エラーの蓄積と学習の欠如、ボトルネックなし、遅れてくる痛み
- エージェントには反復学習能力がなく、同じエラーを繰り返し発生させる
- 人間はエラーから学ぶが、エージェントは同じミスを無限に繰り返す
- 人間はコードを書く速度に限界があるためエラーの蓄積は遅いが、エージェントの群れにはボトルネックがなく、エラーが爆発的に蓄積する
- その結果、コードベースは信頼できなくなり、自動テストさえ信じられなくなる
- 最終的には手動テストだけが唯一の検証手段となり、開発チームは自らを罠にはめることになる
-
複雑性を学習した商人たち
- エージェントはシステム全体の文脈を見ないまま局所的な判断しか下さない
- その結果、重複コード、不要な抽象化、構造的混乱が急速に蓄積する
- 人間の組織ではこうした複雑性は数年かけてゆっくり蓄積するが、エージェント中心のチームは数週間で同じ水準の混乱に達する
- エージェントは訓練データから学んだ誤った設計パターンをそのまま再現し、人間の統制がなければ回復不能な複雑性を生み出す
-
エージェント検索の低い再現率
- エージェントがコード修正やリファクタリングを試みる際、必要なコード全体を見つけられない
- コードベースが大きくなるほど検索再現率(recall) は急激に低下し、重複と不整合が発生する
- Bash、LSP、ベクタDBなどさまざまなツールを使っても、大規模コードベースでは限界がある
- これによりコードの悪臭と不要な複雑性がさらに深刻化する
エージェントと一緒に働くべきやり方（現時点では）
- エージェントは高速なコード生成と高い初期品質によって魅力的だが、システム全体を任せると崩壊する
- 適切なユースケースは、小さな範囲の非中核タスク、自己評価ループが可能なタスク、失敗しても致命的ではないタスクである
- たとえば、社内ツールの作成、アイデアの実験、性能測定ベースの自動化研究(auto-research) などが適している
- 人間は必ず最終的な品質ゲートであり続け、エージェントの結果をレビュー・修正・統合しなければならない
- 評価関数が狭い指標しか反映しない場合、エージェントはコード品質・複雑性・正確性を無視する可能性がある
- 速度を落とすことが重要
- 何を、なぜ作るのかを考える時間を確保し、不必要な機能をきっぱり断るべきだ
- 1日にエージェントが生成できるコード量をレビュー可能な水準に制限する
- アーキテクチャ・APIなどシステムの本質的な形は、必ず人が直接書く
- エージェントとペアプログラミングを行い、コード作成の過程で摩擦と理解の機会を確保する
- このようなアプローチは保守可能なコードベースを作り、ユーザー満足度を高め、不要な機能ではなく中核機能に集中できるようにする
- 人間の理解が残っていればエージェント検索の再現率の問題も緩和され、問題が起きても直接修正可能になる
- 初期設計が誤っていても、理由を理解し改善できる能力が維持される
- 結局必要なのは規律と人間の主体性である
- システムの品質と持続可能性は人間の介入と判断にかかっている
- 「ゆっくり進むこと」こそが、学習と成長、そして健全なソフトウェア生態系を維持する唯一の道である
2件のコメント
Pi – 簡潔なターミナルコーディングハーネス
これを作った人なんですね
Hacker Newsの意見
最近こういう 思索的な文章 を読むたびに、自分もある時点で疲れ切ってしまったように感じる
結局重要なのは「何を作っているのか」と「その道具が本当に役に立つのか」だ
Ruby、PHP、Lotus Notes、Visual BASICの時代にも同じ過ちを繰り返していた
道具は賢く使い、チームが実際に作っている 複雑な現実 を理解できるだけの速度で働くべきだ
アジャイルかウォーターフォールか、DockerかPodmanかといったことは本質ではない
今はLLMが本番DBを消し、そのポストモーテムブログに図まで描いてくれる時代だが、それが本当のエンジニアリングなのかは分からない
もしかするとソフトウェア開発は、そもそも 工学的な学問 ではなかったのかもしれない
この10年間、ソフトウェア業界は メタ作業 であふれていた — 新しいフレームワーク、ツール、仮想化レイヤー、組織構造など
だが肝心の「何のために」これを作るのかは曖昧だ
まるで ピラミッド型の構造 のように、業界を維持するために新しい仕事を生み出しているように感じる
それでも本物のエンジニアリングは存在する — 科学的に問いを立て、その答えで意思決定するときだ
逆に「勘」で仕事をしてCEOの言うことに従うだけなら、それはエンジニアリングではない
昔はバージョン管理すらないチームが多く、あってもひどいものだった
Joel Spolskyの Joel Test を見ると、当時のほとんどの会社は「いいえ」だった
橋は荷重、材料、寿命などを正確に計算するが、Webサイトはトラフィックすら予測しにくい
サーバーやフレームワークの 限界値 を定量的に扱う基準がない
いつかソフトウェアも本当のエンジニアリングになるかもしれないが、まだ道のりは長い
「エンジニア」という言葉を付けたのは、単にもっと金を稼ぐためだった気がする
本物のエンジニアは証明と検証を重視するが、私たちは新しいパターンや試みを楽しんでいる
だから「エンジニア」という言葉がむしろしっくりこない
「プログラミングを知らない人たちがプログラミングしようとするための方法論」だと批判していたが、今でもその通りに思える
最近は AIベースの開発プロセス が大企業中心に固まりつつあり、ベンダーロックイン が強まっている
コードベースがエージェント中心に変われば、結局そのエージェントだけがコードを理解するようになる
そうなれば価格は上がり、人間の開発者が戻るのも難しい 一方向の移行 になりかねない
楽観論者は「技術は常に安くなって良くなる」と言うが、石油市場のようになる可能性もある
昔DVDからストリーミングへ移行したときのように、私たちは同じ映画を二度買っているようなものだ
Claude Opus 4.6のようなモデルは今や 1分あたり1ドル 水準まで高くなっており、プロンプトエンジニアリングでももう補正できない
結局AIサービスも 低価格–中価格–プレミアム の階層構造に分かれつつある
プロンプトエンジニアリングは今やほとんど 巧妙な脱獄(jailbreaking) のような扱いだ
AI企業に知的労働の能力を「賃貸」するのは危険だ
「コストはもうこれ以上上がらない」という言葉は議論の終わりだ — 彼らはすでに サイコロを振った状態 なのだから
AI大手も同じ道をたどるだろう
結局私たちは トークン中毒者の市場 に閉じ込められるかもしれない
オープンソースの 見えざる手 が最終的にはすべてを無料にするだろう
ハードウェアとソフトウェアが進歩するにつれ、計算単価は着実に下がる
ブロックチェーンブームのように実利用のない技術は消えるが、AIには実際のユーザーがいる
Uberのように初期には批判されたサービスも、結局は 持続可能なビジネス として定着した
石油と違って、コンピューティングは毎年より安く、より速くなる
この文章の著者は Pi というオープンソースのコーディングエージェントフレームワークを作った人物だ
OpenClawでも使われている
彼の Pi関連のブログ記事 も参考になる
彼はLLMとエージェントを誰よりも深く扱ってきた人物だ
「AIが100%コードを書く」と主張する会社ほど ひどい製品 を出してくることが多い
昔のDOSやMacOSの時代には、そういうコードはシステム全体を落としてしまったので、品質の重要性がもっと高かった
今はOSが寛容になったので、雑なコード でも生き残れる
OTAアップデートのおかげで未完成の製品を簡単に出せるようになり、競合より早くリリースしようとする
ただ、私たちが覚えているのはよくできた少数の製品だけだ
今ではネットワーク接続さえあれば、OSですらゲームのように簡単に更新される
コーディングエージェントは 「人を惑わすセイレーン」 のようだ
最初は速くて賢く見えるが、「コンピュータよ、自分の仕事を代わりにやってくれ」と考えた瞬間に崩れる
しかしこれは一時的なものだ — AIは 測定可能な領域 ではすでに人間を上回っている
本当の問題は HCI(人間–コンピュータ相互作用) だ
人間の価値観に合うインターフェースを設計することが、これからの核心課題になる
今は AI過熱期 の頂点だ
昔MongoDBやNoSQLが「SQLは死んだ」と叫んでいた時代のように、結局人々は再び 現実的な均衡点 へ戻っていくだろう
NoSQLは消えなかったが、今では必要な場所でだけ使われている
「最近のソフトウェアは壊れやすいぐちゃぐちゃだ」という言葉には共感するが、実は ソフトウェア自体は変わっていない
昔は信頼がなかったので人が直接確認しており、その遅さが問題を減らしていただけだ
DevOpsの核心は 信頼を土台に素早く動きつつ、品質を維持すること だ
Toyotaの Andonコード のように、問題を見つけたらすぐ止まり、根本原因を解決しなければならない
これは技術の問題ではなく 文化とプロセスの問題 だ
間違ったインターフェースやビジネス文脈の不一致を早期に見つけるべきだ
みながGitHub、AWS、Cloudflareを使っているので、一か所が止まると世界中が止まる
テープアウト直前にバグが見つかったら、メッセンジャーを責めずに 慎重に判断する
プログラミングの産出物はコードだけでなく プログラマー自身 でもある
コードを書きながら積み上がる メンタルモデルと筋肉記憶 が本当の資産だ
AIがこの過程を置き換えると、最終的に プログラマーの成長 が失われる
Jonathan Blowの "Preventing the Collapse of Civilization" でも同じ問題を扱っている
"Programming as Theory Building" を参照
昨日、同僚と似たような話をした
AIがログを読み、バグを直し、ポストモーテムまで書くデモを見たのだが、
問題は 人間がその過程を内面化する時間がないこと だ
「車はブレーキがあるから速く走れる」という言葉のように、
人間が理解できる速度で 学習の摩擦 を維持する必要がある
もしエージェントが自ら認識して復旧するなら、人間が学ぶ必要はあるのだろうか？
もちろん根本原因を見落とすかもしれないが、自律復旧システム が十分に堅牢なら、それは問題なのだろうか？
プロダクトデザインの観点からも似た問題を感じる
開発速度が速すぎて、実際に使って検証する時間 がない
間違ったデザインの上に機能を積み上げていくと、後戻りが難しくなる
結局重要なのは 速度ではなく、品質と学習のバランス だ
こうした過程には必ず 時間が必要だ