「コードレビューは2026年に死ぬ」— Latent.Space の衝撃論考

衝撃的な主張

Latent.Space に掲載された Ankit Jain（Aviator CEO）の論考が話題だ。

「人間が書くコードは2025年に死んだ。コードレビューは2026年に死ぬ」

著者について

Ankit Jain は Aviator の創業者兼CEO。AI ネイティブな開発チーム向けのインフラを構築している。

この論考は Latent.Space のゲスト投稿プログラムの一環として掲載された。編集者の swyx は「自分はまだそこに到達していないが、明らかに地平線上にある」とコメントしている。

データが示す現実

10,000人以上の開発者、1,255チームのデータ分析結果：

問題の構造

1. AI がコードを大量生成する
2. PR の数が倍増する
3. レビュー時間も倍増する
4. 人間のレビューが追いつかない

「汚い秘密」

論考は、すべてのエンジニアリング組織が抱える「汚い秘密」を指摘する：

「PRが何日も放置される。ゴム印承認。500行のdiffを流し読み。チームは何十年も、行単位のレビューなしでコードを出荷してきた」

人間がコードを人間の速度で書いていた時代ですら、レビューは追いついていなかった。

AI がコードを書く時代に、人間がレビューで追いつけるはずがない。

開発者の声

「AI 生成コードのレビューは、同僚が書いたコードのレビューより大変」

AI は一貫したスタイルで大量のコードを生成する。しかし、そのコードの「意図」を理解するのは、人間が書いたコードより難しい。

解決策：Spec-Driven Development

Ankit の提案は、チェックポイントを上流に移動させること。

従来のアプローチ

要件 → コード作成 → コードレビュー → マージ
                      ↑
                 ここでチェック

新しいアプローチ

Spec 作成 → Spec レビュー → AI がコード生成 → 自動検証 → マージ
               ↑
          ここでチェック

パラダイムシフト

歴史的な文脈

「チェックポイントは以前にも移動した。Waterfall のサインオフから CI に移行したように、また移動できる」

ソフトウェア開発の歴史：

実践的な意味

Spec に含めるべきもの

• 計画: 何を達成するか
• 制約: 何をしてはいけないか
• 受け入れ基準: どうなったら成功か
• アーキテクチャ決定: なぜこの設計か

コードレビューの役割変化

懐疑的な視点

編集者の swyx は、この論考を掲載しつつも慎重な立場：

「最近 AI レビューツールを出荷したばかりで、個人的にはまだ『そこ』に到達していない。しかし、明らかに地平線上にある」

残る課題

1. AI の幻覚: 自信満々に間違ったコードを生成する
2. セキュリティ: AI がセキュリティホールを見逃す可能性
3. 責任問題: 誰がバグの責任を取るか
4. 複雑なドメイン: ビジネスロジックの正しさは Spec だけでは検証困難

日本への示唆

日本の開発現場の現状

• レビュー文化が強い（品質重視）
• 「目視確認」への信頼が高い
• SI 業界では「レビュー工数」がプロジェクト計画に組み込まれている

変化の圧力

• AI コード生成の普及で PR 数が増加
• レビュー工数の爆発は避けられない
• Spec-Driven への移行圧力は日本にも及ぶ

まとめ

Ankit Jain の論考は、AI 時代のソフトウェア開発における根本的な問いを投げかける：

「AI がコードを書く時代に、人間は何をレビューすべきか？」

答えは「コードではなく Spec」かもしれない。

• AI がコードを大量生成 → レビュー負荷が爆発
• 人間のレビューでは勝てない
• チェックポイントを上流（Spec）に移動
• コードは成果物、Spec が真実

2026年にコードレビューが「死ぬ」かどうかはまだわからない。しかし、変化は確実に来ている。

参考リンク

• How to Kill the Code Review - Latent.Space
• Comments - How to Kill the Code Review
• Scaling without Slop - Latent.Space