Skip to main content
When you ask an LLM to fix a bug, you expect a focused diff. What you often get instead is a sweeping “improvement” that touches comments, reformats whitespace, adds type hints, upgrades validation logic, and restructures boolean returns — none of which you asked for. Surgical Changes enforces a simple discipline: every changed line must trace directly to the user’s request, nothing more.

Two rules

Don’t touch what you shouldn’t

When editing existing code:
  • Don’t “improve” adjacent code, comments, or formatting
  • Don’t refactor things that aren’t broken
  • Match existing style, even if you’d do it differently
  • If you notice unrelated dead code, mention it — don’t delete it

Clean up your own orphans

When your changes create unused artifacts:
  • Remove imports, variables, and functions that your changes made unused
  • Don’t remove pre-existing dead code unless explicitly asked

The test

Every changed line should trace directly to the user’s request. If you can’t answer “why did this line change?” with a direct reference to the task, the change shouldn’t be there.

Drive-by refactoring example

Request: “Fix the bug where empty emails crash the validator”
What LLMs do wrong — “fixing” adjacent username logic, adding a docstring, improving email validation beyond the bug
Unasked-for changes: improved email validation, added username length and alphanumeric checks, changed comments, added a docstring.
The correct approach — only the lines that fix the empty email crash
Only changed: the specific lines that fix empty email handling.

Style drift example

Request: “Add logging to the upload function”
What LLMs do wrong — changing quote style, adding type hints, adding a docstring, reformatting whitespace
Unasked-for changes: type hints, docstring, quote style changed from ' to ", whitespace reformatted, boolean return logic restructured.
The correct approach — match existing style, add only the logging lines
Matched: single quotes, no type hints, existing boolean pattern, original spacing style.

When this principle is working

  • Diffs are small and focused — only requested changes appear
  • PRs are clean with no drive-by refactoring or “improvements”
  • Code style is consistent within each file, even across contributors
  • Every line in the diff has an obvious reason for changing