AIに修正を頼む前に、残すコードを一つ決める

AIに「このバグを直して」と頼むと、テストは通るのに周辺の書き方まで変わって返ってくることがあります。動くなら助かる一方で、レビューするときには「どこが本当に必要な変更だったのか」をほどく時間が増えます。

今回の研究は、この余計な書き換えをover-editingとして扱っています。Paper Idea Labとして借りたい見方は、AIに直しを頼む前に、直す場所だけでなく残す場所も短く言っておくことです。

論文では、400件のBigCodeBench由来タスクに局所的な破損を入れ、既知の最小修正とモデルの修正を比べています。保存を明示する指示を足すと、余分な編集量と追加の複雑さが下がり、Pass@1も少し上がりました。

ここから日常へ持ち帰るなら、「AIは正しく直せるか」だけを見るのではなく、「守りたかった既存の意図を残しているか」も見る、ということです。小さな修正ほど、AIに自由に整えさせる前に、触らない境界を一行で置くほうがレビューしやすくなります。

次に小さなコード修正を頼むとき、依頼文の末尾に一行だけ足します。「修正してほしい場所: 〇〇。残してほしい場所: 既存の入力検証と返り値の形。不要なリファクタはしないでください。」

全部を細かく縛る必要はありません。まずは、守りたい場所を一つだけ決める。APIの形、UIの文言、既存の分岐、どれか一つで十分です。

返ってきた差分は、テスト結果だけでなく、目的外に変わった行がないかを一つ確認します。もし直したい場所以外が大きく動いていたら、「テストが通る前提で、変更行を減らしてください」と頼み直して比べます。

もちろん、大きな設計変更や機能追加では、広い変更が必要なこともあります。その場合は「今回はリファクタも含めてよい」と先に書く。小さく直す作業と、広く作り替える作業を混ぜないことが、人間側に残る大事な線引きです。