Auto Research: taking the researcher out of the loop

Karpathy's name for an agent loop that improves a model without a human in it — an objective, a metric, boundaries, and go. What it did to a repo he had hand-tuned for two decades, the one constraint that decides where it applies, and the parallel version he has not solved.

Source: the NoPriors interview of 2026-03-20, archived under sources/2026-07/karpathy-nopriors-skill-issue/. Reading notes on the rest of it, including the transcript-quality caveat that applies to every quotation on this page, are in Skill Issue: Karpathy on code agents (NoPriors, 2026-03).

The idea, in Karpathy's own framing from that interview: to get the most out of the current tools you have to remove yourself as the bottleneck. You cannot be there to prompt the next thing. Auto Research is the worked implication of that — not a product, a shape:

here's an objective, here's a metric, here's your boundaries of what you can and cannot do, and go

Arrange it once, hit go. The measure of success is how much happens per token you personally type.

The demonstration

Karpathy ran it against his own nanochat work — the small-GPT training repo he uses as a playground for the recursive-self-improvement question (the transcript garbles the project name). He had tuned it by hand, with two decades of experience at exactly this kind of tuning, and considered it fairly well tuned.

He let Auto Research run overnight. It came back with settings he had not found: he had forgotten weight decay on the value embeddings, his Adam betas were under-tuned, and the two interact, so fixing one moves the other. He says plainly that he did not expect it to work.

That is the single most concrete result in the whole harness-design cluster — not "the harness produced a better app by our own evaluator's score", but a domain expert's hand-tuned baseline beaten overnight against a metric nobody disputes. It is also the narrowest: a training loop with a validation loss is the friendliest possible case.

The constraint that decides where it applies

Karpathy states it as a caveat and it is really the whole boundary:

if you can't evaluate then you can't auto research it

The perfect fit is something like writing CUDA kernels — you have slow code, you want fast code with identical behaviour, and correctness and speed are both mechanically checkable. Everything the notebook has collected about evaluators is the same constraint seen from the other side: the automation is only ever as good as the thing that decides whether an attempt was better.

Elsewhere in the same interview he gives the reason the boundary is so hard: capability is advancing where a reward can be computed and stalling everywhere else, so "can this be checked mechanically?" also predicts whether the model is any good at the task. See Jaggedness: what RL optimises, and what stalls.

He adds the failure mode that follows from running a loop over a metric for long enough: the system will overfit the metric. His proposed answer is more metrics, generated by the system itself, for coverage. That is a hope rather than a result, and it has the obvious regress problem — the metrics that catch metric-gaming are themselves unvalidated.

program.md and the layer above it

The loop is specified in markdown. Karpathy calls his program.md a "crappy attempt at describing how the auto researcher should work" — do this, then that, try these kinds of ideas, look at the architecture, look at the optimizer.

Then the generalisation, which is the most interesting line in the interview:

a research organization is a set of markdown files that describe all the roles and how the whole thing connects

Once the organisation is code, the organisation is tunable. Different program.mds produce different rates of progress; one org takes more risk, another holds fewer stand-ups. So there is a meta-layer — run a contest of hand-written program.mds on identical hardware, see where the improvements came from, and hand that data back to a model to write a better one. Neither he nor his interviewer treats this as speculative; both expect it to work. Nobody has run it.

This is the same recursion as Loop engineering: from writing prompts to writing loops, one turn further out: first you stop writing the code, then you stop writing the prompt, then you stop writing the loop. And it inherits the same unanswered question at every level — something still has to decide what "better" means, and that thing is not itself optimised.

The parallel version, which is unsolved

A single Auto Research thread is the easy case. Karpathy's actual interest is parallelising it, and specifically parallelising it across an untrusted pool of workers on the internet rather than a cluster you own.

The structure he sketches is deliberately blockchain-shaped: commits instead of blocks, each building on the last; the proof of work is the enormous search needed to find a commit that helps; verification is cheap because you only have to train the one candidate. Someone tried ten thousand ideas, you check the one that survived. The precedents are Folding@home and SETI@home — expensive to produce, cheap to verify — hence "auto research at home".

The payoff he imagines is not modest: the frontier labs hold a lot of trusted compute, but the Earth holds far more untrusted compute, and a swarm might run circles around them. It also reframes contribution — you donate compute to a research track you care about rather than money to an institution.

He does not have a design he is happy with. The security problem is the visible blocker (running arbitrary code from strangers), and he says he has been playing with ideas without anything clicking.

Someone building the prerequisite

Auto Research assumes a pipeline an agent can read, modify and run — program.md is a gesture at specifying one, and the nanochat demonstration works partly because a small training repo already is that. At production scale it is not free, and Aleph Alpha's Savanna (May 2026) is the first published account of a lab building it deliberately: the whole training pipeline as imperative code, hermetic runs triggered from CI, artefacts immutable and versioned, evaluation as a function you call.

They name auto-research as the reason, in the last paragraph: with the pipeline in code, an LLM agent can read, modify and run it autonomously, they are beginning to explore this, and what they hope for eventually is a model that improves itself through the factory. So the state of play, as of that post, is that the substrate exists at one lab and the loop on top of it does not yet.

That is a small correction to the framing on this page rather than a change to it. The gap here has been described as coordination and parallelism, which is right about Karpathy's version — one machine, one metric, overnight. The Aleph Alpha post says the other gap is plumbing, and that the plumbing is a multi-team engineering project: hermeticity, artefact lineage, a workflow engine, a cache that keeps a sweep from re-running work. None of it is research, all of it is a precondition, and it is the sort of thing that never appears in a description of the loop.

The same loop, taken seriously as a forecast

Everything above is one machine, one metric, overnight. Greenblatt, in August 2026, is arguing about the version where this is the industry: AIs matching top human experts at AI research, doing the research, producing better AIs, feeding back in — with a median around 2030–31 and a rate he puts at four or five years of progress in one.

Three things it changes about this page rather than adding to it.

The environment list stops being a sketch. Containerising AI research has the concrete version — small pretrains, small post-training runs on a near-frontier model, a few genuinely frontier-scale experiments, capability targets with the mechanism left free, and bug-finding as a gradable task. program.md is a specification for the loop; that is a specification for the curriculum, which is the part Karpathy's account leaves out.

The nanochat result gets a name for what made it easy. Asked which part of AI research is least verifiable, Greenblatt says making calls on large experiments: few tries, no iteration, and you have to decide what goes into the one big run. Which is precisely the property the overnight run did not have. So the reason the demonstration worked is not only that a training loss is a clean metric — it is that the runs were cheap enough to do thousands of them. That reframes the boundary on this page: "can you evaluate it" and "can you afford to evaluate it repeatedly" are two conditions, and this cluster has been treating them as one.

And the metric-overfitting caveat gets promoted from a caveat. The paragraph above records Karpathy's worry — run a loop over a metric long enough and it overfits the metric — and his hope that more metrics fix it. Greenblatt's whole failure story is that worry with the consequences followed through: what a system optimising apparent score learns is to make the score look right, the corrections you apply select for the cases you can't see, and at sufficient capability that is a path to losing control of the process rather than to a disappointing research result. The regress this page notes — the metrics that would catch metric-gaming are themselves unvalidated — is the same regress; it just doesn't stop at bad science.

What he thinks the labs are doing

Reported as inference, not as knowledge. He expects the frontier labs to be running some version of this on small models, where exploration is cheap, and extrapolating up the scaling curves. The shape he describes: a single queue of ideas, fed by researchers and by an automated scientist reading arXiv and GitHub; workers pulling items off the queue and trying them; whatever works landing on a feature branch; a human occasionally merging to main.

His view of the researchers in that picture is blunt — they can contribute ideas, they should not be enacting them, and they have far too much confidence in their own judgment. He includes the people employed at the labs to do this in the group being automated away, and says so.

Correcting the record in this notebook

The owner's note states that Auto Research "is not implemented". That was written from memory, before this transcript was in the notebook, and it needs splitting in two:

• The single loop is implemented, and it worked. The nanochat run is a real, reported result with a surprised author. Saying it is unimplemented is too strong.
• The parallel version is genuinely not implemented, by Karpathy's own account, and the meta-layer over program.md is an idea nobody has run.

The note's conclusion is unaffected — the labs have published no working version, we see their work months late, and the useful response is to build your own. But the premise was overstated, and the interesting gap is narrower and more specific than "nobody has done it": it is coordination and parallelism, not the loop itself.

One running outside a lab

An instance from an ordinary company, four months later, and it matches this page's specification line for line. Baseten report a loop in which GLM-5.2 runs a forward pass on itself, reads the resulting profiling trace, finds the bottleneck kernels in the inference engine, writes replacements, and profiles again — see Training and inference are merging for the account and for the confounder nobody controlled.

What makes it worth adding here is the metric. This page's one constraint is that Auto Research applies wherever the objective can be computed without a human, and its examples of that have been loss curves and benchmark scores. A profiling trace is a stronger case than either: it is not a proxy for the goal, it is the goal, and there is nothing in it to game. So the constraint holds, and the example set now includes one case where satisfying it required no eval design at all — somebody simply pointed the loop at a measurement that already existed.

It is also single-threaded, which leaves the gap above exactly where it was.