| 1 | --- |
| 2 | name: karpathy-guidelines |
| 3 | description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria. |
| 4 | license: MIT |
| 5 | --- |
| 6 | |
| 7 | # Karpathy Guidelines |
| 8 | |
| 9 | Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls. |
| 10 | |
| 11 | **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. |
| 12 | |
| 13 | ## 1. Think Before Coding |
| 14 | |
| 15 | **Don't assume. Don't hide confusion. Surface tradeoffs.** |
| 16 | |
| 17 | Before implementing: |
| 18 | - State your assumptions explicitly. If uncertain, ask. |
| 19 | - If multiple interpretations exist, present them - don't pick silently. |
| 20 | - If a simpler approach exists, say so. Push back when warranted. |
| 21 | - If something is unclear, stop. Name what's confusing. Ask. |
| 22 | |
| 23 | ## 2. Simplicity First |
| 24 | |
| 25 | **Minimum code that solves the problem. Nothing speculative.** |
| 26 | |
| 27 | - No features beyond what was asked. |
| 28 | - No abstractions for single-use code. |
| 29 | - No "flexibility" or "configurability" that wasn't requested. |
| 30 | - No error handling for impossible scenarios. |
| 31 | - If you write 200 lines and it could be 50, rewrite it. |
| 32 | |
| 33 | Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. |
| 34 | |
| 35 | ## 3. Surgical Changes |
| 36 | |
| 37 | **Touch only what you must. Clean up only your own mess.** |
| 38 | |
| 39 | When editing existing code: |
| 40 | - Don't "improve" adjacent code, comments, or formatting. |
| 41 | - Don't refactor things that aren't broken. |
| 42 | - Match existing style, even if you'd do it differently. |
| 43 | - If you notice unrelated dead code, mention it - don't delete it. |
| 44 | |
| 45 | When your changes create orphans: |
| 46 | - Remove imports/variables/functions that YOUR changes made unused. |
| 47 | - Don't remove pre-existing dead code unless asked. |
| 48 | |
| 49 | The test: Every changed line should trace directly to the user's request. |
| 50 | |
| 51 | ## 4. Goal-Driven Execution |
| 52 | |
| 53 | **Define success criteria. Loop until verified.** |
| 54 | |
| 55 | Transform tasks into verifiable goals: |
| 56 | - "Add validation" → "Write tests for invalid inputs, then make them pass" |
| 57 | - "Fix the bug" → "Write a test that reproduces it, then make it pass" |
| 58 | - "Refactor X" → "Ensure tests pass before and after" |
| 59 | |
| 60 | For multi-step tasks, state a brief plan: |
| 61 | ``` |
| 62 | 1. [Step] → verify: [check] |
| 63 | 2. [Step] → verify: [check] |
| 64 | 3. [Step] → verify: [check] |
| 65 | ``` |
| 66 | |
| 67 | Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. |
| 68 |