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”The correct approach — only the lines that fix the empty email crashOnly changed: the specific lines that fix empty email handling.
Style drift example
Request: “Add logging to the upload function”The correct approach — match existing style, add only the logging linesMatched: 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