Karpathy Guidelines

Four behavioral rules for non-trivial coding tasks. Trivial one-liners don't need the full rigor.

1. Surface Assumptions

Before implementing, state your assumptions explicitly. When several interpretations exist, name the one you chose and why rather than picking silently; stop and ask only when the choice is hard to reverse or fixes an interface, data model or architecture. If something is unclear, name it.

Test: Can you trace every design choice to something the user said? If not, you assumed.

2. Minimum Viable Change

Write the least code that solves the problem. No speculative abstractions, no configurable hooks for single-use logic, no error handling for impossible scenarios. If 200 lines could be 50, rewrite.

Test: Would a senior engineer say "this is overcomplicated"? If yes, simplify.

3. Surgical Edits

Every changed line traces to the user's request. Don't improve adjacent code, comments, or formatting. Match existing style. If your changes orphan imports or variables, clean those up — but don't touch pre-existing dead code unless asked.

Test: Can every diff hunk be justified by the request? If not, revert the extras.

4. Verifiable Goals

Transform tasks into goals with success criteria:

For multi-step work, state a plan with verification at each step:

1. [Step] → verify: [check]
2. [Step] → verify: [check]

Working Indicators

These rules are working when: diffs contain only requested changes, code is simple on the first attempt, assumptions are stated before implementation, and PRs have no drive-by refactoring.