AI giants have collectively hit the brakes, but the real RSI is still a long way off.

Has AI reached a point where it must slow down its development?

In the past few days, Anthropic and OpenAI have successively signaled that they will "slow down the advancement of cutting-edge AI capabilities", which is regarded by the industry as an active cooling-down measure by Silicon Valley AI giants in the face of security risks. The secondary market reacted first, with technology stocks and semiconductor stocks under collective pressure. NVIDIA once fell by more than 3%, while AMD, Intel and Micron all saw declines of around 5% during the trading session, and the PHLX Semiconductor Index also dropped by nearly 6% at one point.

What has triggered market concerns is that the key assumption supporting the high growth expectation of AI infrastructure has encountered new variables: when those who have been stepping on the AI accelerator begin to actively talk about "braking", the growth logic that "models continue to become stronger, and capital expenditures around computing power, chips and data centers keep rising" is no longer taken for granted.

The source of this round of "braking theory" points to a long-standing sci-fi-themed proposition: Recursive Self-Improvement (hereinafter referred to as RSI). What it envisions is a set of self-evolution scripts in which AI begins to participate in improving, and even building its own next-generation system.

In 2026, RSI has gone beyond the scope of futurology and security discussions, and has become a hot topic in AI academic agendas, engineering practices and startup financing narratives. But putting aside emotions and returning to technology, what exactly does AI self-evolution mean? At what stage has today's AI self-improvement reached, and how far is it from real RSI?

We talked with Qu Ao, an MIT PhD who has long been engaged in this field and a former member of ByteDance's Seed team, and the following are his observations.

RSI is a technical intersection, but it is still a gimmick for now

If you only look at the past six months, you will feel that RSI has suddenly become popular. But if you extend the time horizon, this is not a new problem that emerged out of nowhere in 2026. It is more like several basic routes that have evolved over the past few years and converged in the same direction today.

1. No need for humans to write code manually, RSI has gained a real foothold

I started working on reinforcement learning (RL) in 2019. At that time, I thought reinforcement learning was closer to "intelligence" than pure natural language processing (NLP). Because it discusses how a system interacts with the environment, gets feedback, and then changes its own behavior. But the tasks that could be done at that time were very limited, and the model capabilities were far less than today's.

The emergence of ChatGPT refreshed people's understanding of the capability boundary of language models. Language models have a larger action space, and for the first time, ordinary people can feel that a model can continuously accept instructions through natural language and handle increasingly complex tasks.

After that, the reasoning capabilities were iterated round after round. DeepSeek R1, which everyone has a strong perception of, is a very important node. It shows that large-scale reinforcement learning can be applied to reasoning, and also makes the industry re-see the space for reinforcement learning in the era of large models.

After that, this change became more concrete. Anthropic's Opus 4.5 is a clear node. At this stage, the model can work continuously for a long time. Many tasks that used to require manual disassembly and repeated modification by humans can finally be completed by continuously entering prompts and making adjustments. We can even say that there is basically no code that cannot be "written" by prompts now.

This change is critical to self-improvement. Because once the agent has sufficiently strong programming capabilities, coupled with increasingly mature context management capabilities, it can continuously run on a task for a long time, and independently complete the loop of reading code, modifying code, executing, checking results, and then proceeding to the next round. Many links that used to require human intervention can now be completed automatically in the same agent loop.

In this process, context management has also gradually evolved from an "external capability" to a native capability of the agent. It can remember where it has reached, manage longer and longer tasks, and with the support of tools and code execution, long-horizon tasks have become feasible.

So in my opinion, the most important change in 2026 is that AI has begun to have the conditions to keep doing one thing, which is also the premise for self-improvement to truly evolve from a concept to an engineering problem.

2. What has been implemented today is only the "local loop" of RSI

It is also in this process that I began to re-examine those seemingly scattered research directions in the past few years.

One line is AI for discovery, which later evolved all the way to auto-research, that is, letting the agent propose solutions by itself, run experiments, and then continue to explore based on the results.

The other line focuses on "how to make agents more capable of doing things", modifying memory, creating tools, accumulating skills, or continuously optimizing the entire harness, which is the working framework that agents rely on when doing things.

My own research path actually spans both of these lines. From reinforcement learning and agent memory, I have been working on multi-agent auto-research. When we were developing CORAL, we even struggled with whether it should be classified as "auto-research" or "harness evolution".

So now when I look at RSI, I think although it is a buzzword, it does connect many things in series. What used to look like different schools of thought now have a common coordinate when placed in the framework of "how AI participates in building the next generation of AI".

But we still need to distinguish two concepts here. Most of what we can see today is actually continual self-improvement: AI accumulates experience in the process of continuously interacting with the environment, users and tasks, and then uses this experience to update itself. What it updates is not necessarily only model parameters, but also memory, prompts, tools, skills, and even the entire harness.

The strictly defined RSI goes a step further. One of its ideological origins can be traced back to the ultraintelligent machine proposed by I. J. Good in the 1960s: if a machine begins to participate in designing the next generation of machines, and the next generation can continue to build a stronger one, the improvement of capabilities may enter a recursive acceleration process.

In other words, becoming stronger through continuous experience is only the starting point of RSI; going further, AI also needs to participate in design, training, and even personally build the next version of itself.

It can modify the harness, adjust the training process, generate training data; or go deeper to write GPU kernels, and even participate in the design of next-generation hardware. Therefore, the more completely we define the "machine", the higher the threshold of RSI will be.

According to my understanding, a large number of current practices are more appropriately called continual self-improvement. Strictly defined RSI still has a long way to go.

When we were developing Reef, we also preferred to use the word improve rather than evolve. Because the latter only means "it has changed". In engineering, we care more about another thing: how do you know it has really become better?

AI can of course keep changing, but change itself is meaningless. It may learn bad experiences, or treat an accidental success as a rule. Humans are easily influenced by the company they keep, and models are the same. You can't let it evolve randomly.

After AI finishes the work, the path to gaining real capabilities has just begun

1. No matter how long it works, without learning, it is only "performing on the spot"

As mentioned earlier, my own research has evolved from memory to multi-agent auto-research. In this process, a problem has become increasingly obvious: agents can become more and more capable in the context, but this improvement has an upper limit.

Later, we developed CORAL to let multiple agents do research on their own, share information, and iterate solutions. In the early stage, relying only on the evolution of context, memory and harness, the effect can be pushed to a very high level; but once the task is extended, the system will gradually get stuck.

An intuitive problem is that the agent has done a lot of things and accumulated a lot of experience, but the model itself has not gained new capabilities because of this.

It can remember where it encountered pitfalls this time, call more tools, and optimize the workflow to be smoother. But after the task ends, most of these experiences still remain in the context and memory, and have not really entered the model. It is a bit like a person who becomes more and more skilled by relying on notes when working on a project, but after the project ends, he retains very little knowledge in his mind. The next time he encounters a similar problem, he still has to go through many processes again.

So later when we started to do test-time training, test-time RL, and self-distillation, what we wanted to verify was: can the experience generated by the agent in real tasks be learned back into the model. After practice, we found that this path can indeed break part of the upper limit of pure inference.

Then another question arises: if agents work in the real world every day and generate new experience every day, why can these experiences only be used once?

Traditional large model development roughly goes through several stages: Train, Evaluate, Deploy, and Inference. At the inference stage, the model starts to work for users, but a large amount of experience generated synchronously usually does not automatically return to the next round of learning.

For example, if it reworks three times today because it misunderstood a requirement, it may not become smarter when encountering a similar task tomorrow just because of these three reworks.

What Reef wants to solve is how to reconnect this path, so that what agents have done in the real world, what mistakes they have made, and what they have been corrected by users can all become materials for the next round of learning.

Therefore, for continual self-improvement, inference should not only be the end of each task, but also the starting point of generating new experience. Every time AI completes a task, it may also be accumulating experience for "the next version of itself".

2. If AI wants to learn better, it must first know what "good" means

The difficulty of self-improvement varies greatly in different tasks.

The simplest type is tasks where there is almost no dispute over the quality of results, such as optimizing GPU kernels. Every time the agent modifies the code, it can directly run it to verify the result: is it faster or slower? If the modification really improves performance, then this path is worthy of reward; if performance deteriorates, it means this attempt is ineffective. After doing it many times, the model will gradually learn what kind of writing and modification methods are more likely to improve performance.

This type of task is relatively easy to do because the verification standard is very clear. Faster is faster, slower is slower.

A more complex case is to let the agent "run a company". There is a very interesting benchmark in academia called CEO Bench, which simulates the market environment to evaluate the agent's ability to make business decisions. When we run such tasks, if the model is never updated, some agents will eventually drive the company to bankruptcy.

But unlike kernels, running a business will continuously generate feedback: after this decision, do customers increase or decrease, does the cash balance rise or fall, and does the company continue to survive or go bankrupt in the end. The agent has to look at the results after a period of time to know whether the previous decision was a good one.

So at this point, the feedback is no longer a simple pass/fail. But as long as these changes can be identified and attributed, they can become signals for the next round of learning. After the agent works for a long time, it will have the opportunity to continuously adjust its next decision from its own business records.

Going further, in some dimensions, tasks such as writing style are more tricky. For example, the user repeatedly tells an agent: "I don't like too long sentences", "This tone is too much like AI", "I prefer more direct expressions". In the same round of tasks, it can of course modify accordingly, but the next time it encounters a similar task, it may not really remember what this user considers "good writing".

We have worked on a direction in Reef to gradually internalize this kind of feedback into the model, so that it can retain this preference in similar tasks.

Because there is no unified answer to writing. Some people like short sentences, some people like elaborate descriptions; some people think directness is the best, some people pay more attention to tone and rhythm. No matter how strong the model is, it is impossible to satisfy everyone with the same set of standards.

So from kernel optimization to CEO Bench, and then to personalized writing, the more important change is actually the definition of "good". For some tasks, "good" is a numerical indicator; for some tasks, it needs to be judged from long-term results; for other tasks, even the definition of "good" varies from person to person. If self-improvement wants to move forward, it must be able to handle these completely different types of feedback.

3. Only "training the model" is not enough, only "changing the working method" is not enough either

After the experience is obtained, there is another hotly discussed issue in the industry today: should we modify the model, or modify the harness?

The harness is indeed very important. It can be understood as a complete set of methods, rules and permissions for agents to do things. For example, if you let a coding agent modify code, a good harness will not let it start coding immediately, but first get a full understanding of the entire code repository, and then decide where to start.

These good practical experiences can be gradually precipitated into the harness, so that the original capabilities of the model can be stimulated more stably. It is a bit like equipping a capable person with a more mature workflow: the same person, with better methods, can produce much more stable results.

So there is a popular view now that the upper limit of harness evolution may be higher than that of model evolution.

But I have reservations about this.

No matter how strong the harness is, it can only tell the model "what to do", but cannot replace the model to make judgments. It can tell the model "you should make a plan first", but how to plan for this task is still decided by the model; it can also tell the model "assign the task to several sub-agents", but how to split the task and what each agent does ultimately depends on the model's own capabilities.

In addition, I think it is a bit "unfair" to directly compare who has a higher upper limit between harness evolution and model evolution now. Because today when people do model evolution, most of the time they can only rely on open source models; but harness evolution is often directly built on the strongest closed source models. The two sides do not start from the same starting line.

From the results we have seen now, what is worth exploring is not to choose one of the two, but to improve both sides together.

We are currently working on model-harness co-evolution. Whether it is training both sides at the same time, or modifying the harness first, then training the model, and then continuing to modify the harness, it can achieve effects that are difficult to achieve by only adjusting one side alone.

So it may be too