How to Build a Self-Improving AI Agent That Works While You Sleep

It is a Claude Code agent that gets better at one job every night, without you in the room. Each night it makes the thing, a judge scores it against your best examples, and the agent writes what it learned into a short rulebook. Tomorrow night it reads that rulebook first.

That's the whole idea. You wake up to a finished piece of work, a score, and a note on what changed. You don't need to know how to code. You need to know what good looks like for the thing you make, and this guide gives you the prompts that pull that out of your head and turn it into a working loop.

Who this is for: you already use Claude Code, or you're about to. You make the same kind of thing again and again (web pages, newsletters, scripts, thumbnails, proposals) and you want the next one to beat the last one.

What it is not: an agent that runs all day, spends money on its own, or posts for you. It wakes up once a night, works for a set time, and stops.

In March 2026, Andrej Karpathy released a repo called autoresearch. The README describes it as giving an AI agent a small but real LLM training setup and letting it experiment autonomously overnight. The agent changes the code, trains for 5 minutes, checks whether the result improved, keeps or throws away the change, and repeats. You wake up to a log of experiments and, hopefully, a better model.

His launch tweet has the split that matters: the human iterates on the prompt (a .md file), and the AI agent iterates on the training code (a .py file). Two days later he wrote that he watched the agent work through about 700 changes on its own, found about 20 real improvements, and cut the time to reach GPT-2 quality from 2.02 hours to 1.80 hours. Those are his numbers, not mine.

• Launch tweet: https://x.com/karpathy/status/2030371219518931079
• Results tweet: https://x.com/karpathy/status/2031135152349524125
• The line that started everything for me: https://x.com/karpathy/status/2031137476438548874

That last tweet says you don't use autoresearch directly. It's a recipe: give it to your agent and apply it to what you care about. I knew it was powerful in March. It only clicked in October 2026, when I put the same loop on my own content.

Karpathy's loop works because the score is a number the computer can measure. Most of what you and I make has no such number. A web page isn't faster or slower, it's better or worse. So my loops add a judge and a rulebook. Every working loop I've built has the same five parts.

1. 1The thing it makes. One kind of output, made the same way every night: a web page, a newsletter issue, a script.
2. 2A judge. A critic prompt that scores the output against a fixed rubric and puts it side by side with your best examples.
3. 3A rulebook it writes lessons into. A short file the agent reads before it makes anything and edits after it learns something, one cited line per lesson.
4. 4One experiment per night. One focus area at a time, rotating, so a good or bad result has one cause.
5. 5A schedule. It runs once a night, works for a set time, and stops. It's not always on.

Everything else in this guide is detail on those five. If you remember nothing else, remember that a loop without a judge just produces more output, and a loop without a rulebook forgets everything by morning.

The judge decides whether the loop gets better or just gets busy, so it comes first. It has two pieces.

A rubric. Eight to ten categories, each scored 0 to 10, with a plain description of what a 10 looks like and what a 3 looks like for your work. My web page critic scores categories like clarity, visual craft, motion, typography and narrative. Yours will be different. The interview prompt below builds yours from your own answers.

Benchmarks. Three to five of the best examples you can find, from you or from people you want to beat. Before the critic scores anything, it puts tonight's output next to three benchmarks and answers one question: which looks better, ours or the benchmark? If the benchmark wins, the craft scores are capped at 5. This one rule stops the most common failure, a critic that is too kind to its own agent.

Calibrate the scale out loud: 5 means competent, 7 means equal to your benchmarks, 9 or more means clearly better. Most nights should land between 4 and 6 until the work really catches up. And only compare numbers that were scored on the same scale.

The rulebook is where the self-improving part lives. It's one plain file that the agent reads at the start of every night and edits at the end. Mine has a cap of 60 lines, one lesson per line, and every line carries where it came from. My agent can also rewrite my taste rules as it learns: the look, the story, the layouts, the copy, even its own critic rubric and craft guardrails. That's the point of the loop, so I let it.

These are real lines my web page agent wrote to itself, word for word:

• "[P57] Mechanism changes move the score, polish does not. After round 3, flag a fix only if it changes a category score; otherwise stop"
• "[P56] A fix on a click path is verified with the click shot, not the no-input shot. Four rounds re-fixed the same button blind"
• "[P28] Generated images are the page's light source. Zero images loses the side-by-side and caps visual craft and wow at 5"

Two rules keep the rulebook honest. The cap forces it to replace weak lessons instead of piling up new ones. And the source rule: a line only changes when the agent can cite a score, a critique or one of your notes.

Every rule change comes with receipts. These are the rules I use for my web page agent:

• One line at a time. It changes single lines. It never deletes a file or rewrites a whole one in a single night.
• Every change cites why. The line ends with (src: date and the evidence) or (src: feedback doc and the date).
• Evidence edits need a measurable score effect from a full night. One lucky round isn't enough. My notes in the feedback doc apply directly, since they're my taste.
• Every change is listed in the morning report and saved in git, so you can see it and undo it.
• A small core stays off-limits: the file that says who the agent serves, the rules file every run reads (CLAUDE.md), the settings file, the engine scripts, and the hard limits: never publish, post or push, and never delete.

A judge that can change its own rubric could quietly make itself easier. The receipts are what stop that: if a rubric line changes, you can see the score that justified it, and you can revert it.

Pick 5 to 7 areas where your output can improve. For my web pages they are clarity, composition, interaction, motion, narrative, style and typography. Each night the agent works on one area, tries one change, and compares the score with the best so far on that area.

1. 1It studies the weakest area against your best example and plans a few upgrades.
2. 2It makes the thing with those upgrades.
3. 3The critic scores it. The agent fixes the three worst problems and the critic scores again, up to a set number of rounds.
4. 4In the retro, it keeps the change if the score beat the best on that area, and kills it if not, writing the reason either way.

One focus per night matters because a night that changes five things teaches nothing. When the score moves, you know why.

The feedback doc is a plain notes file with two headings, New and Done. You write a gripe, a sentence or a link under New whenever you think of it. The agent reads that file first every night, before anything else.

• If New has notes, they outrank the critic and the focus rotation that night. The agent turns each note into a concrete change in the rulebook or tonight's focus.
• At the end of the night, it moves each handled note to Done as one line: the date, your note, and what changed.
• A note it couldn't handle stays in New with a short line under it saying why or what it needs.
• It never deletes or rewords your words. It only moves notes and adds its own line.

This is how I steered the web page agent: fonts went through a font lab and landed on one clean pair, I asked for more contrast, then a page 20 percent smaller, then less linear, and eventually a story that flows like I'm explaining it to a friend. Each of those was one sentence in a notes file.

Guardrails are the few hard rules that make an unattended agent safe to leave alone. Write them down before you build anything, because the agent follows them without being asked twice.

• Caps. A time limit per night (mine is 120 minutes for the web page agent, and the Substack one has a 30 minute hard stop), and a cap on anything that costs credits. My web page agent can make 6 images a night, and a small script enforces it.
• What it may change. Its rulebook, its focus files, and single lines of your taste rules and critic rubric, each with a cited reason. It may never touch the settings file, the engine scripts, the file that says who it serves, or the hard limits.
• Every rule change says why, and is saved so you can undo it. The agent cites a source on every edited line, lists each change in the morning note, and the night ends with one git commit. If a change hurts, you ask Claude to revert that commit.
• Nothing publishes until you flip a switch. The agent writes local files. It never posts, emails, sends or deploys, and the settings file blocks git push outright. My newest loop, for Substack, won't post anything until I flip a switch once, and even then autopilot unlocks in stages, starting after seven passing nights in a row.
• It runs on your plan. The nightly job uses claude -p, Claude Code's non-interactive mode, so it draws on your Claude plan. Check your plan's usage limits and start with small caps.

I built a loop called Explainer Forge. Every night at 1:00am it picks a Claude Code topic and builds an explainer web page for me to scroll on camera. Each step is a separate Claude call, and files are the only handoff between them: pick a topic, research it, study the weakest area against the best page so far, write a brief, make images and the page shell, build each section in parallel, simplify the words, take screenshots and a scroll video, score it, fix it in rounds, then run the retro where the agent edits its own rulebook and commits.

A stronger model directs and judges. A cheaper, faster one builds. My taste files (look, story, layouts, copy, the critic rubric, the guardrails) are rules the agent can now rewrite itself, one cited line at a time, and every change is listed in the morning note and saved in git. Only a small core is off-limits: the file that says which audience it serves, CLAUDE.md, the settings file and the engine scripts.

What the first three real nights did:

• Night 1, October 3, Claude Code mods. 37, then 43, then 45, on an older 60 point scale (so don't compare it to the others). I said it was not premium, jargon-heavy and nowhere near my benchmark.
• My hand-built versions, same day. 60, 68, then 72 out of 90. That became the bar to beat.
• Night 2, October 4, Pi 1.0. 56, then 64 over 8 rounds. It made zero images, and it did not beat 72. It ran about 77 minutes.
• Night 3, October 5, Ultracode. 73, 74, 76, 77, 77 out of 90. It beat the best, 77 against 72. It ran about 60 minutes and made 5 images.

The 90 is nine scoring categories. I've since added a tenth, narrative, so new scores are out of 100. These are my critic's scores, not audience data, and one of the three nights failed to beat the bar. That's the honest shape of a loop: most of the gain comes from the lessons it writes down, not from any one night.

I'm running the same loop on short videos and on Substack Notes. The Substack one is brand new, so I have no results to show you yet.

You need three things: a Mac, Claude Code, and a folder. Everything else is a prompt you paste.

1. 1Open Terminal. Press Command and Space, type Terminal, press Return. It's a text window. You'll only paste a few lines into it.
2. 2Install Claude Code. Paste this line and press Return: curl -fsSL https://claude.ai/install.sh | bash. Then type claude --version. You should see a version number. If you see "command not found", close Terminal, open it again and retry. Claude Code needs a paid Claude plan or API credits.
3. 3Make the folder. Paste: mkdir -p ~/my-loop && cd ~/my-loop. This is your loop's home. One loop, one folder.
4. 4Start Claude Code in it. Type claude and press Return. The first time, it asks you to log in through your browser. You should then see a box with a blinking cursor where you type. Paste the prompts below into the chat, one at a time.

The folder will end up looking like this. You don't create any of it by hand. The prompts do.

Start here. This prompt interviews you about what you make, what good looks like and who your best examples are, then writes your rubric, your rules and the first version of the rulebook. Answer in short sentences. Put your best examples in the folder first if you have files, or have their links ready.

What you should see: Claude asks one question, you answer, it asks the next. After about nine questions it reads a summary back. Say what is wrong, then it writes the files and lists them. If it asks two questions at once, reply "one at a time, please".

This prompt reads the files from Prompt 1 and builds the rest: the rules every night follows, the retro that writes lessons, the run folders, the ledger and the git history that lets you undo any change. It checks that Prompt 1 happened first.

What you should see: Claude asks permission to create files (say yes), then prints a folder tree that matches the one above. If it stops and says a file is missing, go back to Prompt 1. Open CLAUDE.md and read it once: it is the rulebook of rules, in plain English.

This is the judge. It saves a critic prompt into your folder. The nightly run hands it to a fresh helper every time, so the judge never sees the agent's excuses, only the output. You can also use it by hand on anything you made: ask Claude to read prompts/critic.md and judge a folder.

What you should see: Claude says it saved prompts/critic.md and tells you the line to run it by hand. Nothing is scored yet.

This is the nightly prompt. Paste it once and Claude saves it as nightly-run.md, then follows it right now as a test. Watch the first run live. Fixing it while you can see it is much easier than finding out at 7am that it stalled.

What you should see: Claude works for 20 to 60 minutes. It will ask permission for file edits the first time; say yes. At the end you get a MORNING.md and a runs/ folder for today holding the plan, the work, critique.md and score.json. Open critique.md first. If a run stalls for more than 10 minutes with no new files, press Escape, tell Claude where it stopped and ask it to continue.

The morning report is what you read with your coffee. Three lines, no approvals asked. This prompt saves the instructions as prompts/morning.md and runs them on your latest night. The nightly job then uses the same file.

Do this only after Prompt 4 ran clean by hand. On a Mac, the scheduler is called launchd. You don't need to learn it. This prompt makes the run script, a settings file so the agent can't do anything outside its lane, and the schedule.

What you should see: Claude shows you nightly.sh and the plist and waits. After you say go, launchctl list prints a line containing myloop, which means the schedule is on. The next morning, open MORNING.md. If it is not there, open logs/nightly.log to see what went wrong.

• A kind critic. Fix: the side-by-side test with a cap at 5, and real benchmarks, not just your own work.
• The agent changes its judge without a reason. Fix: every rule change must cite a score or your note, and the morning report lists it so you can undo it.
• Polish instead of progress. My agent's own lesson: mechanism changes move the score, polish does not. After round 3, only fix what changes a score.
• Five changes in one night. Fix: one focus area per night, so you can tell what worked.
• A rulebook that grows forever. Fix: a line cap, replace instead of add, and a source on every line.
• Restyling when the idea was the problem. The ladder graphic won by getting clearer, not prettier.
• A job that never starts. Usually a missing PATH in the plist, or a sleeping Mac. Read logs/ first.

1. 1Install Claude Code, make ~/my-loop and start Claude in it.
2. 2Put your 3 to 5 best examples in the folder (files or links).
3. 3Paste Prompt 1 and answer the interview. Read RUBRIC.md.
4. 4Paste Prompt 2 to build the loop folder.
5. 5Paste Prompt 3 to save the critic.
6. 6Paste Prompt 4 and watch the first night run by hand.
7. 7Paste Prompt 5 to get your morning report.
8. 8Write one note under New in FEEDBACK.md, then tell Claude to follow nightly-run.md again and watch it handle the note.
9. 9When two hand runs go clean, paste Prompt 6 to schedule it.
10. 10Read MORNING.md each day. Keep the feedback doc open. That's your whole job now.

This guide gives you the map and the prompts. Inside Claude Code Club we build systems like this together: you post what you made, you get feedback, and you see how other members are using Claude Code to build their own.

If you build your own loop, come show me what it learns. Duncan