An agent changes a training script, runs an experiment and keeps the version with a lower validation loss. In the morning, it has more completed trials than a researcher can run manually in the same elapsed time. The next question is less easy: which scientific claim does that improvement support?

A faster optimizer can help without an explanation of its effect. An interesting hypothesis possibly fails a discriminating test. A paper can be convincing although its experiment did not include a test of its claim. A different check is necessary for each case.

My questions about research automation are:

• Which decisions can a research system change?
• Which evidence should justify those changes?

These questions let me compare local code search, paper-generating agents and hypothesis collaborators on their actual work.

Four decisions in a research loop

A research loop proposes an explanation, selects an experiment and decides which claim the result supports. In some cases, it changes the question. Compare the output of each decision with the input necessary for the next decision.

A system can propose strong hypotheses but implement them poorly. A different system can run a narrow experiment reliably while scientific choices stay fixed.

Three reported designs show these differences.

Each design proposes something, receives feedback and selects the next attempt. The possible proposals and the source of feedback are important. A measured loss, model review and laboratory observation support different conclusions.

Search with a fixed objective

In the autoresearch setup discussed here, the agent changes train.py. The implementations for data preparation and evaluation are not in that file. Runs have five minutes of training. Startup and compilation time is not part of this budget. Validation bits per byte is the comparison metric. The human changes instructions in program.md.

The system can change code and keep evaluation fixed. A wall-clock budget gives one question: which recipe gives a better result in that time with this setup? The result includes architecture and throughput effects. Matched-token and matched-FLOP (floating-point operation) comparisons have different questions.

Fig. 2 gives a run with protocol and result checks before candidate retention.

Selection of a lower validation loss answers which change to keep. Ablations, new tasks or a different comparison of computational resources are possibly necessary for an explanation. Agents can also do these experiments. But they are new experiments. The lower loss does not already supply that evidence.

For example, a larger batch lowers loss after five minutes. Optimization dynamics possibly became better, or the GPU possibly processed more work. Compare matched-time and matched-token runs while you record throughput. A gain that disappears at matched tokens can keep value as a training-systems result. But it supports a different explanation.

The objective defines the improvements that can be compared. A different test is necessary for an explanation of an improvement.

Design a discriminating test

The original AI Scientist does more than local code search with a fixed objective. Its methods generate ideas from a template and archive. They examine related work, write and execute experiments, and make a manuscript with an automated review.

In the authors' diffusion case study, the implementation made results better. But more investigation was necessary for the proposed explanation. The apparent mechanism possibly resembled a mixture of experts. The case shows the difference between a code change that operates and knowledge of its cause.

Scientists and agents can propose good or bad hypotheses. The discriminating test favors one explanation rather than the alternatives.

Suppose an agent gives an auxiliary loss as the explanation for better long-context reasoning. More training computation, a new data mixture and a different inference budget are possible confounds. Each is a possible explanation of the gain. Removal of the loss with changes to all three does not identify the loss contribution. Specify the conditions that stay fixed. Specify the observation that would weaken the proposed explanation.

The original AI co-scientist report makes the difference between proposals and tests clear. Agents debate and rank hypotheses in a tournament, then refine them. Scientists can change goals and give feedback. The selected biomedical validations included expert guidance and experimental prioritization. The paper also identifies limited access to negative results and limitations of its internal ranking metric. Google's launch description presents a collaborator that proposes testable hypotheses and research plans.

A proposal loop can give better coherence, relevance and testability before execution. An experiment compares the proposal with observations. Better ranking possibly allocates scarce experiment time correctly, but debate agreement stays an internal preference. A test independent of the process that selected the proposal is necessary for the selected claim.

Score proposals and test results as different quantities. A proposal score is for proposal selection before a test. A result score is for the findings from the test. Their combination rewards plausible plans when execution or verification is weak.

Examine the experiment's execution

The necessary tasks for a research agent can include:

• To implement the intervention
• To keep data splits
• To record failures
• To reproduce a baseline
• To compare actual outputs

At each step, examine the agent's actual execution. A completed script run verifies only part of the experiment.

Zhu et al. argue that implementation and verification are major bottlenecks. They use benchmark evidence and model-based reviews of 28 public papers from five systems.

The papers were public and possibly curated. A large language model (LLM) judged paper quality. The study gives information about reported outputs and execution problems. It does not replicate all claimed discoveries or give a universal success rate for automated science.

I recommend records of these transitions, together with manuscripts:

• Did a proposal become code that can run?
• Did that code run the intended comparison?
• Can a different environment reproduce it?
• Did the interpretation survive a control selected to challenge it?

Different failures have different repairs. If an experiment cannot run, implementation work is necessary. If test data leaks into training, faster execution repeats the incorrect comparison more frequently. For a valid comparison with an overstated explanation, a discriminating test is necessary. The label “model-intelligence deficit” hides these different repairs.

Datasets, code versions, seeds, evaluation access, environment state and failed attempts identify the experiment that gives a score. This connects research agents to verifiable AI infrastructure. A polished number needs a path that a different researcher can reconstruct.

Selection and failed attempts

Search with more candidates has one more problem: selection can overfit the evaluator. Selection of the best result from many noisy trials tends to select favorable noise and changes that help. This problem can occur when all runs are honest. A held-out test set becomes part of search if the system returns to it after each decision.

Selection bias is an experimental-design problem. Automation increases the problem because the system tries many more candidates. A log of accepted changes alone does not show the number of alternatives or the frequency of failed reproductions.

Luo et al. examine benchmark choice, leakage, metric misuse and post-hoc selection in controlled synthetic tasks. Their diagnosis also found undisclosed dataset substitution. It did not find all hypothesized failures in all examined settings.

A different detection experiment used deliberately constructed flawed artifacts, including injected leakage. Logs and code helped identify pitfalls. These results show specific weaknesses and the value of audits. They do not measure the frequency of these problems in different scientific domains.

Declare the permitted data for selection. Keep a separate final evaluation. Keep rejected runs. Distinguish execution failure from a negative result. Record changes to metrics or datasets. A system can enforce these rules without a person who monitors each step.

A rigid protocol protects comparisons, but can prevent repairs to a bad benchmark. Unrestricted evaluator changes make gains less easy to interpret. I would let an agent propose a change and record its reason. An accepted change starts a new comparison. More justification is necessary for a combination of scores from before and after that change.

Each type of feedback should have its own record:

• A failed run and its implementation repair
• A failed check and its rejected interpretation
• A changed objective and its new research question

All three can occur in one agent conversation. But the records should stay separate.

Changes to the research question

Research also includes the selection of questions for investigation. The scientific iceberg represents work below the finished output. This work includes identification of tensions, decisions about important questions and conversion of observations into an investigation.

The systems in this article propose hypotheses, use evidence together and suggest directions. The waterline should not reserve these abilities for humans. The less easy questions are: does a new question deserve resources, and does its evaluator measure the intended quantity?

Suppose a policy in a robot benchmark makes better grasps of visible objects. But the policy still fails when a drawer sticks. A better average grasp success possibly leaves the important deployment constraint unchanged. The next useful question is possibly about contact, recovery or sensing. The original benchmark barely measures these properties. A system could find this pattern and propose the new task.

These parts are necessary for the proposal:

• A reason for the failure's importance
• An intervention for a test of the explanation
• A method to observe improvement

I think that candidate generation at lower cost makes research judgment more consequential. Researchers stay responsible for the resources spent, results recorded and conclusions that other researchers rely on. An automated action cannot transfer that responsibility to its output file.

“Research taste” includes identification of confounds and failures that a benchmark excludes. It also includes separation of explanations and selection of small anomalies for sustained work. Each choice changes an experimental design. Without these changes, taste becomes one more score without a clear meaning.

My proposal for research automation

My proposed requirements for a research system are:

• Keep rejected hypotheses and their reasons.
• Connect claims to the actual runs.
• Send requests for new comparisons that examine confounds.
• Distinguish repairs to the evaluator from algorithm improvements.

Agents can help with all four decisions in the research loop. The scope of delegation depends on verification and the cost of error. A short code search with an immutable evaluator may need a small amount of supervision. Stronger checks are necessary for revision of a scientific claim or a physical protocol with high cost. Select the checks for the work, not for the automation label.

A lower validation loss possibly shows a better recipe with a fixed budget. A hypothesis possibly suggests a worthwhile experiment. A replicated comparison that separates explanations possibly supports a mechanism or discovery. Each claim should match the actual test.

I still see reason for optimism. Automation of local coordination can leave more attention for comparisons that give meaning to results. I would trust faster search with inspectable runs, independent tests and a method to change a question that no longer gives knowledge.

@article{ji2026theageofautoresearchandothercertainties,
  title = {The Age of Auto Research, and Other Certainties},
  author = {Ji, Wenbo},
  journal = {fusheng-ji.github.io},
  year = {2026},
  month = {April},
  url = {https://fusheng-ji.github.io/blog/posts/the-age-of-auto-research-and-other-certainties/}
}

References

1. Andrej Karpathy. autoresearch. Repository and its fixed-budget training/evaluation interface.
2. Lu et al. The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. Original system design, experiments, case study, and limitations.
3. Zhu et al. AI Scientists Fail Without Strong Implementation Capability. Implementation-gap analysis.
4. Luo et al. The More You Automate, the Less You See: Hidden Pitfalls of AI Scientist Systems. Controlled workflow diagnostics and artifact-based failure detection.
5. Google Research. AI co-scientist. Original collaborator framing.
6. Gottweis et al. Towards an AI co-scientist. The original 2025 methods, expert-in-the-loop evaluations and limitations.
7. Helen Wilkes. The Scientific Iceberg. Metaphor for work below finished research outputs.

Updated 03 November 2026