原文のタイトル：Thoughts on slowing the fuck down
原著者：Mario Zechner
翻訳：Peggy，BlockBeats

編者のコメント：生成 AI がソフトウェアエンジニアリングに加速的に導入される中、業界の気分は「能力に驚嘆する」から「効率の焦燥」に移行しています。速く書かないと、多用しないと、自動化が不完全だと、自分が淘汰されるようなプレッシャーを感じてしまうようです。しかし、コーディング Agent が実際のプロダクション環境に本格的に導入されると、より現実的な問題が浮かび上がってきます：エラーが拡大し、複雑性が制御不能になり、システムが理解不能になるにつれ、効率の向上は品質の向上に比例していないことが明らかになります。

この記事はフロントラインの実践に基づいて、「エージェンティック・コーディング」というトレンドについて冷静に考察しています。著者は、Agent は人間のようにエラーから学習しないことを指摘し、ボトルネックやフィードバックメカニズムの欠如により、小さな問題が急速に拡大されることを強調しています。さらに、複雑なコードベースでは、Agent の局所的な視点と限られたリコール能力が、システム構造の混乱をさらに悪化させています。これらの問題の本質は、技術そのものではなく、焦燥に駆られた人間が判断力と制御を早すぎる段階で放棄してしまうことにあります。

そのため、「AI を完全に採用すべきか」に陥るよりも、人間とツールの関係を再調整することが重要です：Agent には局所的で制御可能なタスクを担当させ、システムの設計や品質管理、重要な意思決定を自らの手で堅実に行うべきです。このプロセスで、「スローダウン」はむしろ一種の能力となります。これは、まだシステムを理解し、選択肢を作り出すことができ、仕事をコントロールする能力を持ち続けていることを意味します。

ツールが絶えず進化する時代において、真に希少なのは、より速い生成能力ではなく、複雑性の判断力、効率と品質の間で選択を行う覚悟かもしれません。

以下は原文です：

その亀の顔、それが私がこの業界を見るときの表情です

およそ1年前、本当に「プロジェクト全体を最初から最後までやり遂げることができるコーディング Agent」が登場し始めました。以前から 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（No Good Move Intended）」です。

あなたは絶え間ない「無限ループ」の中で自己消費しています。

見てください——Anthropic はエージェントの集団を使用して C コンパイラを作成しました。現時点では問題がありますが、次世代のモデルでは修正されるでしょうね？

そして見てください——Cursor は大量のエージェントを使用してブラウザを作成しました。現時点ではほぼ使用不可能であり、定期的な手動介入が必要ですが、次世代のモデルはきっと解決できるはずですよね？

「分散」「分割統治」「自律システム」「暗黒工場」「ソフトウェア問題の解決に6ヶ月かかる」「SaaS は死にました、私のおばあちゃんは Claw を使って Shopify を構築しました」......

これらの物語はとても面白いものです。

もちろん、この方法は、あなた自身を含め、ほぼ誰もが使用しない側のプロジェクトにとっては、おそらくまだ機能します。恐らく、本当に誰かがこの方法で、クソでなく、本当に誰かに使用されるソフトウェア製品を作成することができる天才が存在するかもしれません。もしあなたがその人なら、私は本当に尊敬します。

しかし、少なくとも私の周りの開発者コミュニティでは、この方法が本当に効果的なケースをまだ見たことがありません。もちろん、私たちが皆未熟過ぎるだけかもしれません。

学習不足、ボトルネックの不在、遅れた爆発によるエラーの積み重ね

エージェントの問題は：彼らは間違いを comit します。これ自体は問題ありません。人間も間違いを comit します。それはおそらく正確性のエラーであり、それは認識しやすく修正しやすく、追加の回帰テストでより安定します。それはおそらく、そこで無駄なメソッドとここで不合理な型、そして繰り返しコードのようなものです。これらは個別に見ても大したことはありません。人間の開発者も同様の小さなエラーを comit します。

しかし、「機械」は人間ではありません。人間は同じエラーを繰り返した後、通常そのエラーを犯さないように学びます。それは彼らが怒られて目が覚めたり、本当の学習プロセスでそれを変更したりするかもしれません。

しかし、エージェントにはその学習能力がありません。少なくともデフォルトではありません。それは同じエラーを何度も繰り返し、トレーニングデータに基づいてさまざまなエラーの素晴らしい組み合わせを「作成」するかもしれません。

もちろん、あなたはそれを「トレーニング」しようとすることができます： AGENTS.md にルールを記述して、そのようなエラーを犯さないようにします。過去のエラーやベストプラクティスへのクエリを可能にする複雑なメモリシステムを設計します。特定の問題に対してこれは確かに効果的です。ただし、前提条件は、まずそのエラーが発生したことを観察する必要があるということです。

より重要な違いは次のとおりです：人間がボトルネックであり、Agent がそうでないことです。

人間は数時間で2万行のコードを吐き出すことは不可能です。たとえエラー頻度が低くても、1日に導入できるエラーの数には限界があり、これらのエラーの累積は遅いものです。通常、いわゆる「エラーから生じる苦痛」が一定レベルに達したとき、人間は（苦痛を嫌悪する本能から）修正のために停止する傾向があります。または人が交代し、別の人が修正するために入ってきます。要するに、問題は対処されます。

しかし、整理された一連の Agent「アーミー」を使用すると、ボトルネックや「苦痛」はありません。本来は些細な小さなエラーが持続不能な速度で積み重ねられます。あなたは既にループから外されており、これらの取るに足らないように見える小さな問題が巨大なものに成長していることに気付いていません。本当の苦痛を感じるとき、時すでに遅しのことがほとんどです。

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

この時、コードのこのセットを信頼できなくなったことに気付きます。

さらに悪いことに、Agent が生成した何千ものユニットテスト、スナップショットテスト、エンドツーエンドテストすらも信頼できなくなりました。システムが正常に動作しているかどうかを判断するための唯一の手段は、手動テストだけになってしまいました。

おめでとうございます、自ら（および会社）を深刻な窮地に陥れました。

複雑性のディーラー

もはやシステムが何をしているのか完全に把握していません。なぜなら、Agent に制御権を託したからです。そして Agent は本質的に「複雑性を売る人」です。彼らは訓練データの中で多くの悪いアーキテクチャの意思決定を目にし、強化学習プロセスでこれらのパターンを強化し続けます。システムの設計を Agent に任せると、結果は容易に想像できます。

最終的に得られるものは、極めて複雑なシステムであり、さまざまな「業界のベストプラクティス」の拙劣な模倣が混在し、問題がコントロール不可能になる前に何も制約を加えなかったということです。

しかし、問題はここに留まりません。Agent は互いの実行プロセスを共有せず、完全なコードベースを見ることもできず、過去にあなたや他の Agent が行った決定を理解していません。そのため、彼らの意思決定は常に「局所的」です。

これは前述の問題に直結しています：大量の重複コード、抽象的な構造、不整合の数々。これらの問題が積み重なり、最終的には取り返しのつかない複雑なシステムが形成されるのです。

これは実際、人間が作成したエンタープライズ向けコードベースと非常に似ています。ただし、その種の複雑さは通常、数年にわたる蓄積の結果です：苦労は多くの人々に分散され、誰もが「修正が必要」の臨界点に達しておらず、組織自体の忍耐力が非常に高いため、複雑さは組織と共に「共生進化」してきました。

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

エージェント検索のリコール率は非常に低い

あなたはエージェントに「残り物を片付ける」のを期待するかもしれません。コードを再構築したり最適化したりしてシステムをきれいにするのを手伝ってくれると考えているかもしれません。しかし問題は、それらがもはやそれを行うことができないことです。

コードベースが大きすぎ、複雑すぎるため、それらは常にローカルな領域しか見ることができません。これは単にコンテキストウィンドウが十分に大きくない、または長いコンテキストメカニズムが百万行のコードの前で機能しなくなったからというだけの単純な問題ではありません。問題はより隠れています。

エージェントがシステムを修復しようとする前に、修正が必要なすべてのコードと再利用できる既存の実装を見つける必要があります。このステップを、私たちはエージェント検索と呼んでいます。

エージェントがこの作業をどのように行うかは、それに与えられるツールに左右されます：Bash + ripgrepであるかもしれませんし、クエリ可能なコードインデックス、LSPサービス、ベクトルデータベースであるかもしれません……

しかし、どのツールを使用しても、本質は同じです：コードベースが大きいほど、リコール率が低くなります。そしてリコール率の低さは次のようを意味します：エージェントはすべての関連するコードを見つけることができないため、適切な修正を行うこともできません。

これが初めに「コードのにおい」の小さなエラーが発生する理由でもあります。それには既存の実装を見つけられなかったため、重複した実装が行われ、一貫性が損なわれます。最終的に、これらの問題は絶えず拡散し、重なり合い、非常に複雑な「腐った花」を咲かせます。

それでは、これらすべてを避けるにはどうすればよいでしょうか？

（少なくとも現時点での）エージェントとの協力方法

エージェントのコーディングは、まるで海の妖怪のようで、非常に速いコード生成速度とその種の「断続的でありながら時折驚くような」知性であなたを引き込んでいきます。彼らはしばしば驚異的なスピードと高品質でいくつかの単純なタスクを遂行することができます。本当の問題が始まるのは、あなたがそのような考えを持つ時です。「このものは強すぎる、コンピュータよ、私の代わりに仕事をしてくれ！」

タスクをエージェントに委ねること自体にはもちろん問題はありません。良いエージェントのタスクには通常、いくつかの特徴があります：範囲を十分に限定でき、システム全体を理解する必要はありません；タスクは閉ループであり、すなわちエージェントが結果を自己評価できます；出力が主要パスではなく、一時的なツールや内部利用のソフトウェアであり、実際のユーザーや収益に影響を与えるものではありません；または、あなたが考えを補助するために「ゴム製のアヒル」が必要な場合——本質的には、あなたの考えを取ってインターネットの圧縮された知識や合成データと衝突させるものです。

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

たとえば、Andrej Karpathy が提唱する自動研究法を使用してアプリケーションの起動時間を最適化する？素晴らしいです。しかし、そのコードがいかなる生産性も持たないことを理解しておく必要があります。自動研究法が効果的なのは、評価関数を与えることで、特定の指標（例: 起動時間や損失）を最適化できるようになるからです。しかし、この評価関数は非常に狭い次元しかカバーしていません。エージェントは、評価関数に含まれていない指標、例えばコードの品質、システムの複雑さ、場合によっては正確性さえも無視するでしょう —— もしあなたの評価関数自体に問題がある場合は。

基本的な考え方は非常に単純です: エージェントに、退屈なことや新しいことを学べないこと、または普段試す時間がない探索的な作業を行わせる。結果を評価し、真に合理的で正しい部分を選択し、最終的な実装を完了します。もちろん、最後のステップもエージェントに手伝ってもらうことができます。

ただし、私が強調したいのは、本当にもう少しゆっくりすることです。

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

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

最終的には、維持可能なシステムが手に入ります — 少なくとも、エージェントが登場する前よりは悪化しません。はい、過去のシステムにも問題がありました。しかし、ユーザーはあなたに感謝するでしょう。なぜなら、あなたの製品は「使いやすい」ものであり、ただのゴミを吐き出すだけの製品ではないからです。

あなたが行う機能は少なくなりますが、より正確になります。断ることを学ぶこと自体が一つの能力です。安心して眠ることができます。なぜなら、システムが何をしているのかを理解しており、まだ主導権を握っているからです。この理解により、エージェンティックサーチの召回問題を補完し、エージェントの出力を信頼性が高く、修正が少なくなるようにすることができます。

システムに問題が発生した場合、自ら現場に赴いて修復できる；最初から設計が不合理だった場合、問題を理解し、より良い形に再構築できるでしょう。エージェントがいるかどうかは実際にはそれほど重要ではありません。

すべてには規律が必要です。すべては人に依存しています。

[Original Article]

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

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