AIコードは全行読むな、契約とテストで絞れ

記事は単純な観察を土台に議論を組み立てる。AIがコードを生成するほど、人間がそれを読む時間の方が先に尽きる。筆者はすべてを同じ密度で読むのではなく、型・テスト・静的解析で機械的に強制できる部分とそうでない部分を分けることを提案する。鍵となるのは、人間を実装ではなく契約に向けることだ。例では、割引関数の事前条件・事後条件・不変条件をAIが本体を埋める前にdocstringとして書き、プロパティベーステストが入力を生成してその約束を破ろうとする。

筆者は限界にも慎重だ。この提案は仕様が安定し、CIのテスト環境が機能し、副作用が支配的でないコードを前提とする。比較表では、純粋関数とデータマッピングは契約で表現しやすく、外部API連携は部分的にしか表現できず、認可・決済・削除は表現が難しく全行読む必要があるとされる。筆者は認可の抜けがOWASP Top 10の主要リスクだと指摘し、テストが通っても認可が正しいとは限らない——多くの場合、そうしたテストは書かれていないからだと述べる。

弱いテストが仕組み全体を損なわないように、筆者はコードを意図的に壊してテストが失敗するか見るミューテーションテストを挙げ、重要なモジュールに限定することを勧める。工数について筆者は明言する。これは作業を減らす話ではない。契約を書く負担は実装を読む負担とは別物で、総量は減るのではなく移るだけかもしれない。本当の試練は、領域ごとに「守れない層」に属すると誰が決めるかをチームが明言できるかどうかだ。