@yaohui12138: Karpathy released a GitHub open-source project that truly amazed me. The project is called andrej-karpathy-skills, with 130k+ stars on GitHub. I'd call it the most useful AI engineering project of 2026. The problem it solves is extremely precise: making Cl…

Karpathy released a GitHub open-source project, and it absolutely blew my mind.

The project is called andrej-karpathy-skills, with over 130k stars on GitHub. I’d call it the most useful AI engineering project of 2026.

It solves a very precise problem: making Claude Code stop writing bad code.

How impressive is this project?

Bottom line: a 4KB text file that slashes AI coding errors by 90%.

Karpathy himself says he now writes 80% of his code with Claude, but AI often makes several typical mistakes:

• Guessing requirements without asking
• Over-engineering with tons of unused abstractions
• Refactoring B, C, and D while fixing A
• Just making the code run, regardless of whether the goal was met

This project is specifically about putting guardrails on Claude Code, using 4 behavioral rules to constrain AI coding behavior.

Core highlight: 4 rules change everything

The entire project is a CLAUDE.md file with only 4 rules, but each one directly hits the pain points of AI coding.

1. Think Before Coding – Think first, then code

The biggest problem with AI is that it’s “too obedient”—it writes whatever you say without questioning.

This rule requires: explicitly state assumptions, weigh tradeoffs, and ask directly if unsure.

Instead of “I guess you want this,” it becomes “I understand your need is A, but plan B might be better—which do you prefer?”

2. Simplicity First – Minimal implementation first

AI loves to show off. You ask for a login feature, and it writes a full OAuth 2.0 + JWT + refresh token + permission system.

This rule enforces: write only the minimum code that solves the current problem.

No speculative abstractions, no future features, no over-engineering.

One user feedback: after using this rule, code diffs went from hundreds of lines to dozens, making review much easier.

3. Surgical Changes – Precise, surgical modifications

This is my favorite.

AI has a bad habit: you ask it to fix a bug, and it “improves” the entire file’s naming style, indentation, and comments along the way.

This rule requires: only change the parts the user asked for, strictly matching the original code style.

Don’t touch unrelated files, don’t refactor on the side, don’t add changes that “look better.”

One developer tested it: after enabling this, git diffs went from “full-screen red and green” to “3 lines of precise changes.”

4. Goal-Driven Execution – Execute driven by goals

AI often finishes writing code and calls it done, but “code that runs” ≠ “task completed.”

This rule requires: translate the task into verifiable goals/tests/success criteria, then loop: execute, verify, iterate.

Don’t stop until the goal is truly achieved.

This transforms AI from a “code generator” into a “problem solver.”

Real results: the community is blown away

This project is trending on X, and developers’ feedback is highly consistent:

• Code quality leap: diffs are more compact and cleaner; overbuilding and side changes are drastically reduced.
• Error rate plummets: one person measured a drop from 41% to 11%, and down to 3% after further optimization.
• Chinese community praise: “must-have skills,” “Claude/Cursor #1 practical skill,” “just drop it into your project.”

Many people directly @ friends with recommendations: “Put this CLAUDE.md in, and Claude instantly acts like a different person—writes more reliable code, doesn’t mess things up, doesn’t guess.”

How to use: absurdly simple

This is the simplest AI engineering optimization solution I’ve ever seen:

Method 1: directly curl the CLAUDE.md into your project root.

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Method 2: one-click install via Claude Code / Cursor plugin.

Supports mainstream AI coding tools like Claude Code, Cursor, etc.

Completely open source (MIT license), ready to use.

As a developer with a product manager background, I see more than just 4 rules—I see deep insight into AI coding behavior.

What Karpathy essentially did is: establish first principles for AI coding. He wrote his understanding of AI programming into a file.

It’s not about teaching AI how to write code (it already knows), but teaching AI when to ask, when to stop, and when to simplify.

These 4 rules are like PRD principles a PM gives to a dev team:

• Requirements unclear? Ask first.
• Functionality sufficient? Don’t over-design.
• Changing requirements? Only change what’s needed.
• Done? First verify if the goal was met.

How can this help us?

If you’re an indie developer or in a small team, this project can directly boost your AI collaboration efficiency:

• Reduce rework: AI no longer guesses requirements; the code matches expectations better.
• Lower review cost: changes are precise; you don’t have to search for real changes among unrelated modifications.
• Improve code quality: minimal implementation means fewer bugs and better maintainability.
• Accelerate iteration: goal-driven execution makes AI actually solve problems, not just generate code.

For medium-to-large projects, this is a key step to make Claude Code truly “production-ready.”

My personal experience

I deployed this CLAUDE.md in several of my projects. The most intuitive feeling is:

AI got smarter.

Previously, it was like an obedient intern—do whatever you say, often doing it wrong.

Now it’s like an experienced colleague who proactively asks, “Are you sure you want to do this? I have a simpler plan.”

Code diffs are cleaner.

Previously, a small requirement could change dozens of files; now it’s precise, only 3-5 lines.

My focus has shifted.

I used to spend 60% of my time reviewing AI code and fixing bugs.

Now I spend 80% of my time thinking about product logic. AI has truly become a productivity tool.

Finally

This project is hailed as a “phenomenal” black-magic tool in the AI coding field for 2026.

Small file, huge impact.

If you’re using Claude Code / Cursor to write code, I strongly recommend dropping this CLAUDE.md into your project root.

GitHub URL: https://github.com/forrestchang/andrej-karpathy-skills

Everyone who tried it is already in “deployed across all projects” mode.

As a developer who works with AI every day, my advice is: don’t hesitate, just use it.

Source: https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md # CLAUDE.md Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.

**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.

--- **These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.