EvalsAgents

Autoresearch: Let AI Run 100 Experiments Overnight to Improve Itself

EN · Mia Builder Notes · April 2026

The Essay

Have you ever been here? You change one line of a prompt, run the eval, wait 30 minutes for the results, then try to figure out what to change next. By the end of the week, you’ve done 5 rounds.

What if I told you someone has AI run that loop 100 times in a single night, on its own?

I. The 630-line Python script that started a revolution

This March, Karpathy open-sourced autoresearch. 630 lines of Python. What it does is simple:

Give an AI agent a small LLM training setup and let it edit the code itself → train for 5 minutes → check whether the score went up → keep the change if it did, roll it back if it didn’t → repeat.

100+ experiments in one night. Shopify’s CEO gave it a try: 37 experiments overnight, 19% better model performance. Later he ran it on Shopify’s frontend rendering code and found a 53% speedup.

21K GitHub stars. 8.6 million views.

But that’s not the point. The point is that this loop can be applied to every layer of an AI system.

II. Autoresearch isn’t just for tuning training parameters

A modern AI product isn’t just “a model.” On top of the model sit 7 layers you can tune:

Layer	How you tune it today	How autoresearch tunes it
Pre-training	ML researchers tweak the architecture by hand	Karpathy’s autoresearch
Post-training	Hand-picking SFT data	MiniMax M2.7: the model helps train itself
Prompt / Schema	Prompt engineers’ trial and error	Harvey’s Harness Engineering
Pipeline steps	Engineers add and remove steps by hand	AutoAgent / Meta-Harness
Eval / Judge	The eval team calibrates	OpenAI Self-Evolving Agents
Scientific discovery	Researchers do the research	Sakana AI Scientist

The same loop (change a parameter, run the experiment, check the result, keep or roll back) runs at every layer.

Harvey AI (legal AI, $11B valuation) used this approach to lift its average score across 12 legal tasks from 40.8% to 87.7%. They didn’t swap the model. They only changed the model’s “work environment.”

III. The core isn’t the code. It’s three design questions

I’ve run autoresearch on my own project (healthcare AI; I won’t go into specifics) and fell into plenty of traps along the way. Looking back, what makes or breaks autoresearch isn’t the code. It’s three design questions:

1. What is the agent allowed to change? (Action Space)

Too narrow → not much room to optimize. Too wide → the risk gets out of hand.

I use a Where × What matrix: Where = which layers of the system can be changed (prompt? schema? pipeline step? model?), What = which operations are allowed (add/remove/swap/modify). Each round touches exactly one cell of the matrix, so every experiment changes a single variable.

2. How much data is enough?

⚠️ This is the easiest trap to fall into.

I had one config that looked like the worst on 10 cases (a certain metric at -0.300) but turned out to be the best on 54 cases (-0.025). A 12x error.

Another config looked like the best on 10 cases (+0.067) and was actually worse on 54 cases (-0.213).

If I’d made the call after just 10 cases, I would have thrown away the best config and picked a worse one.

Academic research backs this up: in 43 out of 48 scenarios, the apparent effect of structured output was statistical noise.

My rule of thumb from practice: with n < 30, all you can do is rule out directions that are obviously broken. You need n ≥ 50 to make a real decision.

3. How does knowledge accumulate?

AutoAgent (the open-source one, #1 on SpreadsheetBench) has no memory. Every round reasons from scratch. The result? It keeps repeating mistakes it already knows about.

I added a learnings.jsonl: after every round of experiments, it records “what we learned” (structured, with confidence and scope). After 23 learnings, the agent stopped walking into the same walls.

These learnings are the most valuable thing autoresearch produces.

The specific configs (the best prompt, the best schema) go stale as models update. Their half-life is only 3–6 months. But the principles behind “why this config is better” carry over across models and domains.

IV. The truest thing Karpathy said

The bottleneck is no longer how fast the “meat computers” can write code. It’s how well we define the constraints of the search.

(My paraphrase. In the README’s own words, you are now “programming the program.md Markdown files that provide context to the AI agents.”)

The human role shifts from experimenter to experimental designer.

Writing a good program.md (goals, constraints, eval criteria) matters 100x more than tuning parameters by hand.

But only if you have a good eval. Without calibrated evaluation criteria and a big enough sample, autoresearch is just automating the chase after noise.

Eval quality > loop speed. That’s the conclusion I came to after falling into more traps than I’d like to admit.

So what do you think: is “AI automatically optimizing AI” the ultimate lever for engineers, or just another overhyped idea? Tell me in the comments 👇