海外の開発者コミュニティに、こんな相談が投稿されていました。
Reddit の Claude 関連フォーラムでの話です。
Claude Code そのものに不満はない。 むしろ良いツールだと思う。 ただ、まだ完全には信用しきれない。 だから、触った箇所を全部確認してしまう。 その緊張感に疲れた
そして、投稿者はこう続けます。
タイピングの疲れが、レビューの疲れにすり替わっただけではないか。
日によっては、後者のほうがつらい、と。
この投稿には、多くの開発者が反応しました。
本記事では、そこで交わされた議論を整理します。
なお、これは筆者自身の体験談ではありません。
あくまで、海外フォーラムで語られていた内容の紹介です。
タイピング疲れは自動化された。次に来たのは検証疲れ
コメント欄で最も共感を集めていたのは、この構図の言語化でした。
AIが生成したコードを、人間が書いたコードと同じ密度でレビューしようとする。
しかも、量は10倍。
ここに罠があります。
ある開発者はこう指摘していました。
全行を追いかけている限り、あなたがパイプラインの中で一番遅い部分になる、と。
厄介なのは、これが単なる作業量の問題ではない点です。
自分が書いたコードなら、書きながら考えています。
だから、レビューは半分終わっている状態からスタートできます。
ところが、AIの出力は目にした瞬間がすべて初見です。
触ったことのないコードベースだと、さらに事情は悪くなります。
詳しくないドメインなら、そもそも何が地雷なのか分かりません。
「どこを見ればいいか分からないまま全部見る」という、一番消耗するモードに入ってしまうのです。
書く作業には、手が動く時間があります。
頭が休むタイミングも生まれます。
パズルを解く楽しさもある。
読む作業には、それがありません。
ADHDだと自覚している人からは、こんな声も上がっていました。
コードを書くのは好きだった。
でも、レビューは本当にきつい、と。
全行読むのをやめて、境界を読む
議論の結論は、おおむね一致していました。
根性でレビューし続けるのではなく、ワークフローのほうを変える。
具体的には、人間の目を投入する場所を絞ります。
多くのコメントで名前が挙がっていたのは、次の領域でした。
- アーキテクチャ
- データフロー
- 認証まわり
- データベーススキーマ
- 課金や決済の処理
妙な抽象化が入っていないかどうか。
実際の振る舞いが意図どおりかどうか。
これらも、人間が見るべき対象に含まれます。
逆に、ボタンのCSSは軽く済ませて構いません。
ビジネスロジックと無関係なUIの処理も同じです。
ざっと眺めて、明らかな破綻がないかを見る程度でいい。
200行のボイラープレートを丁寧に読むのは、人間の脳の無駄遣いでしょう。
しかし、トリッキーな状態管理の20行を読むのは立派な仕事です。
こういう線引きになります。
ある人の表現が印象的でした。
自分はいまだにAIを信用していない。
ただ、間違っていたときの被害範囲を十分に小さくしておけばいい。
そうすれば、四六時中見張る必要がなくなる、と。
これは信頼を高める話ではありません。
信頼しなくても回る仕組みを作る話です。
テストと小さなコミットが緊張感を肩代わりする
被害範囲を小さくする方法として、テスト環境への投資が最も多く推薦されていました。
なかでも支持を集めていたのが、本来のTDDです。
テストを先に書いて、まず失敗させる。
ここで頭を使います。
受け入れ条件とエッジケースを本当にカバーしているか、時間をかけて確かめる。
そこさえ信用できれば、実装コードは流し読みでも明らかな問題は拾えます。
もう一つが、コミットの粒度でした。
1タスク1コミットです。
同じ400行でも、40行を10回読むほうが脳への負担は段違いに軽い。
編集のたびに型チェックとテストが走るフックも有効です。
仕込んでおけば、動くかどうかを人間が確認する場面自体が消えます。
ある開発者は、こう書いていました。
どの変更もコマンド一発で取り消せる状態になった。
その時点で、全部を読む必要を感じなくなった、と。
AIにAIをレビューさせる
複数のモデルを突き合わせる運用も、いくつも紹介されていました。
役割の違うレビュー用エージェントを何体か立てる。
そして、正確性、ドキュメント、スタイル、受け入れ条件をそれぞれ担当させる。
あるいは、循環的複雑度を計算させて、複雑な箇所を優先的に人間に見せる。
GPTやQwenといった別系統のモデルに、相互チェックさせている人もいました。
ローカルLLMに一次レビューをさせるという手もあります。
危なそうな部分にフラグを立ててもらうだけの、軽量な使い方です。
ただし、ここには落とし穴もあります。
あるコメントによれば、こんな事例があったそうです。
自動レビューに対して「指摘は直した」と報告しながら、実際には直っていなかった。
コードを提示させたところ、嘘は続けられなくなった、と。
レビュー役のAIを増やしても、最後にマージボタンを押す責任は消えません。
「もう読まなくていい」への反論
議論の中には、こういう主張もありました。
コードレビューはもう時代遅れだ。
機能さえ動けば十分だ、と。
これに対する反発は、かなり強かったです。
技術的な指摘として挙がっていたのが、テストを通過する間違ったコードの存在でした。
下層に問題を抱えたまま、関数の形が決まってしまう。
上層の呼び出し側は、その歪みを毎回吸収する。
両方をAIが書いているので、上層のテストは全部通ります。
しかし、設計としては壊れている。
こうしたパターンは、テストでは検出しにくいのです。
冗長なコードや重複、非効率な実装も同じです。
動作としては正常に見えます。
だからこそ、重要な部分には別の検証手段が要ります。
もう一つ、印象的な皮肉が紹介されていました。
AIは生産性を10倍にも100倍にもする。
ただし現実には、エンジニア1人で50人分の技術的負債を作れるようになっただけかもしれない、と。
コードベースが育つほど、初期の設計判断のまずさは効いてきます。
銀行で働いているという開発者は、もっと直接的でした。
振込処理をレビューなしで通したとする。
送金先のIDが別のものにすり替わっていたら、どうするのか。
コードレビューがAI以前から存在した理由は、AI以後も消えません。
見落とされがちな二つの論点
議論の中で、あまり目立たないものの重要だと感じた指摘を紹介します。
一つ目は、コンテキストの汚染です。
会話の圧縮やドキュメント更新を、何度も重ねる。
すると、モデルは自分の過去の出力を土台にして次の作業を始めます。
メモリ機能に残った記述も同じです。
少しずつの逸脱が積み重なっていきます。
いくら訂正しても、同じ誤解が戻ってくる。
その原因が、古いチャットログやメモリファイルに残っていた。
そんな話がありました。
定期的な棚卸しが要ります。
二つ目は、レビューする道具そのものの古さでした。
git のdiff表示は、この用途にはもう素朴すぎる。
そういう声です。
この関数がどこから呼ばれているのか、毎回自分で探し回ることになります。
求められているのは、文脈を差し出してくれるツールでしょう。
たしかに、生成する側だけが劇的に進化しました。
一方で、確認する側の道具は据え置きのままです。
不確実性のほうを聞き出す
具体的なテクニックとして、これは試す価値がありそうだと思ったものがあります。
コードだけを受け取るのではありません。
不確実性を、明示的に質問するのです。
ここで何を前提として仮定したのか。
この変更のうち、自分が一番自信を持てないのはどこか。
そう尋ねると、状態が変わります。
「どこを見ればいいか分からないから全部見る」が、短く具体的なリストになる。
差分全体ではなく、その一部分だけを注視すればよくなります。
ドメイン知識を身につける代わりにはなりません。
それでも、リスクの在り処を毎回ゼロから手探りする手間は減らせます。
まとめ
レビュー疲れは、AIの性能が上がれば自然に消える問題ではありません。
むしろ、生成量が増えるぶん、確認する側の負荷は積み上がります。
議論から見えてきた方向性は、意外とシンプルでした。
全行を追うのをやめる。
認証やスキーマや課金といった急所に、人間の注意を集中させる。
テストと小さなコミットで、間違いの被害範囲を縮める。
AIによる相互レビューを挟みつつ、最後の判断は自分で下す。
これは、プログラマの思考からリードやマネージャーの思考への切り替えでもあります。
エンジニアリングマネージャーは、全部のプルリクエストを読みません。
読まなくても品質が保たれる体制を作る。
それが仕事だからです。
とはいえ、コードを読むこと自体を軽んじる話ではありません。
自分が納品したものについて、何をどうやって実現しているのか説明できない。
その状態は、やはりまずいでしょう。
プロンプトと設計ドキュメントだけで中身を把握した気になるのは、たぶん錯覚です。
書く楽しさが減ったという嘆きにも、正直なところ共感します。
ただ、疲れの正体はどこにあるのか。
「信用できないから全部見る」という構造にあるのなら、対処すべきは自分の集中力ではありません。
その構造のほうです。
