@servasyy_ai: Andrej Karpathy: 'Claude's errors: 90% from missing context, not weak model capability.' Without `CLAUDE.md`, error rate is 41%. With 4 basic rules, error rate drops to 11%. Using the following 12 rules, error rate…

X AI KOLs Timeline Tools
claude ai-coding best-practices context error-rate rules

Summary

Andrej Karpathy points out that 90% of Claude's errors come from missing context, and shares 12 rules (such as think before writing code, simplicity first, etc.) that reduce the error rate from 41% to 3%, emphasizing that discipline and effective context management are more important than frameworks.

Andrej Karpathy: 'Claude's errors: 90% from missing context, not weak model capability.' Without `CLAUDE.md`, error rate is 41%. With 4 basic rules, error rate drops to 11%. Using the following 12 rules, error rate drops to 3%. These are the 12 rules distilled by senior engineers: 1. Think before writing code State assumptions first, don't guess. The model can't read minds, don't expect it to automatically know what you mean. 2. Simplicity first Minimum code, no speculative abstraction. Once you ask Claude to add something for 'future flexibility', you might end up with 200 lines of code to delete next quarter. 3. Surgical modifications Only change what must be changed. Don't let it optimize nearby code along the way; that's how PRs bloat. 4. Goal-driven execution First define success criteria, then loop until verified. Without success criteria, Claude either loops infinitely or stops prematurely. 5. Use the model only for judgment tasks For example, classification, drafting, summarization, extraction. Don't let the model handle routing, retries, status code handling, deterministic transformations. What code can answer, let code answer. 6. Token budgets are not suggestions 4000 per task, 30000 per session. When debugging for a long time and reaching message 40, Claude will re-suggest a fix that was already rejected in message 5. 7. Expose conflicts, don't compromise on averages Two modes in the codebase? Choose one. If Claude mixes both, errors will be swallowed twice. 8. Read before write First read exports, callers, shared utilities. Claude is likely to add a duplicate function next to an existing identical one just because it didn't read it. 9. Tests should verify intent, not just behavior If business logic changes but tests don't fail, the tests are wrong. All 12 tests written by Claude could pass even if the function actually only returns a constant. 10. Checkpoint every important step Claude might continue steps 5 and 6 on a state that was already broken at step 4, and no one notices, wasting an hour. 11. Match codebase conventions If the project uses class components, don't silently change to hooks. Test patterns might depend on `componentDidMount`, and hooks can break it without necessarily exposing the issue. 12. Failures should be loudly exposed 'Successfully completed', but 14% of records were silently skipped—this is the worst kind of bug. Expose uncertainty, don't hide it. What truly compounds is not the next framework, but: - Treat `CLAUDE.md` as cross-session organizational memory - Improve based on eval, not gut feeling - Value checkpoints over blind speed - Explicitly expose conflicts instead of silently mixing - Discipline always matters more than framework - One repo, one rules file, no exceptions Get ahead with these rules before this becomes mainstream consensus on AI Twitter. Study it
Original Article
View Cached Full Text

Cached at: 05/19/26, 12:44 PM

Andrej Karpathy: “90% of Claude’s errors come from missing context, not weak model ability.”

Without CLAUDE.md, the error rate is 41%.
With 4 basic rules, the error rate drops to 11%.
With the following 12 rules, the error rate drops to 3%.

These are the 12 rules ultimately distilled by senior engineers:

  1. Think before writing code
    State assumptions first—don’t guess. The model can’t read your mind, don’t expect it to automatically know what you mean.

  2. Simple first
    Least code, no speculative abstraction. Once you ask Claude to add something for “future flexibility,” you might end up with 200 lines that get deleted next quarter.

  3. Surgical changes
    Only modify what must be modified. Don’t let it “clean up” adjacent code; that’s how a PR balloons.

  4. Goal-driven execution
    Define success criteria first, then loop until validation passes. Without success criteria, Claude either loops forever or stops too early.

  5. Use the model only for judgment tasks
    For example: classification, drafting, summarization, extraction. Don’t let the model handle routing, retries, status code handling, or deterministic transformations. If code can answer it, let code answer it.

  6. Token budget is not a suggestion
    Single task: 4,000 tokens; single session: 30,000. By message #40 during a long debugging session, Claude will re-suggest a fix you already rejected back at message #5.

  7. Surface conflicts, don’t average them
    Two patterns in the codebase? Pick one. If Claude mixes them together, errors get swallowed twice.

  8. Read before you write
    First read exports, callers, shared utilities. Claude is very likely to add a duplicate function right next to an existing one, simply because it didn’t read that part.

  9. Tests should verify intent, not just behavior
    If the business logic changes but the test doesn’t fail, the test is wrong. Claude can write 12 tests that all pass, even if the function actually returns only a constant.

  10. Checkpoint every important step
    Claude might complete steps 5 and 6 on top of a corrupted state from step 4, wasting an hour before anyone notices.

  11. Match codebase conventions
    If the project uses class components, don’t silently switch to hooks. The test pattern might depend on componentDidMount; hooks can break it without obvious symptoms.

  12. Fail loudly
    “Successfully completed” while 14% of records are silently skipped—that’s the worst kind of bug. Surface uncertainty; don’t hide it.

What truly compounds is not the next framework, but:

  • Using CLAUDE.md as cross-session organizational memory
  • Improving based on eval, not gut feeling
  • Valuing checkpoints over raw speed
  • Explicitly surfacing conflicts instead of blending them silently
  • Discipline over frameworks, always
  • One repo, one rules file, no exceptions

Before this becomes the consensus on AI Twitter, get ahead by a few rules.

Study it.

Similar Articles

@xiaohu: Claude Code's father's own CLAUDE.md is now just two lines... Claude Code team discusses "less is more" sharing how to communicate with models as capabilities increase: "Don't fight the model by adding more, because each generation of models gets stronger. What you painstakingly build today will soon be useless."

X AI KOLs Timeline

Claude Code team shares best practices: CLAUDE.md should be as short as possible and regularly cleared; insists on CLI over GUI because models improve too fast; using AI to fix bugs is already remarkably efficient. Core strategy: subtract, keep configuration light, and trust model capabilities.