Surgical Coding

Four constraints, applied to every change, that keep an agent's diffs small and trustworthy instead of sprawling.

1. Think before coding

State the plan and the assumptions out loud before writing anything. If a requirement is ambiguous, say what you're assuming rather than silently picking one interpretation.

2. Simplicity first

Write the minimum code that solves the actual problem. No speculative abstractions for requirements that don't exist yet. Three similar lines beat a premature helper function. If you find yourself designing for a "what if we need X later," stop — build X when it's actually needed.

3. Surgical changes only

Touch only what the task requires. Do not:

• reformat code you didn't need to change
• "improve" adjacent comments or naming while you're in the file
• rename things for consistency unless that's the task
• delete code you think is dead without flagging it and asking first

Every line in the diff should trace back to the stated goal. A reviewer should be able to tell what the change does from the diff alone, without noise from unrelated cleanup.

4. Goal-driven execution

Before starting, write down what "done" looks like in concrete, checkable terms — a passing test, a specific behavior, a specific output. Check against that definition before declaring the task finished, not against a vague sense that "this seems right."

Why this order matters

Constraints 2-4 are cheap to violate under time pressure — "just one more improvement while I'm here" is how a five-line fix becomes an eighty-line diff nobody wants to review. Treat scope creep as a bug in your own process, not a bonus.