Phodal Huang が中国語で書いたこの記事は、ソフトウェア開発に対する AI の効果が通常どのように論じられているかについての観察から始まる。それは個人の生産性、つまり機能がどれだけ速く作られるか、1 人の開発者がいくつのタスクを進められるか、コーディングエージェントがどれだけのコードを生成するか、という観点での議論である。著者は、AI が実行のコストを大きく下げたことは認めつつも、開発者が速くなってもチームがそれに比例して速くなるわけではないと論じる。コード、プルリクエスト、テストはいずれも増えるが、要求が出されてからユーザーが価値を受け取るまでの時間はそれに比例して短くはならない。要求、設計、レビュー、マージ、テスト、リリースが依然として順番待ちになるからである。
著者の主張は、AI はソフトウェア開発を生産能力の問題から流動能力の問題へと移しつつある、というものである。コード生成の限界費用が下がると、チームを制約するのは、要求、設計、検証、フィードバックがシステム全体を釣り合った速度で流れていけるかどうかになる。
要点
- 著者は、AI は種類の異なる仕事を非常に不均一に加速すると論じる。AI はテキスト、コード、ページ、テストの骨組みを生成するのは得意だが、顧客インタビュー、組織の意思決定、ビジネス上のトレードオフ、ユーザーによる検証、チーム間の調整を同じ程度に速めることはできない。
- 著者は、プロダクトの仕事を制約しているのは文書の作成ではなく意思決定だと論じる。開発者とエージェントは、準備のできたタスクを今や数時間のうちに消化でき、それはチームが検証済みの意思決定を生み出す速度よりも速い。そして、プロダクトマネージャーが使う AI は、安全に作ってよい要求を増やすことなく、より多くの要求や仮説を追加しうる。
- 著者は、デザインの仕事を制約しているのは描画の速さではなく経験に基づく判断だと論じる。開発者とエージェントが待つのを避けるために、欠けているデザイン上の決定を既存のコンポーネントから補うと、それらの決定はエージェントやブランチにばらばらに散らばり、デザイナーは後からそれらをレビューして手戻りとして修正しなければならなくなる。
- 著者の説明では、開発は上流の飢餓（成熟した要求とデザインの不足）と下流の渋滞（生成されたコードがレビュー、マージ、テストの順番待ちになること）に同時に陥りうる。著者はこれを仮想的な倍率、すなわち要求の意思決定が 1.2 倍、デザインが 1.5 倍、コードの生産が 5 倍、レビューとテストが 1.3 倍という数字で示し、開発を、入口の車が少なすぎ、出口が交通をさばききれない、突然拡幅された高速道路にたとえている。
- 著者は、局所的な高速化がどのようにシステム全体の手戻りに変わるかを説明する。エージェントは曖昧な要求を、もっともらしい解釈を 1 つ選んでコードに固定することで解決してしまう。著者の挙げる「管理者はメンバー一覧をエクスポートできる」という例では、フロントエンド、バックエンド、テストの各エージェントが、それぞれ局所的には妥当だが互いに異なる決定を下しうる。
- 著者は、並列開発が増えるとマージと所有権のコストが Git のコンフリクトを超えて上昇すると論じる。エージェントは隣り合うモジュールに異なる抽象化、命名、エラー処理を持ち込みうるからであり、レビュアーが最終的な差分しか見ない場合、コードレビューはコンテキストの復元作業になる。
- 著者は、テストが増えても検証能力が増すわけではないと論じる。実装から生成されたテストは、システムが正しいビジネス上の振る舞いを実装していることよりも、コードが書かれたとおりに動くことを示しがちだからである。
- 著者は、変更の流れを最適化するための 4 つの実践を提案している。多くのコードが生産される前に、最小限の決定（ビジネス上の意味、中核となる経路、リスクの境界、完了条件）を形成すること。開発能力を、より大きな要求やプルリクエストではなく小さなバッチで吸収すること。コードとともに、コンテキストと証拠（目標、主要な前提、影響範囲、検証結果、残っている未知の事項）を届けること。そして、バックプレッシャーを使って並列度を制御し、レビュー、テスト、統合が飽和しているときには、同時に進める新機能を減らすか、エージェントを検証やコンテキストの作業に振り向けることである。
背景
この記事は測定結果の報告ではなく、著者自身の視点からの主張である。役割ごとに示された倍率は例示的なものである。生成されたコードがレビューで順番待ちになるという記述は、このウィキで レビューのボトルネック と呼んでいるものと重なる。著者は最後に、AI ネイティブなチームの競争力は、一度にいくつのエージェントを起動できるかではなく、どれだけの変更を、待ち、衝突、手戻りを少なく抑えながら、未確認のアイデアからユーザーが実感できる価値へと動かせるかにある、と論じている。