コーディングアシスタントは、すべてのテストに合格したと報告します。ビルドは緑色なので、プルリクエストをマージして次の作業に移ります。3週間後に問題が届きますが、エージェントは手伝えません。APIのクォータを使い切ったのかもしれませんし、電波の届かない通勤列車に閉じ込められているのかもしれません。そのコードは今やあなたのものであり、何かが壊れています。本当に直せるでしょうか？
この問いこそがCodeOwnershipプロジェクトの中心的な課題です。実際には、所有とはコミットに自分の名前が載っていることを意味しません。そのロジックをたどり、一切の助けなしに完全に修正できて初めて、本当にそのコードを所有していると言えます。テストが通ることは、ソフトウェアが調子の良い日に動くことを示すだけで、あなたがそれを理解していることの証明にはなりません。なお、ここで扱うのは保守の問題のみで、ライセンスや著作権については対象外です。
著者はこの死角を検証するため、軽量なパイロットプロジェクトとしてCodeOwnershipを作りました。AIエージェントが機能を書き、開発者はその理解度を正直に自己評価します。次に、2つ目のエージェントが事前登録された単一のバグを仕込みます。開発者はすべてのAIツールをオフにした状態でインシデントレポートを開き、その欠陥を見つけようとします。
固定された仕様、公開テストと非公開テスト、ブラインドのバグ検証チェック、ガイド付きCLI、そして複合スコアを作らないレポートツールからなるテストハーネスは完成しています。最初の試行では、著者は自信を5段階中4と評価したものの、バグを見つけられないまま8分12秒でタイマーを止めました。後のセッションで約30分かけてバグを特定しましたが、修正を適用していなかったため、スクリプトは依然としてNOT FIXEDと記録しました。
これは1人の開発者による1回の実行にすぎず、業界全体のベンチマークではありません。ハーネスの仕組み、その弱点、そしてコード理解を測る現実的なテストがどのようなものかを示すものです。
出典: Towards Data Science · 要約：HeadlinesBriefing