| name | karpathy-guidelines |
| description | Guidelines for effective LLM-assisted coding based on Andrej Karpathy's observations.
Use this skill when writing code with an LLM to avoid common pitfalls: overcomplication,
bloated abstractions, dead code, wrong assumptions, and 1000-line solutions that should
be 100 lines. Applies to all coding tasks. Invoke with /karpathy-guidelines.
|
Karpathy Guidelines
Behavioral guidelines to reduce common LLM coding mistakes.
Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.
1. Think Before Coding
Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
- State assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them—don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for edge cases the prompt doesn't mention. Don't pre-handle blank lines, missing fields, or malformed input unless asked.
- No docstrings or type annotations unless the surrounding code already uses them or the user asks. Documentation is a feature—don't add it speculatively.
- If 200 lines could be 50, rewrite it.
Test: Re-read the user's request. Can you justify every line you wrote by pointing to something they asked for? If not, delete it.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it—don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
Test: Every changed line should trace directly to the user's request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → Write tests for invalid inputs, then make them pass
- "Fix the bug" → Write a test that reproduces it, then make it pass
- "Refactor X" → Ensure tests pass before and after
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
Strong success criteria enable independent looping. Weak criteria ("make it work") require constant clarification.
These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
