認知的降伏：理解できないコードをAIエージェントが書くとき

あなたはエンジニアに大きなPRについて連絡します。本質的なアーキテクチャの質問を1つすると、彼らは答えられません。誰も答えられません。巨大な差分で、皆急いでいるため、承認され、読まれずにマージされます。それがAIが自分のコードをレビューしている姿です。同じエージェントに自分の作業をチェックさせるのは、生徒が自分の試験を採点するようなものです。いつも合格します。

このシナリオは、Manager.devの最近の記事の中心であり、開発者がコード生成だけでなく意思決定までもClaudeのようなAIアシスタントに委ねたときに何が起こるかを探求しています。著者は「私は知らない、Claudeが書いた」という反応について書き、増大する問題を浮き彫りにしています：認知の降伏です。

認知の降伏とは？

この記事では、2つの用語を区別しています：

• 認知のオフロード — AIに委任するが、依然として答えに対して責任を持つこと。
• 認知の降伏 — AIの出力が静かに自分の出力となり、チェックすべきものが何も残っていないと感じること。

ソフトウェアエンジニアにとって、この2つの境界線はほとんどの日、足元で動いており、多くの人が気づかないうちに越えてしまっています。AIが生成したコードがレビューされないままだと問題はさらに悪化し、著者もレビュアーもコードベースを理解していない状況につながります。

どのように起こるか

記事では典型的なシナリオを説明しています：

1. 小さくないタスクがあるため、有名なスーパーパワーズのブレインストーミングスキルを使ってClaudeとの計画セッションを開始します。
2. 計画を深く読み、いくつかの問題を修正し、実行に送ります。
3. コードをレビューし、良さそうに見え、いくつかのプロンプトで小さな問題を修正し、レビューに送ります。
4. 次に、より大きなタスクが来ます。それは曖昧です。AI以前の世界では、小さな部分に分割したでしょうが、急いでいます。
5. Claudeが妥当な計画を生成するので、すぐに実行に移ります。結果は機能します。コードをざっと読み、PRを開き、次に進みます。
6. あなたは、実際に何が起こっているのかを理解する部分をスキップしました。

最良のケースでは、レビュー担当のエンジニアがあなたが完全には理解していない質問をします。最悪のケースでは、それは非常に大きなPRで、皆急いでおり、承認されてマージされます。誰も理解しませんでした — 著者もレビュアーも。

抵抗が難しい理由

著者は個人的な経験を共有しています：野心的なミッションでClaudeとの計画セッションに2〜3時間費やしたこと。実行の途中で、迷子になったと感じました — 動く部分が多すぎて、Claudeが下した決定も多すぎました。結局、/clearと入力してすべてをリセットしました。2つの問題がありました：

• 達成したいことについて漠然としたアイデアから始めたこと。
• 作業している分野について十分に理解していなかったこと。

計画が曖昧で、自分で決定を下すのに十分な知識がない場合、結局Claudeに決定を委任することになります。GoogleのエンジニアリングディレクターであるAddy Osmaniが書いたように、Claudeを使用することと運転させることの境界線は非常に曖昧で、誘惑に抵抗するには多くの努力が必要です。

一つのアプローチ：すべての行をレビューする

この記事は別のアプローチを提供しています。より小さなタスク（内部AIエージェントインフラストラクチャにSegmentを介したイベントトラッキングを追加すること）に対して、著者はClaudeと計画を立て、それからコミット前にIDEで各変更をレビューしました。理解できないファイルについては、Claudeに説明を求めました。答えが意味をなさない場合、コードを変更し、再度レビューしました。すべてのファイル変更を理解する頃には、完全なソリューションを理解していました。

著者はPRを開き、シニアエンジニアから素晴らしいコメントを得ました — そして、岩の後ろに隠れる魚のように隠れるのではなく、実際にそれらに応答することができました。

重要なポイント

AIコーディングエージェントを使用するときは、自分が責任を持つコードを理解していることを確認してください。AIにすべての決定をさせないでください。各変更をレビューし、質問し、理解していないPRを開かないでください。