How to Use the Karpathy Loop to Make AI Actually Improve Itself
This guide breaks down what the loop actually is, why it works, and how to build your own version with exact prompts you can use today. Total hands-on time is about an hour.
Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu
WHAT YOU NEED
Claude Code or any AI coding agent with terminal access. Claude Pro subscription at $20 a month minimum.
A project with a measurable outcome. This can be a codebase with tests, a model with a benchmark, a content pipeline with a quality score, or any system where you can check whether the output got better or worse with a command.
That is it. The loop works on code, on writing, on research, on data pipelines. Anything where you can define "better" in a way a script can verify.
WHY VIBE CODING HITS A CEILING
Here is the workflow most people use with AI coding tools right now. You describe what you want. The AI generates code. You paste the error back. The AI patches it. Something else breaks. You paste that error. It patches again. This is vibe coding.
Day 1 it feels like magic. Day 30 you are spending more time supervising the AI than you used to spend writing the code yourself. And the core problem is structural. You are asking the AI to generate and verify its own work in the same session. A model grading its own homework always gives itself an A.
Karpathy put it simply at Sequoia's AI Ascent 2026: "You are not allowed to introduce vulnerabilities because of vibe coding. You are still responsible for your software, just as before." The fix is not better prompts. The fix is a better loop.
WHAT THE KARPATHY LOOP ACTUALLY IS
The Karpathy Loop has one rule: the thing that generates the work and the thing that checks the work must be completely separate. The generator cannot touch the verifier. The verifier cannot touch the generator. And a human writes the instructions that both of them follow.
In Karpathy's autoresearch repo this plays out across 3 files:
train.py is the file the agent is allowed to edit. This is where the model architecture, the optimizer, and the training loop live. The agent makes changes here and only here.
prepare.py is the evaluation code. The agent cannot touch this file. It runs the benchmark, calculates the score, and reports whether the change made things better or worse. Because the agent cannot edit the test, it cannot cheat. It cannot make the evaluation easier instead of making the model better.
program.md is the instruction file the human writes. It tells the agent what to optimize, what constraints to respect, and when to stop. The agent reads this at the start of every cycle.
Each cycle runs one experiment. The agent reads the instructions, makes one change to train.py, runs the training, checks the score against prepare.py, records what it learned, and starts the next cycle. After 126 cycles overnight, the system surfaced optimizations Karpathy said he had not applied in more than 20 years of working on similar problems.
The power is not in any single experiment. It is in the compounding. Each cycle learns from the last one. The agent records what worked and what did not. By cycle 50 it is making decisions informed by 49 previous experiments. By cycle 100 it has more empirical data about your specific system than you could gather in a month of manual work.
THE GENERATION-VERIFICATION LOOP (THE CORE PATTERN)
Strip away the ML specifics and the Karpathy Loop is a pattern you can apply to anything. It has 4 parts:
Part 1 is the generator. This is the AI doing the work. Writing code, drafting content, building features, running experiments. It gets one job and one set of constraints.
Part 2 is the verifier. This is a separate process that checks the work. It can be a test suite, a benchmark, a linter, a second AI agent, or a bash script. The critical rule is that the generator cannot modify the verifier. If it could, it would optimize for passing the test instead of doing good work.
Part 3 is the memory. After each cycle the agent records what it tried, what happened, and what it learned. This memory persists across cycles so the agent never repeats a failed experiment.
Part 4 is the human instruction. You write what "done" looks like, what the boundaries are, and what the agent should never do. This is the only file you maintain. Everything else the loop handles.
Here is the prompt to set up this pattern in Claude Code for any project:
"I want you to run an improvement loop on this project. Here are the rules:
You may only edit files in [src/ or whatever your working directory is]. You may never edit files in [tests/ or whatever your verification directory is]. Before each change, state your hypothesis in one sentence. After each change, run [your test command] and record the result. If the change improved the score, keep it and record why it worked. If the change made things worse, revert it and record why it failed. Store all experiment notes in experiments.md with the cycle number, hypothesis, result, and lesson. Do not repeat an experiment that already failed unless you have a specific reason the outcome would differ. Run 10 cycles. After each cycle check whether the score improved. If 3 cycles in a row show no improvement, stop and report what you learned."
HOW TO BUILD YOUR OWN LOOP
Step 1: Define your verifier.
This is the most important decision in the entire process. If your verifier is weak, your loop optimizes for the wrong thing. If your verifier is strong, the loop produces genuinely better work every cycle.
For a codebase: your test suite is the verifier. The command might be "npm test" or "pytest" or "go test ./..." and the score is the number of passing tests plus the absence of lint errors.
For a benchmark: the evaluation script is the verifier. Karpathy used bits-per-byte on a validation set. Your equivalent might be accuracy on a held-out dataset, latency of an API endpoint, or bundle size of a frontend build.
For content: a second AI agent is the verifier. It reads the output against a rubric you wrote and scores it. The generator never sees the rubric directly.
For anything else: write a bash script that exits 0 if the work passes and exits 1 if it does not. The simpler the verifier, the harder it is to game.
Here is a prompt for setting up a content quality verifier:
"You are a verifier. You receive a piece of content and a rubric. Score the content from 1 to 10 on each criterion in the rubric. Be harsh. If something is mediocre, score it as mediocre. Do not grade generously.
Rubric:
- Does it open with a specific claim or number, not a generic statement? (1-10)
- Is every paragraph under 3 sentences? (1-10)
- Are there zero AI-sounding words like leverage, utilize, streamline, robust? (1-10)
- Does every step include a specific action the reader can take? (1-10)
- Is the total length between 1,500 and 2,500 words? (1-10)
Output your scores and one sentence explaining each. Then output a single PASS or FAIL based on whether all scores are 7 or above."
Step 2: Separate the files.
Create a clear boundary between what the agent can edit and what it cannot. In Karpathy's repo this was train.py (editable) versus prepare.py (read-only). In your project it might be src/ (editable) versus tests/ (read-only). Or drafts/ (editable) versus rubric.md (read-only).
The separation is the whole point. Without it the agent eventually learns to weaken the test instead of strengthening the work.
Step 3: Write your program.md.
This is the instruction file the loop reads at the start of every cycle. Keep it short. Here is a template:
"Goal: [what you are optimizing for in one sentence]
Allowed: [which files or folders the agent can edit]
Forbidden: [which files or folders the agent must never touch]
Constraints: [specific rules, e.g. "do not add new dependencies", "do not delete any existing test", "keep the API contract identical"]
Done when: [measurable condition, e.g. "all tests pass and lint score is 0", "validation loss drops below 0.95", "all rubric scores are 8 or above"]
Stop early if: [e.g. "3 consecutive cycles with no improvement", "total runtime exceeds 2 hours"]
After each cycle: record the hypothesis, the change, the result, and the lesson in experiments.md"
Step 4: Start the loop.
Open Claude Code in your project directory and paste this:
"Read program.md. This is your instruction file for an improvement loop. Run the loop as described. Each cycle: read the program, form a hypothesis, make one change within the allowed files, run the verification command, record the result, and decide your next move. Do not ask me for input between cycles. Run until you hit the done condition or the stop-early condition. When finished, give me a summary of every experiment with what worked and what did not."
Then walk away. Make coffee. Do something else. The loop runs on its own and you come back to a log of every experiment, every result, and a system that is measurably better than when you left.
OPEN LOOPS VS CLOSED LOOPS
An open loop has a human checkpoint at every cycle. The agent makes a change, shows you, you approve, it continues. This is safer but slower. Use open loops when you are learning the pattern or working on something where a bad change could be destructive.
An closed loop runs without human intervention. The agent makes changes, verifies them, and continues until it hits the done condition or the stop condition. This is faster but requires a strong verifier. If the verifier is weak, a closed loop will optimize for the wrong thing very quickly.
Start with open loops for your first 2 or 3 projects. Once you trust your verifier, switch to closed loops and let the system run overnight.
THE RATCHET PATTERN
One of the most useful loop variants is the ratchet. The rule is simple: the metric can only go in one direction. If a change makes the score worse, it gets automatically reverted. The floor only rises, never drops.
Here is the prompt:
"Run a ratchet loop on this project. The metric is [your metric]. Current baseline is [current score]. Rules: make one change per cycle, measure the metric, keep the change only if the metric improved or stayed the same, revert immediately if the metric dropped. After each improvement, the new score becomes the new floor. Log every cycle in ratchet-log.md. Run 20 cycles."
Karpathy's autoresearch used exactly this pattern. Over 700 experiments across 2 days, the score only moved in one direction. Each improvement became the new baseline that the next experiment had to beat.
WHAT THE LOOP WORKS ON BEYOND CODE
The Karpathy Loop is named after a coding example but the pattern works anywhere you can define "better" with a measurable check.
Writing: the generator drafts content, the verifier scores it against a rubric, the generator revises based on the scores. After 5 cycles the draft is tighter than anything a single pass would produce.
Research: the generator finds and summarizes sources, the verifier checks for missing citations, unsupported claims, and gaps in coverage. Each cycle fills holes the previous one missed.
Data pipelines: the generator writes transformation code, the verifier checks output against expected schemas and value ranges. Each cycle catches edge cases the last one missed.
Product specs: the generator writes the spec, the verifier checks it against acceptance criteria and flags ambiguities. Each cycle produces a more precise spec.
The pattern is always the same. Generate, verify, record, improve. The domain changes. The loop does not.
RULES TO REMEMBER
The generator and verifier must be completely separate. If the generator can edit the test, the loop is broken.
Memory is what makes the loop compound. Without experiment logs, the agent repeats the same mistakes. With logs, each cycle builds on every previous one.
The verifier is the most important part. A weak verifier produces fast garbage. A strong verifier produces slow progress that is real.
Start with open loops and move to closed loops as you build trust.
The ratchet pattern (only improve, never regress) is the safest way to run a closed loop overnight.
One change per cycle. Multiple changes per cycle make it impossible to know what worked.
Write your program.md once and let the loop run. Your judgment goes into the instruction file. The execution goes to the loop.
The Karpathy Loop is not a framework you install. It is a discipline you apply. Separate the generator from the verifier, write clear instructions, measure everything, and let the loop compound. That is how 126 experiments overnight beats 6 months of manual iteration.
Don't want to figure this out alone? I walk members through every step inside the community. Join the Skool → skool.com/raycfu