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

AI coding agents are increasingly criticized for “over-editing” – rewriting large swaths of code, adding complexity, and touching multiple files when only a small, localized change is needed. Commenters weigh this against the long‑standing ideal of “refactor as you go,” noting that today’s models often perform low‑quality or risky refactors, hide mistakes behind exception handling, and can even run dangerous commands if not tightly constrained. Many advocate for treating agents as tightly steered tools rather than autonomous developers, using strict prompts, sandboxing, and careful code review to capture productivity gains without losing control of code quality or personal understanding of the system.

Over‑editing vs Minimal Changes

  • Many report LLM coding agents fixing a small bug by rewriting large chunks of code or multiple files, increasing cognitive complexity and “code churn.”
  • Users distinguish useful refactoring from arbitrary rewrites; most say agents frequently do the latter, including unnecessary comments and try/catch blocks.
  • Some compare this to junior dev behavior: large, “clean-up” PRs for tiny feature changes, violating the norm of low‑impact changes and small diffs.

Refactor‑as‑You‑Go Debate

  • One camp defends the “Boy Scout rule”: modest refactors while you’re in an area, especially when not refactoring would force hacks.
  • Another camp stresses Chesterton’s Fence: don’t touch code outside the current task unless you deeply understand it, and keep refactors separate from feature commits/PRs.
  • Several suggest compromise: refactor, but in follow‑up PRs, or cap refactor scope (e.g., ~10% of a change).

Autonomous vs Steerable Agents

  • Strong concern about fully autonomous agents: they touch many files, run scripts/tests/deployments, and can wipe databases or mishandle credentials.
  • Some find “babysitting” every command exhausting; others accept slower, supervised workflows as the only safe and comprehensible option.
  • Many argue for semi‑autonomous, steerable agents with granular tools, strong constraints, and explicit human design/architecture decisions.

Learning, Understanding, and Cognitive Load

  • Several worry that offloading too much work atrophies skills and leaves them not understanding their own systems.
  • Others report productivity doubling while still reviewing every line and treating the agent as a junior pair‑programmer or code reviewer.
  • Some find agent‑driven workflows too tedious or anxiety‑inducing and prefer manual coding except for small tasks.

Safety, Sandboxing, and Secrets

  • Recommended mitigations: no prod creds, strict environment separation (VMs, containers, separate pods), no unrestricted shells, tool‑wrapped commands, and read‑only or short‑lived tokens.
  • Some note agents can behave securely one day and carelessly the next, reinforcing the need for structural protections, not just instructions.

Prompting, Harnesses, and Alignment

  • Explicit prompts like “minimal change,” “no refactors,” or “don’t modify unrelated code” help but don’t fully solve over‑editing.
  • Users report better behavior with:
    • Lower “thinking”/complexity modes.
    • Project‑specific guidelines (AGENTS.md, skills).
    • Quality gates, diff regression checks, and multi‑agent review.
  • One comment highlights research: RL‑based fine‑tuning seems to generalize better than SFT for enforcing minimal editing style.