HN Fixates on “Over-Editing”: When Coding Models Rewrite More Than the Bug

Hacker News did not treat this post as abstract benchmark chatter. The discussion landed because it names a failure mode that developers keep running into in real repositories: ask for a one-line fix, get a half-function rewrite back.

The underlying article, Coding Models Are Doing Too Much, calls this over-editing and gives it a concrete definition: code is functionally correct, but the patch diverges from the original structure far more than the minimal fix requires. To study that, the author programmatically corrupted 400 BigCodeBench problems, then compared model outputs against the known minimal repair using token-level Levenshtein distance and added cognitive complexity.

The numbers are why HN paid attention. In the reported results, GPT-5.4 produced some of the biggest diffs in the benchmark, while Claude Opus 4.6 stayed much closer to the minimal patch and scored higher on correctness. The article also shows that a blunt instruction such as “preserve the original code as much as possible” improves both edit size and, for most models, correctness. That matters because it reframes the issue from “models are doomed to rewrite everything” to “their default editing style is wrong for brownfield work.”

Commenters largely agreed on the pain, but they split on what it means in practice. One camp said over-editing is manageable if you aggressively steer the agent, save project-specific rules, and keep it inside a narrow patch scope. Another argued the real cost is asymmetric for solo developers: when an agent touches 50 lines instead of 5, you become both implementer and reviewer, and review time is what disappears first. A third theme in the thread pushed back from the other direction, noting that agents can also become too conservative and cling to existing structure when a requirement really does justify a broader refactor.

That tension is what made the post travel on HN. It is not just complaining that models are verbose. It is asking what good editing means once coding assistants move from autocomplete into direct file mutation. If the goal is reliable software, minimality becomes a product question as much as a model question: smaller diffs are easier to inspect, easier to trust, and harder for bad ideas to hide inside.