https://x.com/i/article/2110446055401947136
Asking with Open-Science: Can AI Create the Next Breakthrough?
Using Open-Science, we trace the technical paths of AI self-improvement, the economics behind them, and the feedback loops that are not yet connected.
A coding agent, initially able to solve only one-fifth of the tasks.
Let it modify its own tools and workflow, save candidate versions, and keep searching.
After 80 rounds, its task resolution rate reached 50%.
This is the result reported by DGM: on a 200-task subset of SWE-bench, with the base model frozen.
What fascinates me most is that the model was not changed.
The improvement happened in the software around the model: how it calls tools, how it organizes problem-solving, how it handles failures. A patch written yesterday may today become the tool for writing the next patch.
Imagine a programmer who, every time they finish a job, also fixes their debugging tools along the way. Next time, they may work faster. What happens if the method for improving tools also keeps getting better?
Recursive Self-Improvement, RSI, asks exactly this question:
Can progress feed back into the machine that makes progress?
Keeping the question inside the project
I opened an RSI project in AIPOCH Open-Science, starting from two materials, What if automating AI R&D triggers an intelligence explosion? and The Economics of Recursive Self-Improvement, to trace this feedback chain.
Open-Science is an open-source AI research workbench. You can put in a question, papers, or data, and the agent can help break down tasks, retrieve material, and write and run analysis code. Sources, sessions, notebooks, reports, and charts remain in the same project, together with available execution records and review comments, making it easier to trace results back to their evidence.
A schematic of this project's relationships among sources, execution, review, and output.
Writing the question into the project first
In Agent Context, I recorded this round's research requirements: compare technical paths, trends, and economic impact; distinguish paper results from inference; and record sources for important numbers. It carries over into later sessions, so that each time I read a paper, I can return to the same checkpoint: how does this round's change get used in the next round?
After connecting the selected model provider, the project is set up; Agent Context saves the research requirements that later sessions must follow.
When AI upgrades itself, what exactly changes?
"Self-improvement" sounds like a button. Opening the papers reveals several very different paths.
This map distinguishes what is changed; the paths do not share a single performance ruler.
First, give it a notebook of mistakes.
Reflexion lets an agent do a task, read feedback, and write down the reason for failure. On the next attempt, that memory is carried along. The model weights stay the same; what remains is experience that can be read again.
This path depends heavily on feedback. If the tests misjudge, it may finish early on a wrong answer.
Conceptual illustration: improvement must have a path for saving and inheriting.
Next, let it produce its own training material.
STaR first generates solution processes, filters them using known answers, and then trains on the filtered material. For questions it answers incorrectly, it can be given the answer and asked to regenerate an explanation. In the next round, the trained model produces the material.
Conceptual illustration. STaR fine-tunes from the original pretrained checkpoint in each round; a correct answer does not guarantee that the entire reasoning process is correct.
SPIN, meanwhile, has the model learn to distinguish fixed external demonstrations from answers generated by an earlier version, and then lets the new model take part in the next round. The external demonstrations here may also come from another model.
Self-generated data is appealing: practice material can keep growing. But the questions, verification criteria, and training rules still determine the direction it moves in.
Giving every number a traceable origin
"The model answers better" is no longer enough. I added the RSI source folder to Open-Science and had the session organize its material against the original texts. The task can be stated more concretely:
Compare what was retained in each round and where the feedback came from. Organize the technical paths, the results reported in the original papers, and the economic bottlenecks. Label every number with its task, metric, and source, and list the claims still needing verification separately.
Add a source directory via Files → Add folder, then have the session read specific material. The above is an example of a usable task.
This round of organization produced 23 core papers, 6 supplementary sources, and 47 source-linked claims. The next three paths shift the change from answers and weights to the tools and processes that produce answers.
The third path directly modifies the agent's own toolbox.
DGM reads failure logs, modifies tools, context management, or workflows, then runs coding evaluations. Versions that run and can still modify code enter an archive, and later rounds can choose different branches to keep growing. A version that has not yet achieved the highest score may still become a stepping stone.
Conceptual illustration: what changes is the agent's code. The outer archive selection and evaluation rules remain fixed.
The improvement at the beginning came from here: upgrading the software around the model let the agent solve more tasks.
The fourth path changes the pipeline that produces AI.
AlphaEvolve has the model generate algorithm candidates, hands them to pre-written programs that check correctness and performance, and then continues searching from the candidate pool. The target can be better scheduling or faster compute kernels.
When these improvements enter real systems, they may lower the compute cost of the next round of R&D. AI finds better algorithms, and those algorithms are then used for AI R&D — this is a feedback chain that could be connected.
The fifth path lets the workshop of improvement also be improved.
Hyperagents open both the "code that does the task" and the "code that proposes and executes modifications" to change. It also checks whether the accumulated improvement methods, when transferred to new tasks, can continue to produce better agents.
Conceptual illustration: the internal improvement process can be modified, while the external evaluation that judges results remains fixed. Task ability and improvement ability are tested separately.
Meta^n takes another route: the underlying improvement operations are fixed, and code, history records, and wrapper layers are added layer by layer so that each new layer inherits the work before it.
From the notebook of mistakes, to the toolbox, to the workshop of improvement, "self-improvement" has gradually taken more concrete shape. Next, let's look at what these changes actually bring.
After upgrading, can it get better at upgrading?
First exam: did it do the tasks better?
Second exam: did it get better at creating the next breakthrough?
AIDE² had the agent scaffolding rewritten 7 times in a single run. Another experiment had the evolved version and the human-designed version each improve a target agent.
The final private-score means were 0.780 and 0.782, with 3 random seeds per group. This test does not establish an advantage for the evolved version, nor does it prove the two are equal.
The upgrade record exists, but the second exam has not produced a clear winner.
Another curve is also worth examining. The incremental gains from SPIN's four rounds of training were, in order, 2.66, 1.32, 0.85, and 0.19.
Per-round increments in the average metric across the paper's six tasks, in metric points. This describes only this set of experiments.
It is still improving, but the gain added each round is shrinking. To make progress faster and faster, one would need to find larger gains in the next round, or lower improvement costs.
Let the curves land in a table first
These differences are easily overshadowed by an attractive chart. I had the session generate a claims table, a timeline, and research charts, and reviewed the build code and run results in the Notebook. When I encountered the Review risky code review card, after checking its scope, I approved building the local output.
This execution built the research outputs and did not train any model; the full screenshot preserves the syntax error and the recovery record. The sketch in this article is a presentation further organized from the research material.
If a number needs changing, go back to the table; if a conclusion needs changing, someone has to find the error.
Ask a reviewer to poke holes in the curve
I asked for an independent review and received the first result in Subagents: REVISE.
It caught an easily overlooked problem: if the control group is regressing, a new version that merely regresses less can appear to be "ahead." Can we then declare that it is accelerating? The decision rule was subsequently amended with a test for its own changes, and the experimental budget was filled in.
Source verification also corrected a striking number: Self-Instruct's 6.8 → 39.9 is ROUGE-L and cannot be written as accuracy.
The review left specific comments; what it can check still depends on what evidence it was given.
This round of research thus produced three experimental designs. The key is to give the old and new versions the same budget, have them improve targets they have not seen, and account for failed candidates and human interventions together. The experiments have not yet been run, but what to test next is now clearer.
The second exam also needs a ledger: how much time and compute did it cost to get one better version?
How fast can the loop run on the compute it saves?
Why is 0.7% worth getting excited about?
The AlphaEvolve developers report that scheduling optimization recovered 0.7% of the compute across the entire fleet.
Another compute-kernel optimization shortened Gemini's overall training time by 1%.
Both figures are run results reported by the developers, and their denominators differ.
Within a huge compute pool, saving a small slice can also give more experiments a chance to run. That compute could also be used to serve more customers. Whether efficiency gains can feed back into the R&D loop depends on how the team uses them, and on how much it costs to run the next round of search, verification, and implementation.
If AI becomes strong, what happens when the most worthwhile use is for it to keep building the next generation of AI?
First, this turn of the technical cycle: AI becomes better at doing research, effective research investment increases, algorithms improve, and the next generation of AI becomes stronger.
Conceptual sketch: returns must truly feed into the next round, and the strength of feedback also changes as bottlenecks shift.
Now look at the funding loop: better AI creates value that people are willing to pay for, and new revenue can support more compute, data, and R&D.
The Economics of Recursive Self-Improvement breaks these links apart and models them: if capability improves a little, how much effective research does that bring? If research increases a little, how many good algorithms can it find? And once algorithms get better, how much does that improve the AI used for research?
Each link determines how strong this loop is. Good ideas get harder and harder to find, and repeated work and experiments queuing up eat away at the gains.
When external labor and compute inputs stop growing, can this feedback chain still speed up progress? A rough calibration in this preprint suggests that the feedback at the time was not yet enough to sustain self-maintaining acceleration, even though it appeared to be strengthening. The judgment depends on indirect data and model assumptions.
What if automating AI R&D triggers an intelligence explosion? asks about a faster scenario: could progress that once took years be compressed into months or less? Work that is hard to automate, experimental compute, and long training cycles could all hold this chain back.
A small example shows why bottlenecks matter.
Suppose one research cycle takes 2 days of coding, 1 day of training, and 1 day of validation, 4 days in total. Now AI speeds up coding tenfold.
This is an artificially designed serial-process example with fixed quality and no overlapping stages; it is not a measurement from the paper. The overall speed is about 1.8 times the original.
Coding now takes only 0.2 days, but the remaining steps still wait 2 days. When hundreds of AIs propose experiments at once, the GPU queue keeps growing, and research speed is held back by experimental throughput. Clinical validation of drugs, grid construction, and organizational decisions each have their own clocks.
Whose bill does this change?
For research teams, the first thing that may change is the cost of an experiment: with the same budget, can they try more reliable ideas? For model companies, the question also includes whether revenue can be reinvested in R&D, and whether chips, electricity, and data can keep up.
For users, the key is whether capability can leave the lab. Being better at optimizing training algorithms does not guarantee being better at handling real work; deployment and organizations must also keep up. The economic model therefore separates R&D capability from broader economic capability.
Teams that control compute, models, and distribution channels may find it easier to feed gains back into the next round; cheap research tools and reusable public records, on the other hand, give more people a chance to take part. How employment and income distribution will change is something current RSI experiments have not yet answered.
After reading this, the number I most want to track has become:
How much money and time in total did it take to get one verified, genuinely useful improvement?
Only when unsuccessful candidates are counted too will this bill show whether the loop has become more efficient.
The results are saved; where's the evidence?
This ledger still awaits new experiments to fill it in. I reopened the review and charts in the project and checked Provenance → Reproducibility. This panel also revealed a gap: the automatic dependency graph did not capture anything, and execution evidence was unavailable. So I additionally kept a local build check.
Research records help verify sources and process; checking build output is not the same as reproducing the paper's model experiments.
Sources, claims, revisions, and charts have been left behind. Can the next person who takes this over continue following these clues?
Where will the next researcher start?
If I only handed over that 20% → 50% chart, the most eye-catching number would survive, but the conditions of the evaluation tasks, frozen models, and version selection would have to be found all over again. I want to leave behind the path the conclusion took as well.
So I tried using Open-Science's .science to bring this RSI research into another project. I chose Full export, expanded the content list, and could see the latest review, build packages, and different file versions separately.
There was a small hiccup during packaging: the sensitive-content check flagged the auth variable used to generate the reference list. Expanding the code showed it was concatenating author names. After verifying this, I continued; once copying and validation finished, I got a 44.24 MiB research package.
The 445.6 MiB in the screenshot is the interface's estimate before export; 44.24 MiB is the size of the file finally saved.
Switch projects: do the numbers still have their origin?
I created another project and imported the package into it. The preview listed 8 branches and 71 messages, and the discussions and file versions came along with the results into the new project.
The latest review can already be opened, and earlier versions and messages can be browsed. The imported research history remains read-only, and the code was not automatically rerun. I first checked the files actually received: the latest review and the final build package are byte-for-byte identical to the originals.
Then, using the materials in the export package, I reran the build in a separate directory: the four CSVs and the reference file are completely identical; the labels, dates, and content of the two research charts match, though the layout differs.
The materials were transferred and the output was rechecked. Next, attention should return to the improvement capability itself.
Hand the unanswered question to the next round
I clicked Fork to continue, opening an independent, editable session from the received records. The imported read-only history is still there, and the new input box is ready to take the next question:
After being improved, will an agent be better at improving itself on a type of task it has never seen before?
The fork was actually created. The question in the screenshot is an unsent demo draft, which was cleared after verification.
This handoff was completed between two projects on the same computer. The chart reconstruction used an existing Python environment separately; it did not reproduce the model experiments in the paper, nor did it verify environment recovery across devices.
Whether AI progress can accelerate on its own remains an open question. A next round of experiments that also counts failures will make this question a bit more concrete.
Original texts and materials
The figures in this article come from papers or developer reports; this project's work consists of literature research and output building as of October 11, 2026. All external links are gathered here, with original titles and inspection locations retained.
[1] Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents — Sections 3–4: archive search, frozen base model, and results on the 200-task subset.
[2] What if automating AI R&D triggers an intelligence explosion? — September 2026 institutional version: software feedback, research friction, and a conditional acceleration scenario.
[3] The Economics of Recursive Self-Improvement — fixed v1; Sections 2.2–2.6 on technical and financial feedback, Section 4.1 on rough calibration, Section 4.3 on economic impact.
[4] Reflexion: Language Agents with Verbal Reinforcement Learning — Sections 3 and 4.3: verbal memory, retries, and test misjudgment.
[5] STaR: Bootstrapping Reasoning With Reasoning — Section 3 and Algorithm 1: filtering, rationale generation, and iterative fine-tuning.
[6] Self-Play Fine-Tuning Converts Weak Language Models to Strong Language Models — SPIN; Section 6, Appendix B Table 4: demonstration data and round-by-round results.
[7] AlphaEvolve: A coding agent for scientific and algorithmic discovery — Sections 2 and 3.3: algorithm search and two deployment efficiency results.
[8] Hyperagents — Sections 3 and 5.2: editable task and improvement programs, transfer of improvement capability.
[9] Metaⁿ: Recursive Self-Improvement through Emergent Depth — Sections 2–4: fixed improvement operations and layer-by-layer accumulation.
[10] Recursive self-improvement of AI research agents — AIDE²; Sections 3.2–3.3 and 3.6: seven rewrites and the direct-improver test.
[11] Self-Instruct: Aligning Language Models with Self-Generated Instructions — Table 3: 6.8 → 39.9 corresponding to ROUGE-L.
[12] Projects and source folders — project settings, Agent Context, and directory access instructions.
[13] Product entry points: Open-Science · GitHub · @aipoch_ai. The official project is licensed under Apache-2.0 and supports multiple model providers, Skills, and connectors. Project files stay local, but the necessary context sent to the selected model may still leave the machine.
[14] AIPOCH Open-Science .science: Share Research with Context — introduction to .science research packages; this article adds the actual export and import experience of this project.
〔15〕AIPOCH Open-Science Ranks First in the Reported ASI-Bench B1 and B2 Comparison — A local evaluation released by the product team. B1 at 79.35 and B2 at 56.11 are the task quality scores it reports; the 0.02-point difference from the same-model comparison is not enough to prove a statistical advantage. This project has not run any product benchmarks.
〔16〕.science research packages — Official operating guide: export scope, read-only record import, Fork, and execution boundaries after receipt.