Agodaは最近、AIコーディングツールが個々の開発者の生産性を測定可能な形で向上させている一方で、プロジェクトレベルでのベロシティ向上は驚くほど限定的であるとする見解を発表した。なぜならコーディングがこれまで本当のボトルネックではなかったからである。同記事はこれらの領域が人的判断を必要とするため、ボトルネックは上流工程の仕様策定や検証へシフトしたと主張している。この変化はエンジニアリングチームの構成方法に重大な示唆を与える。
Agodaのソフトウェアエンジニア Leonardo Stern氏は、この状況をFred Brooks氏が数十年前に「No Silver Bullet」で提示した「開発ライフサイクルの一部だけの速度向上は全体のデリバリーに対して逓減的な効果しかもたらさない」という主張の再発見であると捉えている。
この見解は業界全体のデータとも一致している:1,255チームに属する1万人以上の開発者のテレメトリを分析したFaros AIの研究によれば、AI導入率の高いチームはタスク完了数が21%増加し、プルリクエストのマージ数は98%増加した一方で、PRレビュー時間は91%増加した。この指標はコーディング段階での加速が他の工程へ負荷を移動させるという診断と整合している。
Stern氏にとってより重要なのはこのシフトがチーム構造に何を意味するかである。小規模でフォーカスされたエンジニアリングチームを正当化する従来の根拠は、コーディングが最も重要な価値創出活動であり、コミュニケーションはそれを妨げるオーバーヘッドであるという前提に部分的に基づいている。
最も価値の高い作業が協調的な仕様策定やアーキテクチャ整合になるのであれば、その論理は逆転する:コミュニケーションは最小化すべきコストではなく、それ自体が仕事となる。小規模チームが優位に立つのは調整を減らせるからではなく、共通理解により速く到達できるからである。5人のチームは通常15人では困難なレベルで、意図やコーナーケースについて真に整合することができる。
コーディングから仕様策定および検証へのソフトウェアエンジニアリング主要成果物のシフト(出典)。
Stern氏はエンジニアがAI生成コードにどのように向き合うかについて3つのスタンスによる分類を提示している。人間がすべての行を読みレビューする「ホワイトボックス」モデルは、エージェントが1時間に数千行を生成できる状況ではスケールしない。最小限の検証でAIが生成したものをそのまま出荷する「ブラックボックス」または「バイブコーディング」は高速だが大規模ユーザー基盤を支える本番システムには脆弱である。
Stern氏が「グレーボックス」と呼ぶ中間的アプローチは、重要な2つのポイント:エージェントが正しく実行できるぐらい十分精緻な仕様を書くこと、実装を一行ずつ精査するのではなくエビデンスに基づいて結果を検証すること、において人間の説明責任を維持する。重要なのは説明責任がAIにシフトするわけではないと彼が明確に述べている点である:エージェントを指導しマージリクエストを承認するエンジニアが、出荷される成果物に対して引き続き全面的に責任を負う。
コード検査からエビデンス検証へのレビューのリフレーミングはLeigh Griffin氏とRay Carroll氏による最近のInfoQ記事Spec-Driven Developmentにおけるアーキテクチャ形式主義と響き合うものである。この記事では仕様はシステムにおける実行可能な信頼できる唯一の情報源となるべきであり、生成されたコードは下流の再生成可能な成果物として扱うべきであると論じている。
人間の権限はコードを書くことから意図の定義および管理へ移行しつつある(出典)。
Stern氏はワークフローの観点からも同様の結論に至っている:テスト可能な受け入れ基準、明示的なコーナーケース、記録されたアーキテクチャ上の意思決定を備えた高忠実度の仕様が主要なエンジニアリング成果物となり、実装は徐々に委譲される。両記事は人間の権限が抽象化スタックの上位へと移行している-すなわちコードを書くことから意図の定義と管理へ移っているという観察に収束している。