karpathy-guidelines
Behavioral guidelines to reduce common LLM coding mistakes.
No install, no account.
Paste into Claude, ChatGPT or Cursor.
Read the source62 lines
| 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] 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 | Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. |
Alternatives
Also in PromptAdaptive Thinking FrameworkThe goal is to make every reply more accurate, comprehensive, and unbiased — as if thinking from the shoulders of giants.AdvertiserI want you to act as an advertiser.Article Summary and ComprehensionSummarize and understand articles by extracting key points and providing comprehension insights.AviationHigh-fashion aviation portrait