AI開発でいつ、どこまでコードを理解するか

AIに実装を任せると、コードを一行ずつ読まずにPRを通すことが構造上可能になる。筆者はチケット起票から実装前の調査、PRへの一次レビューまでAIに任せ、場合によっては設計と動作確認の記録だけを見て判断しているという。以前は、実装の過程でコードを段階的に理解せざるを得なかった。その強制力が消えたことで、設計の理解は深まる一方、行レベルの理解は急速に落ちる。Anthropicの小規模な実験でも、AIを使った開発者は直後の理解度テストで低い点を取り、特にデバッグ問題で差が出たと報告されている。 面白いのは、筆者がこれを「理解の放棄」ではなく、実装者から管理者へ立場を移した結果の意図的な選択と位置づけている点だ。ここに本音がある。認知負債は消えるわけではなく、払うタイミングが先送りされるだけで、利子は後から効いてくる。筆者自身、複雑なデータパイプラインの現状整理をAIに任せて理解を後回しにした結果、仕様書不足や並行開発が重なり、同じ仕組みを何度も説明し直す羽目になった。後回しの理解は、返済を先延ばしにした分だけ金利が積み上がる借金のようなものだ。判断の軸は、データ移行、権限、外部インターフェースなど、失敗時の影響が大きく戻しにくい箇所を先に理解することである。 中小企業で同じ問題に直面するのは、社内システムの改修を外注やAIに任せたときだ。明日からは、どこが壊れると取り返しがつかないかを三つ挙げ、その部分だけは担当者が説明できる状態にしておくことが実務的な一手になる。テストを仕様書として書く作業は、その理解を確実に残す方法でもある。