原文标题：思考放慢速度
原文作者：Mario Zechner
编译：Peggy，BlockBeats

編者按：生成式 AI がソフトウェアエンジニアリングに加速的に進入する今、業界の感情は「能力驚嘆」から「効率不安」へと移行しています。書くのが遅い、使うのが少ない、自動化が不十分であると、淘汰されるプレッシャーを感じるようです。しかし、コーディングエージェントが本当に生産環境に入ると、より現実的な問題が浮上します：エラーが拡大し、複雑性が制御不能になり、システムが徐々に理解不能になり、効率の向上は質の向上に等比例に変換されていません。

この記事は、最前線の実践に基づいて、この「エージェンティックコーディング」の熱潮を冷静に反省しています。著者は、エージェントは人間のようにエラーから学ばないこと、ボトルネックとフィードバックメカニズムが欠如している場合、小さな問題が迅速に拡大することを指摘しています。また、複雑なコードベースでは、その局所的な視点と限られたリコール能力がシステム構造の混乱をさらに悪化させます。これらの問題の本質は技術自体にはなく、不安に駆動されて人間が判断と制御を早々に手放してしまうことにあります。

したがって、「AIを全面的に受け入れなければならないのか」という不安に陥るよりも、人とツールの関係を再調整する方が良いでしょう：エージェントに局所的で制御可能なタスクを負わせ、システム設計、品質管理、重要な決定はしっかりと自分の手中に持つことです。このプロセスで「ゆっくりする」ことがむしろ一つの能力となり、それはあなたがシステムを理解し、選択を行うことができ、仕事に対するコントロール感を持ち続けていることを意味します。

ツールが進化し続ける時代において、実際に希少なのは、より速い生成能力ではなく、複雑性に対する判断力、そして効率と品質の間で選択を行う冷静さかもしれません。

以下は原文です：

カメの顔が、私がこの業界を見るときの表情です

約1年前、「プロジェクトを最初から最後まで完結させる」ことができるコーディングエージェントが登場しました。それ以前にもAiderや初期のCursorのようなツールがありましたが、それらは「アシスタント」に近く、「エージェント」ではありませんでした。新世代のツールは非常に魅力的で、多くの人々が余暇の時間を使って、ずっとやりたかったが時間がなかったプロジェクトをすべて実現しました。

私自身はそれ自体には問題ないと思います。余暇の時間を使って何かをするのは本来楽しいことですし、ほとんどの場合、コードの品質や保守性を気にする必要もありません。これにより、新しい技術スタックを学ぶ道が開かれます。

クリスマス休暇中、AnthropicとOpenAIは「無料クレジット」をいくつか配布し、まるでスロットマシンのように人々を引き込んでいきました。多くの人にとって、これは「エージェントがコードを書く」という魔法を実際に体験する初めての機会でした。参加者は増え続けています。

現在、コーディングエージェントも生産コードベースに入ってきています。12ヶ月が経過し、私たちはこの「進歩」の結果を見始めています。以下は私の現在の見解です。

すべてが壊れてしまった

これらはほとんどが経験則ですが、現在のソフトウェアは確かに「いつ崩れてもおかしくない」という感覚を与えています。98%の可用性は例外から常態に変わりつつあり、大規模なサービスでさえ例外ではありません。ユーザーインターフェースには、QAチームが一目で見つけられるような様々な信じられないバグが満載です。

私は、この状況はエージェントの登場以前から存在していたことを認めます。しかし今、問題は明らかに加速しています。

私たちは社内の真実を見ているわけではありませんが、時折「AIによるAWSのダウン」という噂のように情報が漏れ出ることがあります。Amazon Web Servicesはその後すぐに「訂正」しましたが、続いて90日間の再編成計画を内部で開始しました。

Satya Nadella（Microsoft CEO）も最近、社内でAIが書いたコードが増えていることを強調しています。直接的な証拠はありませんが、確かにWindowsの品質が低下しているという感覚があります。実際、Microsoft自身が発表したブログのいくつかからも、彼らはこの点を暗に認めているようです。

「製品の100%がAIによって生成された」と主張する企業は、ほぼ常に想像できる最悪の製品を出力しています。誰かを攻撃するつもりはありませんが、GB単位のメモリリーク、UIの混乱、機能の欠如、頻繁なクラッシュなどは、彼らが思っている「品質の裏付け」ではなく、「エージェントにすべてを任せる」という正のデモンストレーションでもありません。

プライベートでは、大企業でも小チームでも、みんなが言っていることがあります：「彼らはすでに『エージェントによるコード作成』によって行き詰まっている」と。コードレビューがなく、設計決定をエージェントに委ね、必要のない機能を積み上げてしまった結果、終わりは良くないでしょう。

私たちはなぜエージェントをこう使うべきではないのか

私たちはほぼすべてのエンジニアリングの規律と主観的判断を放棄し、ある種の「依存的」な働き方に陥っています：目標は一つだけ——最短の時間で最も多くのコードを生成すること、結果については全く考慮していません。

あなたはオーケストレーション層を構築し、自動化エージェントの軍隊を指揮しています。Beadsをインストールしましたが、本質的にはそれがアンインストール不可能な「マルウェア」であることを全く知らないのです。ただ「みんながそうしている」とネット上で言われているからです。そうしないと「終わりだ」（ngmi）。

あなたは「入れ子式のループ」の中で自己消耗しています。

見てください——Anthropicは一群のエージェントを使ってCコンパイラを作りましたが、今は問題がありますが、次世代モデルは必ず修正できるでしょう、そうですよね？

もう一つ——Cursorは大量のエージェントを使ってブラウザを作りましたが、今はほとんど使えず、人が時々手動で介入する必要がありますが、次世代モデルは必ずうまくやれるでしょう、そうですよね？

「分散型」「分けて治める」「自治システム」「ブラックボックス工場」「六ヶ月でソフトウェア問題を解決」「SaaSは死んだ、私のおばあちゃんはClawを使ってShopifyを構築しました」……

これらの物語はとても魅力的に聞こえます。

もちろん、この方法はほとんど誰も使わない（あなた自身を含む）サイドプロジェクトには「まだ動く」かもしれません。もしかしたら、実際にこの方法でゴミではなく、誰かに実際に使われるソフトウェア製品を作れる天才がいるかもしれません。もしあなたがその人であるなら、心から感心します。

しかし、少なくとも私の周りの開発者の中では、この方法が本当に効果的なケースは見たことがありません。もちろん、単に私たちが未熟なだけかもしれません。

エラーが学習なし、ボトルネックなし、遅延で累積する

エージェントの問題は：彼らはエラーを犯すことです。これは本質的には問題ではありません。人間もエラーを犯します。正しさに関するエラーである可能性があり、容易に識別でき、修正も容易です。その後に回帰テストを追加すればさらに安定します。また、linterがキャッチできないコードの匂いがあることもあります：ここに使われていないメソッド、あそこに不合理な型、さらには重複したコードなどです。これらは個別に見れば無害であり、人間の開発者も同様の小さなエラーを犯します。

しかし「機械」は人間ではありません。人間は同じエラーを何度も繰り返すうちに、通常は再発を学びます——誰かに叱られたり、本当に学ぶプロセスの中で修正したりします。

しかし、エージェントにはそのような学習能力がありません。少なくともデフォルトではありません。彼らは同じエラーを何度も繰り返し、さらに訓練データに基づいて「異なるエラーの素晴らしい組み合わせ」を「創造」する可能性もあります。

当然、あなたは「訓練」しようとすることができます：AGENTS.mdにルールを書いて、彼らにこのエラーを犯さないようにさせる；歴史的なエラーやベストプラクティスを参照するための複雑な記憶システムを設計する。これは特定の問題タイプにおいて確かに効果的です。しかし前提は——あなたは彼らがそのエラーを犯したことを観察しなければなりません。

より重要な違いは：人間はボトルネックですが、エージェントはそうではありません。

人間は数時間で2万行のコードを吐き出すことは不可能です。エラーの頻度が高くても、一日に導入できるエラーの数は限られており、これらのエラーの蓄積は遅いです。通常、「エラーからの苦痛」が一定のレベルに蓄積されると、人間（本能的に苦痛を嫌うため）は立ち止まって修正します。あるいは、人が置き換えられて他の誰かが修正します。とにかく、問題は処理されます。

しかし、整然としたエージェントの「軍隊」を使うと、ボトルネックも「痛み」もありません。これらの本来は取るに足らない小さなエラーは、持続不可能な速度で累積されます。あなたはすでにサイクルから外れ、これらの見た目は無害な小さな問題が巨大な存在に成長していることすら知らないのです。実際に痛みを感じる時には、すでに手遅れです。

ある日、新しい機能を追加しようとすると、現在のシステムアーキテクチャ（本質的にエラーの蓄積）は修正を全くサポートできないことに気付きます。あるいは、ユーザーが最新のリリースに問題が発生し、データを失うことに対して狂ったように苦情を申し立て始めます。

この時、あなたはこのコードを信頼できなくなったことに気づきます。

さらに悪いことに、エージェントが生成した何千ものユニットテスト、スナップショットテスト、エンドツーエンドテストも同様に信頼できなくなります。「システムが正常に機能しているか」を判断できる唯一の方法は、手動テストだけです。

おめでとうございます、あなたは自分自身（そして会社）を非常に困難な状況に追い込んでしまいました。

複雑性の販売者

あなたはシステムで何が起こっているのか完全に理解できていません。なぜなら、制御をエージェントに渡してしまったからです。そしてエージェントは本質的に「複雑性を販売」しています。彼らは訓練データの中で多くの悪いアーキテクチャの決定を見てきており、強化学習の過程でそれらのパターンを強化しています。あなたがシステムの設計を彼らに任せると、結果は想像に難くありません。

最終的に得られるのは：非常に複雑なシステムの一式で、さまざまな「業界のベストプラクティス」の拙劣な模倣が混在しており、問題が制御不能になる前に制約を加えていません。

しかし、問題はそれだけではありません。あなたのエージェントは互いに実行プロセスを共有せず、完全なコードベースを見ず、あなたや他のエージェントが以前に行った決定を理解していません。したがって、彼らの決定は常に「局所的」です。

これが前述の問題を直接引き起こします：大量の重複コード、抽象のための抽象構造、さまざまな不整合。この問題は累積し、最終的には取り返しのつかない複雑なシステムを形成します。

これは実際に人間が書いた企業レベルのコードベースに非常に似ています。ただし、そのような複雑性は通常、何年もかけて蓄積された結果です：苦痛は多くの人に分散され、誰も「修正しなければならない」という臨界点に達しておらず、組織自体の耐性も非常に高いため、複雑性と組織が「共生進化」します。

しかし、人間とエージェントの組み合わせでは、このプロセスが大幅に加速されます。2人と多数のエージェントで、数週間でこの複雑度に達することができます。

エージェンティック検索のリコール率は非常に低い

あなたはエージェントに「残りの部分を片付けてもらい」、リファクタリング、最適化、システムをクリーンにする手助けを期待するかもしれません。しかし、問題は：彼らはもうそれを行うことができません。

コードベースがあまりにも大きく、複雑性があまりにも高いため、彼らは常に局所的な視点しか持っていません。これは単にコンテキストウィンドウが十分に大きくないとか、長いコンテキストメカニズムが百万行のコードの前で失敗するということではありません。問題はもっと隠れています。

エージェントがシステムを修正しようとする前に、彼らはまず修正が必要なすべてのコードを見つけ、再利用可能な既存の実装を見つける必要があります。このステップを私たちはエージェンティックサーチ（Agent検索）と呼びます。

エージェントがこれをどのように行うかは、あなたが与えるツールによります：Bash + ripgrep、クエリ可能なコードインデックス、LSPサービス、ベクトルデータベースなど。

しかし、どんなツールを使っても本質は同じです：コードベースが大きくなるほど、リコール率は低くなります。そしてリコール率が低いということは、エージェントがすべての関連コードを見つけられず、当然、正しい修正を行うこともできないということです。

これが最初に「コードの匂い」の小さなエラーが発生する理由でもあります。彼らは既存の実装を見つけられず、再び車輪を作り出し、不整合をもたらします。最終的に、これらの問題は拡散し、累積して非常に複雑な「腐った花」を咲かせます。

では、私たちはこれらすべてをどう避けるべきでしょうか？

私たちはエージェントとどのように協力すべきか（少なくとも今のところ）

コーディングエージェントは、非常に迅速なコード生成速度と「断続的だが時折驚くべき」知性であなたを引き込むセイレーンのようです。彼らは驚くべき速度で、高品質でいくつかの簡単なタスクを完了することができます。問題が本格的に発生するのは、あなたが「このものは強力だ、コンピュータ、私のために働いてくれ！」という考えを抱いたときです。

タスクをエージェントに任せること自体には問題はありません。良いエージェントタスクは通常いくつかの特徴を持っています：範囲が適切に限定でき、システム全体を理解する必要がない；タスクが閉じられており、つまりエージェントが結果を自己評価できる；出力が重要な経路でなく、一時的なツールや内部使用のソフトウェアであり、実際のユーザーや収益に影響を与えない；あるいは単にあなたが考えを助けるための「ゴムダック」が必要である——本質的にはあなたの考えをインターネットの圧縮された知識や合成データと衝突させることです。

これらの条件を満たす場合、それはエージェントに任せるべきタスクです。前提は、あなたが人間として最終的な品質管理者であることです。

たとえば、Andrej Karpathyが提案したauto-research方法を使ってアプリの起動時間を最適化しますか？素晴らしい。しかし、前提は、彼が吐き出すコードは生産に適用可能なものではないことを理解していることです。auto-researchが効果的なのは、あなたが評価関数を与え、それに基づいて特定の指標（たとえば、起動時間やloss）を最適化できるからです。しかしこの評価関数は非常に狭い次元しかカバーしていません。エージェントは評価関数に含まれていないすべての指標、たとえばコードの品質、システムの複雑性、さらには特定の状況では正確性さえも無視することができます——もしあなたの評価関数自体に問題があるなら。

核心的な考え方は非常にシンプルです：エージェントに退屈で、新しいことを学ばせないタスク、あるいは本来時間がなかった探究的な作業をやらせます。そして、あなたが結果を評価し、本当に合理的で正しい部分を選び出し、最終実装を完了させます。当然、最後のステップでもエージェントを使うことができます。

しかし、私が強調したいのは：本当に、少しゆっくりすべきです。

自分に時間を与えて、あなたが何をしているのか、なぜそれをしているのかを考えます。「いいえ」と言う機会を自分に与えます。「いいえ、これは必要ありません。」エージェントに明確な上限を設定します：毎日どれだけのコードを生成することが許可されるか、その量はあなたが実際にレビューできる能力に一致するべきです。システムの「全体的な形態」に関するすべての決定、アーキテクチャやAPIなどは、必ず自分自身で書くべきです。自動補完を使って「手書きのコードの感覚」を得ることもできますし、エージェントとペアプログラミングをすることもできますが、重要なのは：あなたがコードの中にいることです。

なぜなら、実際にコードを書くこと、あるいはそれが一歩一歩構築されるのを見ることは、そのプロセス自体が「摩擦感」をもたらすからです。この摩擦こそが、あなたが本当に何をしたいのか、システムがどのように機能しているのか、全体の「触感」がどうなるのかをより明確に理解させます。これこそが経験と「センス」が働く場面であり、まさにこれが現在の最先端のモデルが置き換えられないものです。ゆっくりし、少しの摩擦を受け入れることが、あなたの学びと成長の方法なのです。

最終的に得られるのは、依然としてメンテナンス可能なシステムです——少なくともエージェントが現れる前よりも悪くはありません。そうです、過去のシステムも完璧ではありません。しかし、あなたのユーザーはあなたに感謝するでしょう。なぜなら、あなたの製品は「使いやすい」からであり、一堆の手抜きのゴミではないからです。

あなたが作る機能は少なくなりますが、より正確です。「いいえ」と言えることを学ぶこと自体が、一つの能力です。あなたは安心して眠ることができます。なぜなら、少なくともシステムで何が起こっているのかを知っており、あなたが依然として主導権を握っているからです。この理解こそが、あなたがエージェンティックサーチのリコール問題を補うことを可能にし、エージェントの出力をより信頼できるものにし、修正を必要としなくなるのです。

システムに問題が発生したとき、あなたは自ら修正に入ることができます；設計が初めから不合理な場合、あなたは問題の所在を理解し、それをより良い形にリファクタリングすることができます。エージェントがいるかどうかは、実際にはそれほど重要ではありません。

すべては規律が必要です。すべては人なしには成り立ちません。

[原文リンク]

クリックして律動BlockBeatsが求人を募集中のポジションを確認

律動BlockBeats公式コミュニティに参加しませんか：

Telegram 受信グループ：https://t.me/theblockbeats

Telegram チャットグループ：https://t.me/BlockBeats_App

Twitter公式アカウント：https://twitter.com/BlockBeatsAsia