Tell Claude What NOT to Change When Making Edits
One of the most common frustrations with AI-assisted editing is getting back more changes than you asked for. You wanted a bug fix in one function, but Claude also "improved" the error handling next door and renamed a variable for clarity. The fix? Tell Claude what's off-limits.
Fix the pagination bug in getUserList(). Do NOT change the authentication
middleware, the response format, or any other function in this file.
Being explicit about boundaries works because Claude treats every prompt as an opportunity to be helpful — and sometimes "helpful" means touching things you didn't ask about. A clear exclusion list keeps it focused.
You can scope the constraint however you need:
Refactor this component to use composition API. Keep all prop names,
emitted events, and the template markup exactly as they are.
Add input validation to the create endpoint. Don't modify the update
or delete endpoints, even if they have the same issue.
A few patterns that work well:
- "Only touch X" — whitelist approach, limits Claude to specific functions or files.
- "Don't change any tests" — useful when refactoring implementation but not behaviour.
- "Keep the public API identical" — lets Claude refactor internals freely.
- "Leave comments and formatting as-is" — prevents cosmetic noise in your diff.
The more specific you are about what's off-limits, the cleaner your diffs will be. Constraints aren't limitations — they're focus.
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.