10月29日、Steef-Jan Wiggersが「Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That」と題した記事を公開した。この記事では、AnthropicがClaudeコードの約90%をClaudeが書く体制においてコードレビューをどう運用しているかについて詳しく紹介されている。

「誰もメンタルモデルを持つ必要はない」という主張

コードの90%をAIが書く環境で、人間のエンジニアはコードベースをどこまで把握すべきなのか。Anthropicが公開したブログ記事の中で最も議論を呼んでいるのは、90%という数字ではなく、チームが「もはや不要だ」と位置づけている事柄だ。

チームの誰もClaudeコード全体のメンタルモデルを頭に入れていないし、誰かが持つ必要があるとも思っていない。コードベースのある部分を理解したい場合は、その箇所のexplainerをClaudeに書かせる。数分で、今日現在のコードを反映した説明が得られる。

これはAnthropicが「メンタルモデルは不要だ」と積極的に推奨しているというより、AIが大半のコードを生成する環境での実態として記述されたものだ。それでもこの一節がHacker Newsの議論を支配した。コメントのjonahxはこのアプローチが手放しているものを整理している：

誰も把握していないのに、クリティカルなバグが発生したとき誰に聞けばいいのか。誰の頭の中にも因果モデルがない。新しい信頼モデルはこうだ：「Claudeが常にシステムを理解し、あらゆるデバッグや変更を行えると信じる」

ただし同コメントは、大規模なレガシーシステムの多くがすでにこの状態に近いとも指摘している。

この判断が正しいかを試すケースがすでに存在する

Anthropic自身のリポジトリでexplainerの精度に疑問符がつく事例が記録されている。

8月、Claude Codeの開発者Boris Chernyが、issueの自動クローズに関する長年の苦情に「Generated with Claude Code」フッター付きのコメントで回答した。内容は「issueは一定期間活動がなく再現手順の情報が欠けている場合にクローズされる」というものだった。

ところが実際には、リポジトリのissue-lifecycle.tsが14日でstale、さらに14日でクローズする設定になっており、10件以上のupvoteを持つissueのみ除外される。開発者のmarcindulakは、再現手順ありとラベルされたissueが6,000件以上「非アクティブ」としてクローズされていたと報告した。さらに、コメントが示した救済策（コメントしてissueを再オープンさせる）は、クローズ後7日でissueをロックするワークフローによって実際には機能しない。

この問題の発端となった回答は、世界トップクラスのモデルによって生成されたものであり、このリポジトリでissueがどう管理されているかを誤診していた。

「エージェントがレビュアー」になることで生じる固有の問題

記事が記録している障害のうち最初のものは、レビュアー・著者の両方がエージェントのときにのみ発生する：

ノイズのコストは著者がエージェントのとき高くなる。人間なら細かい指摘を数秒で流せる。エージェントはそれを修正しようとし、別のコミットとレビューラウンドが発生する。

あるCLIのPRは一晩で50回以上のレビューと修正ラウンドを繰り返した末に著者（エージェント）が止めたという。ラウンド数を増やすと状況は悪化したため、チームは上限を設けた。

r/ClaudeCodeのコメントChemicalExcellent463も独立して同じ制御に行き着いたと報告している。2回連続で修正に失敗したら止める、というルールだ。理由はシンプルで、繰り返し失敗しているなら「エージェントが編集し続けている行ではなく、コード全体の認識が壊れている」ためだという。

さらに、複数ラウンドのレビューが何を発見しているかの分析も興味深い：

git blameを実行したところ、レビュアーがフラグを立て続けていたコードの約59%は最初のパスからあったコードだった。レビュアーは新しいバグを見つけていたわけではなく、古いバグを少しずつ見つけていたに過ぎない。

マージを制御するリスク分類

マージの承認要件は、変更のリスクティアで決まる。「変更がティアを決定する。著者が誰かではなく」という原則だ。

• ローカルリスク（Low）: ドキュメント、コピー、フラグ付きの追加変更 → 人間の承認不要
• ミディアムリスク（Medium）: キャッシング、自動アップデーター、システムプロンプト → 1人必要
• ハイリスク（High）: 元記事にHighティアの詳細な記述がある場合は補足が望ましいが、現時点では具体的な要件は記事中で明示されていない

2つのルールが境界線を守る：「エージェントの承認は人間の承認としてカウントしない」、そして「変更をプロンプトした人物は必要レビュアーの1人としてカウントする」

このルールに対しては疑問も上がっている。Redditのコメント（Oximy-Naman）は「ローカルリスクはドキュメントとして出荷されるエージェント命令の変更もカバーするか？それらはアプリケーションコードに触れずにエージェントの動作を変更できる」と問いかけたが、回答は得られていない。また、Hacker NewsのコメントのGaal_Dornickは自社のSOC 2レビュアーが本番環境へのすべての変更を第二の人間がレビューするよう要求していると報告しており、記事は監査要件については言及していない。

「サーキットブレーカーはまだない」と自ら認める

チームは1点の欠落を自ら明示している：

数値が動いたときに承認要件を厳格化するサーキットブレーカーがまだない。より多くのコードがゼロヒューマンマージに移行する前に、エンジニアたちはそれを望んでいる。

楽観的な見方もある。Hacker NewsのコメントのCheema33は「大組織はもともと誰も完全なモデルを持っていない。これはむしろ現状からの改善だ」と主張し、Markbaoは月数千ドルのAIレビューと、エンジニアの時間の最大3分の1を消費する人間レビューの比較を報告している。

公開されているコンポーネント

システムの一部はすでに公開されている。Code Review for Claude CodeはTeamおよびEnterpriseプランで利用可能で、セキュリティレビューはオープンソースのGitHub Actionとして公開されている。ただし、そのREADMEには「プロンプトインジェクション攻撃に対してハードニングされておらず、信頼できるPRのレビューにのみ使用すること」と明記されている。

詳細はAnthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing Thatを参照していただきたい。