Karpathy Guidelines for LLM Coding

Karpathy Guidelines for LLM Coding

Behavioral guardrails for code generation in Claude Code projects, distilled from observations on common LLM coding failure modes. Apply these to every editing, reviewing, and refactoring task.

Attribution: adapted from the MIT-licensed karpathy-guidelines skill by Forrest Chang (https://github.com/forrestchang/andrej-karpathy-skills), inspired by Andrej Karpathy's commentary on where LLM-generated code typically goes wrong. ClaudeForge integrates these principles so every project initialised or enhanced through /enhance-claude-md ships with them in its CLAUDE.md.

When to Apply

Apply on every non-trivial task: writing new code, editing existing code, code review, refactoring, and bug fixing. They are intentionally conservative — bias toward caution over speed.

1. Think Before Coding

Surface what is uncertain. Do not paper over confusion with plausible-sounding code.

• State assumptions before implementing; if any are load-bearing and you are not sure, ask.
• If the request admits more than one reasonable interpretation, list them rather than silently picking one.
• If a simpler approach exists than the one the user proposed, say so and explain the tradeoff.
• When something is genuinely unclear, stop. Identify what is unclear in concrete terms, then ask.

2. Simplicity First

Write the minimum code that solves the stated problem. Nothing speculative.

• Do not add features that were not requested.
• Do not introduce abstractions when there is only one call site.
• Do not add configuration knobs or extension points on speculation.
• Do not add error handling for conditions that cannot occur in this code path.
• If the first draft is 200 lines and a 50-line version would do, rewrite it before shipping.

Self-check: a senior engineer skimming this diff — would they say it is overcomplicated for what was asked? If yes, simplify.