Claude Codeがコードを書いたときの「コードレビュー」とは何か
従来のコードレビューでは、レビュアーがコードを書かなかったと仮定します。新鮮な視点を持ち込み、著者が近すぎて見えなかった点を見つけます。
Claude Codeがコードを書いたとき、あなたは奇妙な形でレビュアーと著者の両方です――あなたはそれを書かなかったが、各段階を承認しました。以下は、私がレビュープロセスについて見つけた変化です。
間違った決定を探す、間違った構文を探すのではない
エージェントは構文的に正しいコードを書きます。リンターは通します。間違っている点は意味論的なもので、誤った挙動を実装してしまうこと、スケールしない設計上の選択をしてしまうこと、技術的には妥当でも文脈上は不正確なエッジケースの扱いをしてしまうことです。
エージェントが書いたコードの良いレビューは、「これが私の意図した通りに動作しているか」ではなく、「これは正しく書かれているか」に焦点を当てるべきです。
前提検証
最も有益なレビューの質問は次のとおりです：「エージェントは私が明示的に伝えなかったことを何と仮定したのか？」
エージェントが書いたコードのすべてには暗黙の前提があります。入力がこの関数に到達する前に検証されると仮定していました。このフィールドは常に存在すると仮定していました。このAPIは毎回同じ形を返すと仮定していました。
それらの前提のいくつかは正しいです。いくつかは正しくありません。レビューの主な目的は、そうでない前提を探すことです。
網羅性のギャップ
エージェントが書いたテストは、正常系をよくカバーしますが、エッジケースは一貫性に欠けることが多いです。テストをレビューするとき:
- エラーパスがテストされていることを確認する。成功パスだけではなく。
- テストの入力が実際の入力範囲を表していることを検証する。
- 失敗時に有用なエラーメッセージが出ることを確認する。単に失敗するだけではなく。
「テストは通るが、テストしているのは間違ったこと」という状況には、数え切れないほど遭遇してきました。
範囲チェック
エージェントが本来触れるべきでないものに手を加えていないか？ 私はgit diff --statを実行してすべてのファイルを確認します。予期しなかったファイルが現れた場合、それを承認する前にその理由を理解します。
レビューは何ではない
これは行ごとの構文監査ではありません。エージェントは構文的にきれいなコードを書きます。フォーマットの検討に時間を費やすのは、レビューの帯域を浪費します。
これは信頼はするが検証は何もしないというレビューではありません。「テストが通る」ことは必要ですが十分ではありません。レビューは実行ではなく、意思決定についてのものです。
builtbyzac.comでClaude Codeを実行した結果。
