HN
Today

Over-editing refers to a model modifying code beyond what is necessary

AI coding assistants frequently "over-edit" code, making extensive, unnecessary changes beyond a minimal fix. This behavior, though often driven by their inherent reasoning styles, creates significant overhead in code review and can degrade codebase quality. However, new research shows that targeted prompting and Reinforcement Learning (RL) can train these models to be much more precise and faithful editors.

334
Score
184
Comments
#2
Highest Rank
19h
on Front Page
First Seen
Apr 22, 6:00 PM
Last Seen
Apr 23, 12:00 PM
Rank Over Time
22234666789121191010111317

The Lowdown

AI-assisted coding, while powerful, often suffers from the "Over-Editing" problem: models modify code far beyond what's necessary for a requested fix. This leads to massive diffs, increases cognitive load for reviewers, and can silently degrade code quality, particularly in brown-field development where existing code is well-understood and deliberately structured.

Here's a breakdown of the key findings:

  • Defining Over-Editing: The paper defines over-editing as functionally correct output that structurally diverges from the original code more than the minimal fix requires. A prime example shows GPT-5.4 rewriting an entire function for a single off-by-one error.
  • Measuring the Problem: A novel methodology programmatically corrupts 400 problems from BigCodeBench, ensuring a well-defined minimal fix. Metrics like token-level Levenshtein Distance and Added Cognitive Complexity (an improvement over Cyclomatic Complexity) quantify the extent of over-editing.
  • Model Performance: All frontier models exhibit over-editing. GPT-5.4 demonstrates the most over-editing (high Levenshtein, high Cognitive Complexity), while Claude Opus 4.6 performs best, achieving high correctness with minimal diffs.
  • Prompting's Impact: A simple instruction like "preserve the original code as much as possible" significantly reduces over-editing across models, with reasoning models showing the largest gains due to their stronger instruction-following capabilities. This suggests over-editing is a default behavior, not a fundamental limitation.
  • Reasoning vs. Overthinking: By default, reasoning models tend to over-edit more, as their extended reasoning leads them to "improve" code unnecessarily. However, their superior instruction-following means they excel at making minimal edits when explicitly asked.
  • Training for Minimality: Various fine-tuning methods were explored, with Reinforcement Learning (RL) proving most effective. RL successfully trained models to be more faithful editors, improving both Levenshtein Distance and Added Cognitive Complexity, crucially without experiencing catastrophic forgetting of general coding abilities.
  • Efficiency of LoRA: Using LoRA with RL showed that even a small number of additional parameters can effectively teach models minimal editing behavior, offering a cost-effective solution for style-level changes.
  • Scalability: The RL approach generalized well to larger models (Qwen3 14B), indicating its robustness for broader application.

The research concludes that while over-editing is a widespread and measurable issue in AI-assisted coding, it is a solvable problem. Both careful prompting and advanced training techniques like RL can significantly enhance LLMs' ability to make precise, minimal, and higher-quality code edits, ultimately improving the utility of these tools for developers.

The Gossip

Agent Anxiety & Effectiveness Allegories

The comment section reflects a split experience with AI coding assistants. Many users share deep anxieties about surrendering control, not understanding underlying processes, and the potential for severe errors (like accidentally wiping databases or leaking credentials). They worry about skill atrophy and the feeling of 'not knowing what you don't know.' Conversely, some, particularly Claude users, report highly positive experiences, crediting specific interaction patterns like 'Just Talk To It,' providing clear feedback, and reviewing AI-generated code meticulously. They see significant productivity gains, transforming their roles from coders to 'teachers' or 'architects' overseeing AI 'teams.' There's also a debate on whether AI 'games' its metrics, producing verbose but potentially flawed code to appear successful.

Refactoring Riddles & Commit Concerns

A significant discussion revolves around whether LLM over-editing is a flaw or an unintentional fulfillment of the 'Boy Scout Rule' (leave code cleaner than you found it). Some argue that LLM changes are not true refactoring but rather 'yanks of the slot machine's arm,' often increasing cognitive complexity and breaking functionality. Critics emphasize the importance of atomic commits, separating refactors from bug fixes to maintain reviewability. Others, however, see value in the AI's tendency to refactor as it goes, suggesting it can help tackle tech debt, even if it requires careful oversight. The consensus leans towards the AI's changes not being true 'refactors' as understood by developers.

Prompting Prowess & Control Conundrums

Commenters largely agree with the paper's finding that explicit prompting to make minimal changes is effective. Users share various strategies for 'taming' AI, such as breaking down tasks, specifying what *not* to change, using `git add -p` for granular control, and building custom agent 'skills.' The debate highlights the tension between allowing AI autonomy and maintaining developer control. Many advocate for 'semi-autonomous, steerable agents' rather than fully autonomous ones, emphasizing the need for tools that better integrate with human workflows and allow for effective context management to avoid excessive, unwanted changes.

Algorithmic Ambiguity & Deterministic Dilemmas

The discussion delves into the underlying mechanics of LLMs. Some theorize that over-editing is a training data artifact, as models learn from examples that prioritize 'cleaner' or more polished outputs over minimal diffs. The comparison to traditional compilers is frequently made: while compilers are deterministic and their outputs understood, LLMs are seen as less predictable, increasing the cognitive load of review. A debate emerges on whether LLMs are fundamentally deterministic (given fixed seeds and models) or practically non-deterministic (due to provider changes, temperature settings, and the sheer complexity making reproducibility difficult). Concerns about 'reward hacking' are also raised, where models might optimize for superficial metrics rather than true utility.