ボトルネックは移動した：エージェントがコードを書くとき、テックチームはどう速くあり続けるか
コーディングはもはや遅いステップではなくなった。4つの最近のトークを通じて、同じパターンが現れる：エージェントは変更を素早く起草でき、チームはその後品質、レビュー、信頼、検証で停滞する。
これは会社全体を自動化するのと同じ議論でも、1つのコーディング製品内の単一の検証ループでもない。エージェントがすでにほとんどのdiffを書いているときに、チームがどう速くあり続けるかについてだ。
時間が実際にどこに行くか
無人のエージェントは時間とともにコードベースを悪化させる。 Dexter HorthyはBeyond Codingで、そして再びAgentic AI Foundationで、SlopCodeBenchを歩く：モデルはgreenfieldアプリを得て、それから機能のシーケンスを得て、問題全体を事前に与えられない。失敗するテストが上がる。最良のモデルでもまだ十代半ばのスコアだ。彼の警告は実用的だ：来年のモデルがそれをきれいにする希望にコードベースを抵当に入れるな。2-4倍を目指せ、100倍ではない。並行してやることを減らし、アーキテクチャを変えるものには研究-設計-計画ループに人間を残せ。
レビュープロセスはしばしばモデルより遅い。 AmpのDario HamidiもBeyond Codingで、チームは1日約50回本番に出荷し、それを可能にする変更はエージェントではないと言う。プルリクエストとフィーチャーブランチをやめることだ。彼は、AIを使っていないチームでも、trunkにマージすることで二桁の生産性を拾えると主張する。なぜなら人々は見知らぬ人のために作られたキューで待つ代わりに自分の仕事をチェックするからだ。対応する制約は信頼だ：エージェントが「ナイフをジャグリング」できない環境を構築し、短命の資格情報と実際に承認する権限を使う。
検証は生成にスケールしない。 IBMのPrompt to Productionは新しいボトルネックを一文で置く：AIスケールでの人間の検証。計画、影響、証拠は最初のコード行より重要だ。なぜなら本当の変更はテスト、設定、パイプライン、モニタリングにも触れるからだ。関連するIBMのIDE vs CLIの記事はツールチェーン側から同じ点を述べる：摩擦はコードを打つことではなく、コードの周りの仕事を調整することだ。
仕様と評価がチームのインターフェースだ。 Guillermo RauchはDavid Ondrejのインタビューで、多くのモデルを試し、個人と会社の評価、短い指示からアプリをレビューしたり関数を出荷したりできるエージェントに基づくエージェント的ワークフローを記述する。チームにとって有用な部分は有名人のセットアップではない。それは共有評価で、「今週どのモデル」が私的な議論にならないようにすることだ。
月曜日に何を変えるか
- 仕事を分割する。小さく可逆的な変更はバックグラウンドエージェントに行ける。抽象を変えるものは人間との研究-設計-計画パスに留める。
- トークンや並列エージェントで速度を測るのをやめろ。インシデントを起こさなかったデプロイを測り、1つの優先事項を飛行中に保て。
- レビューを左に動かせ。自動チェックと信頼できる環境は長いPRキューに勝る。プルリクエストをやめるなら、何がそれに取って代わるかを言え：trunk、テスト、そしてまだdiffを読む誰か。
- エージェントが見られる反スロップ規則を書け：マージしないパターン、そしてユーザーフィードバックが工場に再入る場所。
- 検証を希少資源として扱え。エージェントに実装を求める前に証拠（テスト、フラグ、短い手動チェック）を計画せよ。
速くなるチームは、夜間に最も多くのエージェントを走らせているチームではない。ボトルネックが移動したことに気づき、そのステップに人員を配置したチームだ。