Karpathy Guidelines

Karpathy Guidelines

Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.

"The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should."

"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks (obvious one-liners, typo fixes), use judgment. For non-trivial work — anything that could cause regressions or require rework — apply these fully.

1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:

• State your assumptions explicitly. If uncertain, ask.
• If multiple valid 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.

Banned behaviors:

• Picking a silent interpretation of an ambiguous request and running with it
• Hiding confusion behind "I'll figure it out as I go"
• Implementing before surfacing a tradeoff that would change the decision

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.

The test: Would a senior engineer say this is overcomplicated? If yes, simplify.

Banned patterns:

• Generic base classes for a problem with 1 concrete case
• Config objects with 15 fields when 3 are ever used
• "For future flexibility" arguments that add complexity now
• Wrapper functions that do nothing but call another function

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 explicitly asked.

The test: Every changed line should trace directly to the user's request. If you can't explain why a line changed, undo it.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform imperative tasks into verifiable goals:

For multi-step tasks, state a brief plan with explicit verification:

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Strong success criteria let the agent loop independently. Weak criteria ("make it work") require constant clarification and usually produce wrong results.

How to Know It's Working

These guidelines are working when you see:

• Fewer unnecessary changes in diffs — Only requested changes appear
• Fewer rewrites due to overcomplication — Code is simple the first time
• Clarifying questions come before implementation — Not after mistakes
• Clean, minimal PRs — No drive-by refactoring, no "improvements"

AGENTS.md / CLAUDE.md Snippet

Add this to any project's AGENTS.md, CLAUDE.md, or .github/copilot-instructions.md to make all AI tools follow these rules on that project:

## Coding Behavior Guidelines (Karpathy)

1. **Think Before Coding** — State assumptions explicitly. If multiple interpretations exist, ask. Push back when a simpler approach exists.
2. **Simplicity First** — Minimum code that solves the problem. No speculative features, no single-use abstractions.
3. **Surgical Changes** — Touch only what you must. Match existing style. Mention unrelated dead code, don't delete it.
4. **Goal-Driven Execution** — Transform tasks into verifiable goals. Loop until success criteria are met.

Pipeline Integration

These rules are already embedded in key pipeline agents — this skill makes them explicit and invocable on demand:

Use /karpathy-guidelines when:

• Onboarding a new project (add AGENTS.md snippet)
• A PR has unexpected drive-by changes
• A implementation came back overengineered
• You want to re-center an agent that's going in circles

Copilot CLI Operations

Signal

• Invoked as a reminder/overlay: KARPATHY_DONE: [principle applied]
• No blocking signal — this is a behavioral overlay, not a pipeline step