Use Negative Constraints to Tell Claude What NOT to Touch
Claude tries to be thorough — which sometimes means it changes things you didn't want changed. Negative constraints draw a clear line around what's off-limits before Claude starts working, so you don't have to undo surprises after.
> fix the timezone bug in the scheduling module — but don't change
> the database schema or any existing API response formats
Without that constraint, Claude might "helpfully" add a timezone column to the database or change the API to return UTC. With it, Claude fixes the bug within the existing structure.
Useful negative constraints for common scenarios:
> refactor this service class for readability — but don't change
> any method signatures, don't rename anything public, and don't
> split it into multiple files
> add pagination to the users endpoint — but don't change the
> existing response format, just add pagination metadata alongside it
> optimize this query — but don't add any new indexes (we need
> DBA approval for schema changes)
> update the frontend component — but don't touch the CSS, only
> change the JavaScript logic
You can combine negative constraints with positive instructions for precise control:
> add input validation to the checkout form. DO validate all fields
> on the server side. DON'T add client-side validation — we handle
> that separately with a different library.
> clean up this controller. DO extract business logic into a service.
> DON'T change the route definitions or middleware. DON'T modify
> the form request classes.
This is especially important for:
- Shared code — "don't change the interface other modules depend on"
- Reviewed code — "don't touch files that were already approved in this PR"
- Sensitive areas — "don't modify the payment processing logic"
- Schema changes — "don't create migrations without asking first"
Tell Claude what's out of bounds and it stays within them. Negative constraints are cheaper than reverting changes.
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.
After Claude makes changes to your code, ask it to explain what it did and why it made specific choices. This turns every coding task into a learning opportunity — you understand the reasoning behind the approach, learn patterns you can apply yourself, and catch any decisions you disagree with before moving on.