バグ1行なのに差分は大改造、HNが「過剰編集」に反応した理由

この話がHacker Newsで強く刺さったのは、開発者が普段から感じていた違和感にやっと名前が付いたからだ。1行のバグ修正を頼んだだけなのに、返ってくるのは関数半分を書き直した巨大diff。変数名は変わり、不要な検証が増え、レビュー負荷だけが跳ね上がる。

元記事 Coding Models Are Doing Too Much は、この現象を over-editing と呼ぶ。修正に必要な最小範囲を超えてコードをいじる振る舞いだ。著者は BigCodeBench の400問を人工的に壊し、モデルの出力を「本当に必要な最小修正」と比べた。指標は token-level Levenshtein distance と追加の cognitive complexity。テストが通るかだけではなく、どれだけ余計な変更を増やしたかを見たわけだ。

HNが特に注目したのは結果だ。記事では GPT-5.4 が大きなdiffを作りやすく、Claude Opus 4.6 はより小さい修正で高い正解率を出した。さらに「元のコードをできるだけ保て」という単純な指示だけでも、多くのモデルで編集量が減り、一部では正解率も上がった。つまり過剰編集は能力不足だけではなく、デフォルトの作業スタイルの問題でもある。

コメント欄の温度感も興味深い。プロジェクトルールを明示し、パッチ範囲を狭くすればかなり抑えられるという声がある一方、個人開発ではコストが重いという反応も強かった。5行で済む変更が50行に膨らむと、実装者とレビューアの両方を一人で引き受けることになるからだ。逆に、既存コードを尊重しすぎて必要な構造変更まで避けるモデルもある、という反論もあった。

HNがこの話から受け取ったのは、単なるモデル比較表ではない。コーディングエージェント時代の「良い編集」の基準だ。brownfield のコードベースで価値があるのは、派手な書き直しではなく小さく読めるdiffだ。変更が小さければ、読むのも、信じるのも、危ない発想を見つけるのもずっと楽になる。