Hands Tied, Lips Sealed

When you let AI edit your code, the worry isn’t that it can’t do the job. The worry is that it’s too eager. Ask it to fix one bug and it helpfully “improves” the three functions next door, then doesn’t say a word, like nothing happened.

Even Andrej Karpathy got fed up. In January he posted a long list of charges against LLMs that write code. They guess on your behalf, then charge ahead without checking. They don’t ask, they don’t flag anything, and they don’t push back when they should. They love making things complicated, turning a 100-line job into 1,000 lines. And they like to tinker with code and comments you never asked them to touch.

The very next day, somebody turned that list of charges into a rulebook.

What it is

The project is andrej-karpathy-skills. Karpathy’s name is on it, but he didn’t write it. The author is Jiayuan Zhang (forrestchang on GitHub), who’s now building an open-source project called Multica. The repo was created on January 27, and as of today it has 230,000 stars and 23,000 forks. The README says MIT license.

Strip it down and the whole project is one file: CLAUDE.md, 65 lines long. Claude Code reads it before every job, like the employee handbook you memorize before your first shift. Two hundred thirty thousand stars for 65 lines. Per line, that may be the most valuable file on GitHub.

This site has one of those too. It’s called WRITING.md, and it tells the AI how to write my posts. The one you’re reading followed it.

The four rules

1. Think before coding. Don’t guess for me. If you’re not sure, ask. If a request could mean several things, lay them all out instead of quietly picking one. If there’s a simpler way, say so, and push back when it’s warranted.
2. Simplicity first. Enough is enough. No features nobody asked for, no abstractions for code used once, no “flexibility” nobody will use. If you wrote 200 lines and 50 would do, rewrite it. Ask yourself one question: would a senior engineer call this overcomplicated?
3. Surgical changes. Hands off the neighboring code, comments and formatting, no matter how much they need a tidy. If it isn’t broken, don’t refactor it. Match the style that’s already there. If you spot dead code somewhere else, mention it, don’t delete it. The whole test fits in one line: every changed line has to trace back to what the user asked for.
4. Goal-driven execution. Turn “fix the bug” into a goal you can check: first write a test that reproduces the bug, then make it pass.

Put plainly, it’s the four rules the foreman lays down on an apprentice’s first day: don’t overthink it, don’t mess around, don’t touch other people’s stuff, and check your own work before you hand it in.

How to install it

Two ways. One is as a Claude Code plugin, which covers all your projects:

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

The other covers a single project. Download the file into the project root:

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

If your project already has a CLAUDE.md, don’t use that one, because it will overwrite yours. The README has a version that appends instead. Cursor users get a ready-made Cursor rule in the repo too.

The repo has since moved under multica-ai, while the README commands still say forrestchang, the original account. I checked: the old address forwards to the new repo, and the curl command still downloads fine.

Does it work?

A content creator ran a small experiment. They took a 37-line order-export script they’d written and set two tasks. The model was Alibaba’s Qwen (qwen3.7-plus), and each task ran twice with the rules and twice without.

Task one: fix a bug. When the amount was empty, the script crashed. With the rules, both runs changed exactly one line: amount = float(o["amount"]) became a version that returns 0.0 for an empty value. Without the rules, one run changed 5 lines and the other changed 8, and one of them also reformatted the dates on the side and never mentioned it.

On this one, the rules earned their keep.

Task two: speed it up. The whole request was one sentence: “The export is too slow, optimize it for me.” How slow, slow where, how fast it needed to be: not a word. This is exactly when rule one is supposed to step up. If you’re not sure, ask first.

Both runs with the rules asked nothing. They went straight to rewriting the entire file, and along the way deleted the comment at the top that said “don’t touch.”

Better still, the repo’s own EXAMPLES.md illustrates “think before coding” with this exact situation. The user says “make the search faster,” and the AI never asks which kind of faster, just piles on caching, indexes and async. The right move, per the example, is to ask first: which kind of faster do you mean?

The answer was printed in the textbook, and it still flunked the exam.

A few honest notes

• It ties the hands, but it can’t unseal the lips. It can keep the size of the change in check. Asking when it should ask? Writing that into a file doesn’t make it happen. When the request is vague, the problem is the request, and you still have to spell it out yourself.
• The sample is tiny. Two runs per group, testing this rulebook with Qwen, not Claude Code itself. Take it as a data point, not a verdict.
• If you want it to ask first, one line saying “if unsure, ask” isn’t enough. The Agent Skills set I wrote about last time has interview-me, which turns asking into a step of its own: one question at a time, until it’s 95% sure what you want.
• The file says so itself: these rules choose caution over speed. For a typo fix, you don’t need all the ceremony.

Last word

Anyone who’s trained an apprentice dreads two kinds. One has busy hands and wants to fix everything. The other has a sealed mouth and never asks, even when lost. This rulebook mostly cures the first kind. The second kind is on the foreman.

If you can’t pry its mouth open, open yours first. Hand out the job clearly, and it won’t have to guess.