What Will Change First in Robotics? — Part 1

A few years ago, when I was working closer to computer systems, I spent a great deal of time thinking about why programs were slow. We measured throughput and latency, inspected resource use, read code, and formed explanations. Perhaps the program copied too much data. Perhaps several workers were waiting for the same resource. Perhaps an assumption that worked for one workload no longer held for another. A useful explanation suggested what to change next. Running the program again told us whether the change helped.

Around 2021, while experimenting with GPT-3, I began to wonder how much of this process a language model might eventually perform. Given the measurements and the code, could it suggest the likely bottleneck? Could it propose a different implementation and explain why it should be faster? I initially worried about how accurate its interpretation might become. If a model understood these numbers exceptionally well, it seemed difficult to know where my own expertise would remain useful. Looking back, I think that question was incomplete. A model might not need to be right about every explanation. It might make progress by producing plausible changes, testing them, and discarding the ones that failed.

Now that I work closer to graphics, HCI, and robotics, I recognize something familiar. The physical problems are different, but the work surrounding a successful robot demonstration is recognizable: collect evidence, propose a change, implement it, and try again. Looking ahead from June 2026, I expect some of this work to change considerably over the next few years. I do not expect the changes to arrive in the order suggested by how impressive a robot’s movements look. Some precise, technically demanding tasks may become much easier to develop before seemingly ordinary everyday tasks become dependable. To understand why, I find it useful to look at which parts of other fields have changed, and which parts have not changed in the same way.

A small part can contain the difficult work

In May 2025, Google reported that AlphaEvolve had improved a scheduling rule inside Borg, its system for managing data-center workloads. The rule helped decide how to place work on available machines. According to Google, the deployed improvement recovered an average of 0.7% of its worldwide computing resources. AlphaEvolve had not designed an entire data center. It had changed one decision rule inside a system that made the candidate executable and its consequences measurable. Calling this a small part is accurate, but potentially misleading. A small scheduling function can encode years of understanding about a workload. The size of a component and the difficulty of designing it are different things.

In a robot, the comparable component might choose among possible grasps, decide when to look again, or select a recovery after a failed attempt. I expect the automatic improvement of such components to become more common. Some robots may become noticeably more capable without receiving a new foundation model, because the code and decisions around that model become better. An apparently local change could alter the cost of the entire task.

A result in theoretical computer science makes this possibility harder to dismiss as mere tuning. In work on MAX-4-CUT, AlphaEvolve helped find a small graph construction that strengthened a result about the limits of efficient algorithms. The researchers provided a mathematical route from a suitable finite construction to a general theorem. The discovered object supplied a better construction within that route. Yet the same paper’s MAX-3-CUT construction improved the best result using that approach without surpassing the strongest result obtained through a different proof method. The contribution was real, and its scope was specific.

These are not identical forms of verification. Checking a finite construction inside a valid mathematical argument can support an exact claim. Measuring a scheduler supports an empirical claim about the workloads and conditions tested. A robot experiment introduces further uncertainty about sensing and physical execution. The parallel is not that all three fields are simply quantitative. It is that an important part of a solution can be represented as something a machine can change, while an evaluation supplies useful evidence about the change. The strength of the resulting claim still depends on what that evaluation establishes.

For robotics, I would therefore expect change within research areas before I expected whole areas to disappear. A method for ranking grasps might become a standard target for automatic search while the question of what information makes a grasp transferable remains difficult. A recovery routine might become easy to synthesize for one workcell while failures across unfamiliar objects remain poorly understood. Improving a component can still be research, especially when it reveals a new method or an unexpected result. But repeatedly obtaining a local configuration through an established procedure may become ordinary development. Both changes can happen around the same component.

The difficult task may come first

The systems paper Barbarians at the Gate offers a useful contrast within a single problem. Its authors used automatic code search to order database transactions so that conflicting operations would interfere less. In the online setting, decisions had to be made quickly with incomplete knowledge, and the search did not surpass the existing best policy. In an offline variant, relaxing constraints allowed a more expensive search to improve the comparison baseline. The settings were not a controlled test of every possible cause of the difference. Still, they show why a result cannot be separated from the information and computation available to produce it.

A robot planning a sequence on a well-observed workbench has opportunities that a robot responding to a slipping object does not. It may compare several plans before acting. During a slip, a delayed answer can be a bad answer even if the reasoning behind it is better. This does not mean reactive control will remain outside AI’s reach. It means that more computation, better observations, and faster execution are different resources. Progress in one does not automatically compensate for the absence of another. Predictions about robotics need to distinguish the cost of discovering a behavior from the time available to execute it.

The DeepSeek-R1 report gives another example. Its reinforcement-learning approach used checkable answers and executable tests to improve reasoning on mathematics and coding tasks. The authors also reported that long evaluation times limited their use of large-scale reinforcement learning for software-engineering tasks, where they did not observe a large improvement over the base model. This was not learning from nothing: a pretrained model already supplied substantial capabilities. The ability to obtain useful feedback repeatedly helped determine which capabilities could be improved through that training process.

Now compare inserting a pin with clearing someone’s desk. Insertion may require difficult contact control. But a particular workcell can make the initial state repeatable, instrument the result, and return the robot to another attempt. Clearing a desk may require no equally precise movement, yet the robot may not know whether a paper is rubbish, whether a cup is still being used, or where its owner wants an object placed. The distinction is not between a hard physical task and an easy one. It is between different obstacles to making improvement repeatable. Some obstacles concern control. Others concern information or the meaning of success.

My expectation is that demanding manipulation in well-prepared environments will improve faster than its apparent difficulty suggests. This is conditional on useful starting skills, adequate observations, and affordable recovery; a reset mechanism alone cannot teach an arbitrary behavior. Equally, an everyday task does not remain difficult merely because a person cares about the result. Preferences and corrections can become learning signals. What matters is whether the system can obtain the evidence it needs without requiring a researcher to reconstruct the experiment after every failure. The order of progress may follow that cost more closely than it follows our intuitive ranking of tasks.

Learning a behavior is not the only thing being learned

Vision-language-action models, or VLAs, connect visual observations and instructions to robot actions. They make it possible to start a task with a shared learned policy rather than a completely new controller. The move toward broader starting capabilities is visible in RT-2 and π₀. More recent work also changes what happens after that starting point. Physical Intelligence’s π*₀.₆ combines demonstrations, human corrections, and autonomous experience, reporting improvements in reliability and throughput on the tasks evaluated. The model’s initial behavior is no longer the only object of interest. So is the process that improves it after deployment.

April’s π₀.₇ results suggest a related change in how people can supply that improvement. In its air-fryer example, a zero-shot instruction did not produce complete success. Step-by-step language coaching helped, and fine-tuning the high-level policy on the coaching improved autonomous execution without additional teleoperated demonstrations for that adaptation. This is not the same as having learned nothing about the task. Rather, existing skills made a different form of teaching useful. As these starting capabilities improve, I expect some new tasks to require less direct motion demonstration and more correction of sequence, conditions, or intent.

The next question is whether selecting the learning method must itself remain a manual task. In 2025, DiscoRL learned rules for updating agents from experience and evaluated the discovered algorithm beyond the environments used to discover it. This was meta-learning, not a language model rewriting code. Its relevance is nevertheless direct: the rule used to learn behavior was itself subject to learning. Eureka had shown another route in 2023, using a language model to generate reward code, train policies in supplied simulations, and revise the rewards from the results. These approaches automate different parts of learning-method design rather than merely executing a fixed training recipe.

This month’s ENPIRE paper brings coding-agent experimentation into physical robot learning. Its first phase uses human feedback to help construct reset procedures, outcome checks, and execution constraints. The resulting interfaces are then fixed for the policy-improvement phase, in which agents modify training code and inspect real executions. The reported manipulation experiments include insertion and tool use. Their task-success protocol permits retries, so its results should not be read as a universal first-attempt reliability claim. What matters for my forecast is the combination: physical feedback informs changes to how the policy is trained, not only to which action it takes next.

I expect these developments to meet in a more reusable development process. A system could first test what an existing policy can already do, then choose among additional demonstrations, reinforcement learning, changes to a planning routine, or a more precise instruction. It would not have to use the same intervention for every task. A failure caused by the wrong sequence does not necessarily need more low-level motor data. A failure during contact may not be repaired by rephrasing the goal. Automating the choice among interventions could matter as much as making any one learning algorithm more effective.

The stronger prediction is that developing a new capability may become much cheaper before robots acquire broad, immediate competence in arbitrary environments. A robot could still fail on first exposure while the system surrounding it becomes much better at diagnosing and correcting that failure. A machine that knows every task and a development process that can teach many tasks cheaply are different possibilities. Watching only zero-shot demonstrations could cause us to miss the second one.

The next bottleneck may be the experiment

A reset is not just another line of training code. A dropped object must be found or replaced. A successful insertion may need to be undone. A camera can move, a fixture can loosen, and a failed attempt can leave the scene outside the conditions assumed by the next attempt. These are familiar possibilities in physical experimentation, not evidence that automation is impossible. They explain why counting only active robot data can underestimate the cost of learning. For my forecast, the relevant quantity is the effort required to obtain another informative, trustworthy trial, including everything needed between trials.

Even theoretical work can run into the cost of checking candidates. In the MAX-CUT study, AlphaEvolve also accelerated the verification procedure. The authors nevertheless checked their final constructions with the original exhaustive method. They did not make the theorem depend on trusting the faster search-time checker. That distinction suggests a useful architecture for robot development: use inexpensive models and simulations to explore widely, then use independent physical evidence to check the selected improvements. Fast evaluation and final confidence need not come from exactly the same procedure.

For graphics, this creates a demanding role for simulation and reconstruction. Consider two simulated objects that reproduce the same observed movement but use different friction parameters. They may predict different outcomes for a new grasp. Matching what the camera has already seen is not enough to establish which prediction to trust. A useful experiment might involve moving the object slightly or observing contact from another direction. I expect increasing interest in scene representations that help decide which policy to use, which failure to investigate, or which physical measurement to collect, rather than treating visual resemblance as sufficient evidence of a useful robot simulator.

This also makes the design of the workcell part of the learning system. Fixtures, object supply, sensing, and reversible actions can reduce the cost of experimentation. A narrowly prepared environment may therefore support rapid improvement even while a general household environment remains difficult. Preparation is not necessarily a failure of intelligence. It is a design choice whose cost should be visible. The important comparison is whether the preparation pays for itself across many trials and related tasks, or whether a new expert must rebuild the entire process at every installation.

The gains may be distributed unevenly. A shared policy could make useful behavior available to a small team, while extensive physical experimentation still favors organizations with more equipment and operational support. This is an inference about costs, not a prediction that scale alone will determine the winner. More trials are valuable only when they provide information that transfers. I would look for evidence that a deployment reduces the effort required at the next deployment. A fleet that repeatedly solves the same local problem may be expensive experience, not cumulative learning.

When a research project becomes a tool

From a researcher’s position, it is tempting to sort these changes into the work we are losing and the work we still have. I think that framing hides an important possibility. A capability that once required a research project can become a tool for another research project. Suppose obtaining reliable object transfer no longer consumes most of a year. A team might then study how people coordinate several transfers, how failures accumulate over a long task, or how an assistive system should respond when a person’s needs change. Easier construction can make previously impractical questions approachable. It does not guarantee that the new opportunities belong to the same people or arrive at the right moment in their careers.

Nor does using automated search make a result merely engineering. The finite construction in the complexity-theory example supported new knowledge. An automatically discovered robot-learning rule could do the same. Conversely, months of manual implementation do not, by themselves, establish a new research contribution. I would distinguish the effort required to obtain a result from what the result teaches us. For a proposed learning method, that means comparing against strong alternatives with comparable models, data, physical trials, and human support. Otherwise, more resources or better preparation can masquerade as a better method. For a new discovery, the contribution might instead be the result itself, a counterexample, or a previously unknown failure condition. Their significance does not depend on every step having been performed by hand.

Some work may nevertheless become more routine. Applying a known adaptation procedure to another object, connecting standard interfaces, and configuring a familiar evaluation process could increasingly be ordinary engineering. Ordinary does not mean trivial, unskilled, or unimportant. It means that the main uncertainty may concern delivering a known capability under local constraints rather than establishing something not yet understood. Making research usable is an accomplishment. But a paper may need to say more than that its authors successfully repeated a procedure now available to others.

The boundary will not stay still. The ADRS authors identify tightly coupled system changes, weak evaluation, and expensive experiments as difficult settings for their approach. They also exclude problem and evaluation setup from the reported iteration time. In robotics, the corresponding questions include how modules interact, what happens outside the test conditions, and who prepares the experiment. These are current limits of particular methods, not protected human occupations. The distinction matters: research should investigate those limits rather than assume that naming them establishes a permanent division of labor.

What I would watch over the next few years

My strongest expectation is a growing number of robot tasks developed through shared starting policies and increasingly automatic adaptation. The first broad successes may look less like one robot doing everything and more like many systems becoming competent at related families of work with less specialist effort. Some improvements will come from the VLA. Others will come from a coding model changing the surrounding software, a better outcome checker, or an experiment that produces more useful data. Robotics will inherit progress from several kinds of AI at once, so its rate of change may not be visible in robot-model releases alone.

I also expect a separation between expensive discovery and fast execution. A large model can spend time investigating failures or comparing training recipes without controlling every motor command. Once a better behavior is found, a smaller policy or a piece of code may execute it. This arrangement could connect advances in general reasoning to systems with strict reaction-time requirements. The long-term architecture is uncertain, but I would not assume that stronger intelligence requires one ever-larger model to make every decision at every time scale. The question is where additional computation improves the outcome enough to justify its cost.

A more consequential measure of progress would be how much less work is needed for the next task. I would count the initial setup, the real trials, the recovery, and the human attention, not only the final success rate. I would ask whether experience from one object or workcell reduces those costs for another. I would also separate first-attempt reliability from success after recovery. Recovery can be valuable; concealing its cost is not. The relevant outcome is dependable work under stated conditions, and a development process whose claimed savings remain after its supporting labor is included.

Several developments could change this forecast. Much stronger out-of-the-box generalization could reduce the importance of task-specific adaptation. More faithful simulation could replace more physical trials than I expect. Conversely, costly resets or poor transfer could keep automatic experimentation confined to prepared stations. A high score on a familiar benchmark would not settle these alternatives. Falling adaptation costs on genuinely new tasks would be much stronger evidence. This is why I am more confident about the direction of some development practices than about a date for broad household autonomy.

When I first worried about language models in systems research, I imagined competing with a machine’s interpretation of a performance trace. I now think the larger change concerns which parts of a problem we can afford to search, test, and reuse. Robotics adds physical consequences and, often, people whose purposes are not fully specified by the task description. Those conditions will shape the order of progress. They need not stop it. Perhaps one of the next important changes will be that teaching a robot something new becomes less of a research project. For researchers, that is not only a reason to ask what has become ordinary. It is a reason to ask what we can finally investigate once it has.

Continued in Part 2 — When Doing the Task Is Not Enough, which asks what happens after a robot can do the task.