In autoresearch, the most important thing isn't the agent, but an honest oracle

The most important part of autoresearch isn’t the agent that writes code and runs experiments. It’s the oracle: a verification system that determines whether a solution has actually improved.

Without it, the autonomous cycle turns into a generator of plausible explanations. The agent might report an acceleration even though the loss is NaN everywhere, or choose a pipeline that “removes” text from an image but leaves minor artifacts. In both cases, the problem isn’t a lack of autonomy, but rather that the success criterion was incomplete.

From Manual Work to Cycle Design

The author describes a simple shift. Instead of manually sifting through hypotheses, he outlined a pipeline, instructed Gemini to evaluate the results, and let the agent run overnight. In the morning, the log showed 40 tested hypotheses. Some turned out to be junk, but that no longer mattered: the system had weeded out the unsuccessful options on its own, and the human ended up with far more tested avenues than they could have covered manually.

This differs from the usual scenario of “running several agents in parallel.” Parallel tasks without a common evaluation logic create parallel chaos: it only takes one thread to fail for all attention to shift to dealing with the consequences. Even a detailed plan doesn’t completely eliminate the problem—it merely reduces the number of surprises, but leaves the human as the dispatcher.

In autoresearch, a person designs not a single solution, but a closed loop:

• hypothesis generation;
• running an experiment;
• measuring the result;
• accepting or reverting a change;
• stop condition.

This is exactly how the approach is described in the examples from Karpathy and AlphaEvolve: the agent cycles through changes, and automatic evaluation decides which ones to keep. Expertise shifts from “I know the correct answer” to “I know how to build a process that reliably filters out incorrect answers.”

Where the Magic Breaks Down

The most unpleasant conclusion is that an oracle requires more engineering attention than a prompt. If we measure only speed, the agent will easily find a way to speed up the computation at the cost of the model ceasing to learn. If it checks the entire image, it may optimize the overall result without noticing that letters remain in the target area.

The evaluation criterion must specifically check the property that the experiment was designed to test. For training, this means monitoring not only time but also loss. For text removal, it means checking the removal area separately, rather than settling for an evaluation of the entire image. For GPU code optimization—reject solutions that formally pass the test but circumvent the requirement for fair operation merging.

A good oracle doesn’t just pick a winner. It doesn’t let the system win unfairly.

In this sense, the KernelBench-Mega run described in the article is illustrative: most of the session was spent measuring the baseline and running microbenchmarks, rather than immediately generating code. When one of the hypotheses worsened the result, it was measured and reverted, rather than rationalized away. For autonomous research, this is more important than an impressive number of experiments.

Autonomy Does Not Replace Expertise

There is also a limitation that cannot be fixed by a good loop alone. The result depends on whether the model understands which directions make sense in the first place. In the comparison described, Fable 5 independently proposed meaningful hypotheses, Claude Opus 4.8 stopped after an OOM error, and GPT-5.5 required explicit prompts.

This leads to an unfortunate paradox: to automate domain expertise, a human still needs to have a fairly good grasp of the task. Otherwise, they won’t be able to understand which contexts to add to the prompt, where the oracle is blind, and which constraints need to be checked separately.

Therefore, autoresearch does not yet appear to be a universal replacement for a researcher. It works well where there is a measurable criterion, a cheap, repeatable experiment, and the ability to quickly roll back a failure. In tasks with implicit quality, weak feedback, or expensive validation, the autonomous loop will either be too slow or will start optimizing a proxy instead of the actual goal.

The practical takeaway for an engineer is simple: you shouldn’t start by choosing the “smartest” model, but rather by asking how the system will prove that the result has improved. First, establish a baseline, check for degradation, and protect against exploitation. Then comes the agent that will explore different options.

Otherwise, the result will not be automated exploration, but automated certainty in an incorrect answer. For now, the main shortfall is not the number of agents, but the quality of measurement.

Source: All Articles / Machine Learning / Habr