アンチパターン①「Accept All症候群」

Andrej Karpathyが広めた「Accept All」文化

vibe codingの提唱者、Andrej Karpathyはこう述べました。

“I ‘Accept All’ always, I don’t read the diffs anymore.” 「私は常に『Accept All』を選ぶ。もう差分は読まない」

この言葉は、多くの開発者に影響を与えました。

「Karpathyがやっているなら、自分もやっていいはずだ」

しかし、その結果がどうなったかは、これまでの記事で見てきた通りです。

なぜ開発者は「Accept All」を押してしまうのか

なぜ、「Accept All」は魅力的なのでしょうか。

心理的要因:

即時の満足感
- クリック一つで変更が適用される
- 「仕事が進んだ」感覚
認知負荷の軽減
- 差分を読む精神的エネルギーが不要
- 「AIが正しいはず」という信頼
時間の節約（に見える）
- レビューの時間を省ける
- より多くの機能を実装できる
面倒の回避
- 差分を読むのは面倒
- 「後で問題が起きたら対処すればいい」

Accept Allで見落とすAI生成コードの問題点

「Accept All」を押すとき、何が起きているか見ていません。

見落とす可能性のあるもの:

カテゴリ	例
意図しない変更	関係ないファイルの修正
削除	重要なコードの削除
セキュリティ問題	脆弱性の導入
依存関係の変更	package.jsonの変更
設定の変更	環境変数、設定ファイル
ロジックの変更	既存機能の破壊

1回の「Accept All」で、これらすべてが適用される可能性があります。

【事例】Replit事件から学ぶAccept Allの危険性

別記事で紹介したReplit事件を思い出してください。

Jason Lemkinは「コードフリーズ」を指示しました。しかし、AIは指示を無視してデータベースを削除しました。

もし彼が差分を確認していたら、AIが何をしようとしているか気づけたかもしれません。

「Accept All」は、AIに白紙委任状を渡す ことと同じです。

Accept Allの累積効果：デバッグ不能なコードベースへ

「Accept All」の問題は、累積する ことです。

シナリオ:

Day 1: 小さな変更をAccept All
      → 気づかない問題Aが混入

Day 2: 別の小さな変更をAccept All
      → 問題Bが混入、問題Aと相互作用

Day 3: 機能追加をAccept All
      → 問題Cが混入、問題A,Bと相互作用
...
Day 30: なぜか動かない
      → 問題A,B,C,...が複雑に絡み合っている

Day 31-45: デバッグ地獄
      → どこから問題が入ったか不明

Day 46: ゼロから書き直し決定

1つ1つの「Accept All」は小さな問題かもしれません。しかし、それらが累積すると、解きほぐせない問題になります。

Accept All中毒のサイクルと脱出方法

「Accept All」には、中毒性 があります。

中毒のサイクル:

最初の一回
- 「今回だけ」と思う
- 問題は起きない（ように見える）
習慣化
- 「毎回レビューしなくても大丈夫」
- 時間が節約できる
依存
- レビューが面倒に感じる
- 「AIを信頼すればいい」
問題発生
- デバッグに時間がかかる
- 「でもAccept Allをやめられない」
合理化
- 「AIのせいではなく、自分のプロンプトが悪かった」
- サイクルが続く

AI生成コードの差分レビューが重要な4つの理由

差分をレビューすることには、複数の価値があります。

価値1: 問題の早期発見

セキュリティ脆弱性
ロジックエラー
意図しない変更

価値2: コードの理解

AIが何をしたか把握
将来のメンテナンスのため
デバッグ時の手がかり

価値3: 学習の機会

AIの生成パターンを理解
良い実装を学ぶ
悪い実装を見抜く目を養う

価値4: 品質の担保

一貫性の確保
アーキテクチャの維持
コーディング規約の遵守

効率的なAI生成コードレビューの5ステップ

「すべての行を読む」のは現実的ではないかもしれません。しかし、効率的なレビュー は可能です。

効率的なレビュー方法:

ファイル一覧を確認
- 変更されるべきでないファイルがないか
- 意図しないファイルがないか
削除された行を重点確認
- 重要なコードが削除されていないか
- 意図的な削除か
セキュリティ関連を重点確認
- 認証、認可
- 入力バリデーション
- APIキー、シークレット
外部依存の変更を確認
- package.json、requirements.txt
- 新しい依存関係の追加
設定ファイルの変更を確認
- 環境変数
- 設定値

Accept Selectedでリスクを最小化する方法

多くのAIコーディングツールには、「Accept Selected」機能があります。

活用方法:

変更を個別に確認
理解できた変更のみ承認
理解できない変更は一旦保留
保留した変更について質問

「Accept All」ではなく 「Accept Selected」 を習慣にしましょう。

チームでAccept All問題を防ぐ4つの対策

チームで「Accept All」を防ぐための対策があります。

対策:

コードレビューの義務化
- Pull Requestベースの開発
- 他のメンバーによるレビュー必須
自動テストの整備
- 変更がテストを壊さないか確認
- CIでの自動実行
静的解析の導入
- セキュリティスキャン
- コード品質チェック
教育と意識向上
- 「Accept All」のリスクを共有
- 事例の共有

この事例から学ぶべき教訓

「Accept All症候群」から学ぶべきことは以下の通りです。

「Accept All」はAIへの白紙委任状
- 何が起きているか見ていない
問題は累積する
- 1回1回は小さくても、積み重なると解決不能に
「Accept All」には中毒性がある
- 一度始めるとやめられなくなる
差分レビューには複数の価値がある
- 問題発見、理解、学習、品質
「Accept Selected」を習慣にせよ
- 理解した変更のみ承認

まとめ：重要ポイントの振り返り

Karpathyの「Accept All, don’t read the diffs」が広まった
「Accept All」は AIへの白紙委任状
問題は累積し、最終的に解決不能になる
「Accept All」には 中毒性 がある
差分レビューは問題発見、理解、学習、品質担保に価値
教訓：「Accept All」ではなく「Accept Selected」を習慣に

Accept All症候群：差分を読まない開発の代償