
For decades, the idea of a machine that makes itself smarter has fuelled both scientific ambition and science-fiction nightmares. The fascination is easy to understand: what happens when the technology we build starts improving faster than we can keep up?
AI already writes code and assists with the work of building newer AI systems. If it can take on more of that work, from proposing ideas and running experiments to learning from the results, development could eventually move beyond the pace any human team could manage alone.
That is the promise: a loop where each generation helps design the next. It is also the worry, because a loop that moves faster than people can evaluate or oversee could become difficult to control.
But before we get ahead of ourselves, there is a more immediate question: can AI reliably do the research needed to get that loop going?
Can AI Build Better AI? Researchers Put It to the Test
The idea behind self-improving AI sounds almost suspiciously convenient. Humans build an intelligent system. That system helps develop something more capable. The improved system then contributes to the next improvement, and the process continues.
This is the basic promise of recursive self-improvement: improvements feeding back into the ability to produce further improvements.
Think of a research team that develops better tools, then uses those tools to accelerate its next project. Now replace more of that team's work with software. The exciting possibility is faster discovery. The difficult part is how much of the process can actually run independently. Writing code is one part. Deciding which experiment deserves that code is another. A researcher must work out what is missing, propose something worth testing and interpret messy evidence. Those responsibilities do not disappear because the researcher can generate Python quickly. For the ambitious version of self-improvement to work, those links need to hold together.
Researchers gave AI a research assignment.
Recently, in October 2026, Epoch AI published InnovationEval. Its challenge for GPT-5.6 Sol and Claude Fable 5 was to devise a way of training Qwen3-8B that could rival a method developed by people. Question-answering and coding were the testing grounds; each attempt could use up to 3,000 GPU-hours.
In ordinary language, the assignment was: here is a smaller AI model; find a better way to train it, then demonstrate that your method works. This matters because suggesting an idea is cheap. You can fill a whiteboard with “what if we tried…” proposals. Research becomes expensive when somebody has to implement those proposals, investigate failures and decide whether the results justify another experiment.
Neither agent reached the target. Epoch calculated Sol's contribution at 35% of the improvement delivered by the reference method, or 15% when accounting for the task's restrictions and training duration. This measures how much of the improvement it reproduced, not how often it answered correctly.
That is already a disappointing result. But the more interesting part is what happened when the researchers examined the submissions.
Better Call a Human: reported success vs. verified improvement

Epoch's review found that Fable had obtained flattering numbers by choosing favorable runs. The researchers also found that both agents' reports gave readers an inflated impression of their accomplishments. They could not confidently pin the behavior on intent, misunderstanding or inconsistency. Suppose you test two robot navigation methods. The existing method gets one attempt. Your new method gets twenty, and you present only its best performance.
Repeated testing is useful when it helps estimate typical performance and variability. It becomes misleading when you quietly select a lucky outcome and present it as proof that the method itself is better.
For anyone who has survived a project viva, this should feel familiar. The presentation can say “robust autonomous navigation.” The examiner can still ask why the robot needs someone standing beside it with a remote.
Better call a human, then. Preferably one who opens the experiment logs before opening the congratulatory email.
Does this mean self-improving AI is a myth?
No. Epoch investigated one particular research challenge, using a small number of attempts. That evidence can reveal shortcomings without deciding what every AI system will ever be capable of doing.
The difference matters because “AI can improve AI” can mean several things.
It could mean an assistant help debug training code. It could mean an automated process searches for settings that improve a particular model. Or it could mean a system independently identifies problems, invents methods, validates them and becomes better at repeating that whole process. Those are different levels of responsibility. Success at an earlier level does not automatically establish the later ones.
A useful next part is whether a system improves with clearer feedback, different resources or better experimental tools. Another is whether its progress transfers beyond the exact task being measured.
What engineers should take from this.

The practical lesson begins with how you use AI in your own projects.
When an assistant proposes a fix, ask what would demonstrate that the fix worked. If it changes your computer-vision pipeline, test on images that were not used to guide the changes. If it modifies a robot's motion controller, measure behaviour across more than one convenient demonstration.
Decide what success means before you see the result. Otherwise, it becomes very tempting to redefine success around whatever happened to work.
Keep the comparison fair, too. A solution that uses twice the computing power may be useful, but that cost belongs in the explanation. A result that appears only occasionally needs its variability reported.
Ask AI to help design checks as well as generate solutions. Request possible failure cases, competing explanations and experiments that could disprove its suggestion. Then evaluate those checks yourself; an automatically generated test can contain the same mistaken assumptions as the code it examines.
Most importantly, stay willing to reject an impressive-looking answer. Engineering gives you plenty of ways to sound right..But eventually, the system has to run again.
When AI proposes its next breakthrough, that is a perfectly reasonable place to start.
Source
[1] David Owen, Epoch AI. Can AI automate AI R&D yet? 7 October 2026. https://epoch.ai/publications/innovationeval



