The most misread repo of 2026 is Andrej Karpathy's autoresearch. The famous version of the story — pushed to GitHub on March 7, agent ran experiments overnight while he slept, tens of thousands of stars within weeks — makes it sound like the breakthrough was the agent. It was not. The agent was ordinary; Karpathy explicitly designed the setup so any capable coding agent could drive it. The breakthrough was the environment: a system deliberately shrunk until verification became cheap, so a loop of propose-test-keep-discard could run unattended without drifting into fantasy. I know because I had been running the unglamorous version of that loop on my own work before the repo existed — my project's CLAUDE.md literally encodes a section titled "Karpathy + Project Workflow" — and everything that makes autoresearch work maps one-to-one onto what makes my loops work on SEO and Laravel code.
This post is that mapping: what autoresearch actually did, the four components every such loop needs, and how to run one tonight on work that is not machine learning.
What actually happened, minus the mythology
The verified shape of it: autoresearch points a coding agent — Claude Code, Codex, or equivalent — at a deliberately minimal LLM training setup: a stripped-down, single-GPU version of his nanochat where the key file, train.py, is roughly 630 lines of Python. The agent runs an indefinite loop: read the code, propose a change, run a ~5-minute training job, measure whether the target metric improved, commit if it did, roll back if it did not, repeat.
First night: about 50 experiments while he slept, including a better learning rate, committed to git with the receipts. His own extended two-day run: roughly 700 experiments, stacking around 20 additive improvements that cut the "Time to GPT-2" benchmark from 2.02 hours to 1.80. The repo collected on the order of 66,000 stars within a month. Real, impressive — and every impressive part is downstream of design decisions that have nothing to do with model intelligence: one file, one GPU, one metric, five-minute experiments.
The file people skim past is the most important one: program.md, a single Markdown document carrying three registers at once — what to search for, what must not change, and when to stop. That file is the loop's constitution, and writing yours is most of the work of transplanting the idea.
The anatomy: four components, no exceptions
Strip autoresearch to its skeleton and you get four requirements. I have run loops with all four, and attempted loops missing one; the difference is not gradual, it is binary.
- A metric. One number the loop is trying to move. Not "better" — a number.
- A mutation space. What the agent may change, and much more importantly, what it may not. Constraints are what keep an overnight run from optimizing your metric by deleting your product.
- A verifier. A cheap, scripted, non-negotiable check that decides keep-or-discard. The agent must not grade its own homework.
- A ledger. Durable state — git commits, a manifest — so every experiment is recorded, reversible, and resumable after a crash.
Five-minute training runs are autoresearch's verifier being cheap; the passes-or-fails metric is it being non-negotiable. That cheapness is a design achievement, not a lucky property of ML. Which is the transferable insight: your job is not to build the agent; it is to shrink your problem until verification is cheap.
The same loop on work nobody tweets about
Here is the loop running on this website, a production Laravel platform, where the domain is SEO and content rather than GPU training.
The metric. A scripted quality gate for rewritten posts: structural checks, link validation, length bounds, banned-phrase detection, scored criteria with hard minimums. It runs as a Python script, and its verdict is binary — a rewrite ships or it does not. Building that script was the real work; once "good post" collapsed from a debate into an exit code, the rest of the pipeline became mechanical.
The mutation space. Rewrites may change body content and metadata; titles, slugs, and non-English locales are locked. The constraint list came from painful experience, not foresight — early experiments taught me that an unconstrained agent will happily "improve" a URL and torch the page's search equity. Your program.md equivalent gets written one incident at a time, so start it before the incidents.
The verifier as a separate context. The agent that rewrites is never the agent that verifies. Same principle as autoresearch's objective training run: the generator does not grade itself. My gate is a script plus a fresh session with no investment in the draft it is judging.
The ledger. Durable manifests mark each unit DONE or PENDING the moment it completes, with row-level backups before any change. Sessions crash; the loop resumes from the manifest instead of re-doing or — worse — half-re-doing work. I described that machinery in my post on task management across sessions; it is the same pattern Karpathy gets from git commits.
Overnight cadence and all: the scheduled, recurring version of this — checks that run on a timer and file their findings — is covered in automating SEO checks with Claude Code routines, with the scheduling mechanics in my loop and cron setup.
Where the loop fails: a confession
I once ran a "make the writing better" loop with no scripted gate — the metric was, effectively, the agent's own opinion. It churned beautifully. Every pass produced confident edits, every edit was defensible, and after dozens of iterations the content had oscillated rather than improved, because the judge changed its mind session to session. That failure taught me the rule I now consider the whole game: no scalar-ish metric plus cheap verifier, no loop. Work that genuinely resists scripted verification — strategy, taste, novel design — should get agent assistance, not agent loops. Pretending otherwise produces motion, not progress, and burns tokens doing it.
The other failure mode is subtler: a metric that is cheap but wrong. Optimize word count and you get padding; optimize keyword density and you get spam. The loop will find whatever your verifier actually rewards, with the literal-mindedness of a genie. Audit the metric before you scale the loop.
Start tonight, small
The honest on-ramp, in order: pick one number you can compute with a script (test count passing, page-speed score, lint violations, a quality gate of your own). Write the constraints file — what may change, what may not, when to stop. Wire the loop: propose, apply, verify, commit-or-revert, log. Run it attended for one evening before you ever run it overnight. My CLAUDE.md's workflow section — state the domain, name the sibling pattern you are copying, list concrete verify steps before touching code — is the single-iteration version of this discipline, and installing a Karpathy-style CLAUDE.md plus skills is the fastest way to bootstrap it. For the theory underneath — why agent loops work and where they top out — my loop engineering explainer goes deeper.
Karpathy's contribution was not letting an agent run all night. People had done that and woken up to messes. His contribution was building a room where running all night could only produce committed, measured, reversible progress. Build the room. The agent you already have is enough.
Several of the verification gates and workflow procedures from my own loops are packaged as installable skills on my agent skills marketplace — a shortcut to the room, if you would rather furnish than build.
