Skip to content
>devspeak
← glossary
patternCommunication Patterns

Avoid unrelated refactors

Tell the agent not to reorganize or tidy up code that has nothing to do with the task, even if it thinks that code could be cleaner.

Start lessonPracticeAsk the tutor about Avoid unrelated refactors
a bit more technical

Keep restructuring, such as renaming, moving, reformatting, or reorganizing code, out of a change unless the task requires it. Mixing cleanup with behavior changes inflates the diff, hides the real fix, and raises regression risk.

picture it

Asking a plumber to fix a leak and coming home to find they also rearranged your kitchen cabinets. Maybe it's better. But now you can't find anything, and you didn't ask.

✗ instead of
fix the typo in the confirmation email, and feel free to tidy up the code while you're there
✓ try
Fix the typo in the booking confirmation email. Avoid unrelated refactors: don't rename, move, or reformat other code. If you spot cleanup worth doing, list it separately for later.
why it matters

Agents often spot improvements and make them unasked. A two-line fix becomes a 40-file change you can't review. If something breaks, you can't tell whether the fix or the cleanup did it.

what your agent might say
agent
Fixed the confirmation typo. I avoided unrelated refactors, but the email module has inconsistent naming. I can clean that up as a separate task if you want.
how you might use it
you → your agent
Fix the confirmation email typo. Avoid unrelated refactors: if you see code worth cleaning up, note it for later instead of changing it.
common mistake

Thinking all cleanup is harmful. Refactoring is valuable, just as its own separate task, with its own review and testing.

builds on
Regression