Tell Claude to Do Less When It Over-Engineers or Adds Things You Didn't Ask For
Claude's biggest failure mode isn't doing too little — it's doing too much. You ask for a one-line bug fix and get a three-file refactor with new abstractions. The fix is simple: tell Claude to do less.
"Fix the off-by-one error in the pagination. Only change what's needed —
don't refactor, don't add comments, don't improve anything else."
Claude stays focused. One line changed, one bug fixed, nothing else touched.
This is a problem in several scenarios:
# You asked for a bug fix, Claude rewrote the function
"Just fix the null check on line 42. Don't restructure the method."
# You asked for one feature, Claude added three
"Add the search endpoint. Don't add filtering, sorting, or pagination
yet — just the basic search."
# You asked for a test, Claude refactored the code to be 'more testable'
"Write a test for this function as-is. Don't change the implementation."
# You asked for a small change, Claude 'improved' nearby code
"Update the error message on line 15. Don't touch any other lines
in this file."
Useful phrases that keep Claude minimal:
- "Only change what I asked for" — prevents scope creep
- "Don't refactor" — stops unnecessary restructuring
- "Minimal change" — fewest lines edited
- "Don't add comments or docs" — skips unsolicited documentation
- "Don't improve the surrounding code" — leaves neighbors alone
- "Just the fix, nothing else" — laser focus
You can also put this in your CLAUDE.md for permanent effect:
When fixing bugs, make the minimum change needed. Don't refactor
surrounding code, add comments, or improve things that weren't
part of the request.
The minimalism instinct matters most for:
- Bug fixes — where extra changes hide what actually fixed the problem
- Hotfixes — where every changed line is a risk
- Code you don't own — where unexpected changes surprise the author
- Large PRs — where unrelated changes make review harder
The best change is the smallest one that solves the problem — tell Claude "do less" when it tries to do more.
via Claude Code
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.