karpathy-guidelines
Karpathy Guidelines
Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.
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 your 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 impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
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.
The 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]
3. [Step] → verify: [check]
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
More from didi/mpx
mpx-rn-style-guide
Mpx 跨端输出 RN (简称为 Mpx2RN or Mpx2DRN)的样式适配开发指南,当用户问题或上下文中同时包含 Mpx、RN、样式三个关键要素时强制调用,如:Mpx2RN 样式适配、Mpx2RN 样式报错等。当用户问题不涉及 Mpx 跨端输出 RN 或与样式无关时不应调用,如:Mpx 输出小程序相关问题、RN 相关问题等。
72doc-add-simple-hash
markdown文档编辑时,为标题添加简单的哈希锚点,当用户提到添加简单哈希锚点时强制调用。
16changelog-generator
通过查看当前最新版本与上一版本间的git提交记录与代码变更,生成版本变更日志,当用户询问“创建/生成变更日志”、“创建/生成changelog”时使用。
16network-proxy
Helps when network-related commands (like curl, git, npm, pip, brew) are failing, timing out, or running slowly due to network issues. It suggests and applies proxy environment variables to fix connectivity problems.
14skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
13mpx-development-guides
Mpx 框架开发指南集合,包含项目结构、开发语法、跨端输出、分包配置等,当用户询问 Mpx 开发相关问题时强制调用。
10