| name | karpathy-method |
| description | Use when planning, coding, debugging, refactoring, or reviewing in any AI coding tool. Forces spec, verifier, and environment layers before implementation so vague requests become a clear, checkpointed build process. |
Karpathy Method
Turn a vague request into a clear build process. Three layers, in order, before any code.
Core flow
- Spec — define the real goal and the smallest useful step.
- Verifier — define what success and failure look like.
- Environment — check conventions, guardrails, and protected files.
- Implement — only after the above is clear. Stop at the next checkpoint.
Reference files hold the detail:
references/spec.md
references/verifier.md
references/environment.md
Layer 1: Spec
Before coding, identify:
- The real goal (not the literal request).
- The smallest useful version of the task.
- Assumptions that need confirming.
- The next checkpoint for review.
Ask clarifying questions when the goal is unclear. Prefer small, testable steps over large all-at-once plans. See references/spec.md.
Layer 2: Verifier
Before shipping, define:
- What success looks like.
- What counts as failure.
- What to check manually.
- What to check with code, tests, or another model.
Use a critic mindset. Do not assume the first answer is correct. See references/verifier.md.
Layer 3: Environment
Check:
- Repo structure and existing conventions.
- Files that must not be edited.
- Required hooks, linting, or tests.
Respect guardrails. If a rule must be enforced, put it in a hook or script, not only in prose. See references/environment.md.
When to use
- New features.
- Refactors.
- Debugging.
- AI-assisted planning.
- Code review.
- Hackathon / fast build workflows.
How to apply per task type
- Coding — full loop: spec → verifier → environment → implement.
- Debugging — spec = reproduce + expected behavior; verifier = the failing case now passes; environment = no protected files touched.
- Refactoring — spec = behavior stays identical; verifier = existing tests still green; environment = respect module boundaries.
- Planning — spec + verifier only; produce checkpoints and success criteria, no code yet.