Reading research acceleration from inside OpenAI

Patrick Rho · AI Research

Simon Willison wrote a short post on September 6 titled Research acceleration: The view inside OpenAI. It pulls together OpenAI's coordinated writing about RSI, a companion essay on the research process, and notes on how the research team uses coding agents every day to describe how research speed changed during 2026. The acceleration it describes means AI compute used per researcher rose fast while agentic engineering became ordinary work. The original is linked under the title.

The post is short, but I spent a while on it. On the surface it reads like a news roundup from inside OpenAI. Between the lines, questions keep appearing. Why did the term RSI surface now, how did agents change daily research, and what does the bend in the spend chart actually say. What interests me more is not the grand wording but the place where routine and numbers meet. Tool stories and a spend curve sit side by side in the same post. Wording can be skimmed, but tools and numbers ask to be reread. This piece follows those two threads slowly.

Why this short roundup deserved a long read

Willison's post is brief. It opens with the observation that OpenAI seems to be having an RSI day, introduces the companion essay An Alien Mind by Jakub Pachocki, moves into how the research team uses coding agents, and closes on a chart of AI spend per researcher. Summarized, it fits in a few lines. After summarizing, something remains. An organization known for releasing models and papers started explaining how it works, how much it runs, and which word it uses for the trend, all at once. Models used to come first and work habits leaked out later in fragments. This time the order is different. Work habits, usage volume, and vocabulary arrive together.

When I look at a model release, I usually look for the work log before the score table. Which tools were used, where time was saved, where people had to step in. Scores are results. Work logs are process. Process changes pull results along. The OpenAI news reads the same way from this angle. What matters more than a new model announcement is what the team runs every day. I picture agents writing experiment code, sorting failures, and chaining the next attempt. I say picture because the original does not publish the detailed procedure. Even so, the direction is clear. Unit tasks in research are moving from human hands to agent runs.

When our team reviews new AI work, we do not look only at the announced numbers. We look at what actually changed and how that change reshapes a team's day. If nothing in daily work changed behind the numbers, we treat it as fashion. If daily work changed, we treat it as structure. This story feels closer to the second case. It names 2026 as the year agentic engineering took hold, shows an internal spend curve, and brings out the term RSI. Each piece is small, but together they say the production method of research has changed.

What the unexplained arrival of the term RSI tells us

One detail stands out. The term RSI appears with almost no definition. Willison writes that today feels like RSI day at OpenAI, for Recursive Self-Improvement, and moves on. He adds that the companion essay An Alien Mind covers the same theme. The post assumes readers already know the term or at least will not find it strange. I paused here. When an organization introduces a concept to outsiders, it usually defines it first. Writing without a definition suggests the word is already ordinary inside.

RSI is an old phrase. It points to the idea that a system improves itself, and the improved system improves again, so speed compounds. The words are simple. The practice raises many questions. What is being improved, code, weights, or experiment design, where do people stay in the loop, and who grades the result. Willison's post does not answer these. It only reports that several pieces arrived around the same time. I think the more important result is not the definition but the coordination. Multiple pieces landing together means the message was aligned. Organizations do this when they want outside conversation to gather around one word.

This is where I would be careful not to over-read the post. The appearance of the word RSI does not mean a self improvement loop is finished. A gap sits between wording and implementation. When insider language first moves outside, it often carries an announcement character. It signals direction, attracts people, and tries to set the terms of discussion. So I read this news as the arrival of vocabulary rather than proof of capability. The fact that an internal word came outside matters, and it matters more that it came bundled with tooling stories and a usage curve. The word alone says little. The bundle of wording plus tools plus numbers says more.

Why 2026 became the year of agentic engineering

Willison reports that 2026 was the year agentic engineering really took off inside OpenAI, in line with the wider industry. Reading that line, I recalled the shift from the past year. Code completion grew into agent runs, single file edits widened into repository scale tasks, and one call turned into a flow that plans, uses tools, and summarizes results. Research labs are no exception. If anything they feel the change sooner, because they run many experiments, many failures, and many repeats.

The phrase agentic engineering carries two meanings at once. Building agents, and engineering alongside agents. The first joins models, tools, and evaluation. The second remakes a person's day. It decides what to hand to an agent, what to inspect directly, and where to stop the run. The news here leans toward the second. The center is that researchers actually use coding agents, and that usage grew fast. It is a report on changed work rather than an announcement of a new agent model.

The next point follows quickly. Better tools do not automatically mean better outcomes. When agents write code faster, experiment cycles shorten. Shorter cycles mean more attempts. More attempts raise the chance of a good result. That chain feels natural. But more attempts also raise review load. Someone must sort why each attempt failed, whether the failure was luck or structure, and what to change next. As agents take over execution, human work concentrates on judgment. Judgment becomes the bottleneck. The 2026 story says the execution bottleneck loosened. How to loosen the judgment bottleneck remains the next question.

The daily scene of researchers using coding agents

The most concrete part of the report, for me, is the everyday use of agents by the research team. Not a grand vision but daily tasks. Agents sit inside the flow of writing code, running tests, organizing results, and designing the next experiment. Reading this, I recalled a familiar pattern. At first a team hands an agent a small job. Fix a few files, run the tests. When it works, the scope widens. Read the whole repository and make a plan. When it fails, the scope shrinks. After a few weeks of this cycle, each team develops its own feel. A sense of which jobs go to the agent and which stay with people.

From a systems perspective, the next question is obvious. How large is the repository the agent touches, how long do tests take, and how fast can the cause be found on failure. Research code differs from product code. It lives briefly, ties to a hypothesis, and breaks easily. Dependencies tangle, docs are missing, and assumptions known only to the author hide inside. For an agent to move well in such code, the runtime environment must be solid. Tests must run with one command, failure logs must read cleanly, and rollback must be easy. With a weak setup, even a good tool runs slowly. With a solid setup, even an ordinary tool runs fast. I read the OpenAI story as an environment story as much as a model story.

One more shift matters. Researchers using agents does not mean researchers read less code. It means they read differently. Instead of reading while writing, they read while reviewing. The work of checking diffs, reading test results, and picking out strange choices grows. If this review is slow, the whole pipeline is slow. If review is fast, the whole pipeline is fast. So skill in the agent era moves from writing code fast to noticing strangeness fast. Knowing what looks off, what passed by luck, and where to dig deeper. The original does not publish these review details. Even so, the direction is clear. Human hands move from execution to judgment.

Where the spend per researcher curve bends sharply

The part of Willison's post that remains as a number is the AI spend per researcher chart. This internal tracking figure climbs to the right, and the slope turns much steeper near late July. Reading that, I pictured the shape. A gently rising curve that shoots up past some point. Teams in the field know this shape well. It appears when a tool improves, when permissions widen, or when an organization officially says to use it. The point where personal and voluntary use becomes an official team flow.

The word spend needs care. Money going out does not by itself prove research got faster. What the money buys matters. Whether it paid for inference or training, for exploration or evaluation, for successful or failed runs, each changes the reading. The original does not publish the breakdown. It only says AI usage per researcher rose fast. Before trusting the number at face value, I look at the conditions. The denominator is researcher count, the numerator is an internal tracking figure, and the timing sits in late July. If the denominator is stable, a rising numerator means stronger use. The phrase internal tracking suggests run based measurement rather than a billing view. Clear timing lets us ask about causes.

So how should we take this. I do not read a spend curve directly as a capability curve. Spend is input. More input often brings more output, but the link is not automatic. What is missing is where the input went. Even so, it cannot be dismissed. Research organizations watch money closely. They do not keep raising usage without effect. Managing the figure per researcher means the organization watches this metric. Watched metrics change behavior. Teams build setups that invite agent use, and a culture forms that justifies the volume. The bend in the curve therefore reads less like a billing record and more like the trace of an organization turning.

Pausing before the late July bend

Willison passes along one hypothesis for the bend. It may line up with the moment internal staff gained access to the model later released as GPT-6 Astra. Note the phrasing. It is not stated as fact but as a guess. The observation is that internal access timing and the bend overlap, plus an interpretation that gives the overlap meaning. I found the guess interesting, but I did not accept it right away. Overlap in timing and proof of cause are separated by verification.

Why would this guess come up. A new model changes behavior. Better answers mean more delegated work. More delegated work means more calls. More calls lift the spend curve. This link feels natural. In repetition heavy work like coding and experiments, a quality gap turns directly into a usage gap. Slightly more accurate, slightly better at following instructions, slightly better with tools, and the delegated range widens. Wider range bends the curve. That is the skeleton of the hypothesis. A new model arrived, so usage rose.

Here I want to add some doubt. Other changes may have landed in the same window. The agent runtime may have been cleaned up, teams may have been encouraged to use it, or evaluation habits may have changed. One model rarely explains every change. In practice, several changes stack to make a curve. I do not reject the internal access story, but I would not lock it in as the single cause either. Plausible means it needs checking. I hope the coming posts say more about what changed around that date. We need the detail that separates model, environment, and policy, or tells us it was all three together.

How early internal access changes research speed

Let us accept the hypothesis for a moment and think it through. What happens when an internal team uses a new model before the outside world. Attempt counts change first. Waiting time falls and run counts rise. Experiments once queued overnight run several times during the day. Failed runs get retried. Retries make failure less feared. Less fear invites harder attempts. This loop is the body of research speed. A better model spins the loop faster. A faster loop changes team habits. Teams that spend time on impossible tasks behave differently from teams that speed up solvable ones.

The delegated job types change next. Where an older model received short and crisp tasks, the new model receives long and vague ones. Reading a whole repository and making a plan, reading failure logs and guessing causes, gathering several experiment results and picking the next hypothesis. These jobs resist full specification in sentences. They need context reading and gap filling. Better gap filling widens delegated range. Wider range remakes a person's day. Direct writing time falls and selection time rises. As selection grows, selection criteria matter. The team must decide what counts as good and where to stop.

What I would watch next is the story of those selection criteria. Claims that an internal model improved appear often. Stories of how it was used appear rarely. I want to know which jobs were delegated first, where the process jammed, and how the jam was cleared. The news Willison passes along does not include that detail. Since more OpenAI writing is expected, I hope that part gets unpacked there. A report on how failure handling changed helps more than a statement that tooling improved. Research speed is set less by the pace of success than by the pace of passing through failure.

What the number for acceleration leaves out

A spend chart catches the eye. A curve shooting upward tells an easy story. But much stays outside the frame. I think the more important result is not the number but the structure behind it. Who ran what, for which purpose, and what came out. Those links are missing. Input alone cannot speak for output. A separate output chart is needed. Whether it counts papers, experiment hit rates, model quality, or felt speed must be fixed first. Without that, acceleration stays a feeling.

On the surface it reads simply. More usage must mean faster progress. In practice it does not. The place where usage grew matters. Work spent on search, on verification, or on automating repeats carries different meaning. Search means a wider attempt range. Verification means more careful checks. Automation means more human hours freed for judgment. None of these is bad. But the same curve can hide different contents. The original does not give this split. So I treat the curve as a direction signal and hold judgment on the contents.

Another easy miss is the denominator. When we say per researcher, the range of researcher matters. Whether they write code daily, focus on planning and review, or joined recently changes what the average means. Averages can rise when some teams use heavily while others use little. We need the distribution behind the average. Did usage rise evenly, or did a few teams pull ahead. If a few teams led, their habits may become the next standard. If the rise was even, the whole culture shifted. The next steps differ between the two cases. If more writing follows, I hope distribution comes with it.

Questions we ask together when a new research method appears

When our team reviews new AI work, we do not look only at benchmark scores. We look at what actually changed and what cost structure the change creates in a system. The same standard applies here. After the sentence that the team uses agents come the follow up questions. How is the runtime set up, how often do evaluations run, how are failures grouped, and where does human review enter. Acceleration becomes tangible only with answers to these.

I look at the runtime story first. For agents to run well on research code, rollback must be easy. If one experiment litters the repository, the next experiment slows down. Isolation must hold. Tests must be fast. Slow tests keep agents waiting, and waiting cuts attempts. Logs must read cleanly. Messy logs force people to join the hunt for causes. With these conditions in place, even a modest model delivers speed. Without them, even a strong model stalls. That is why I wonder what sat at the bend in OpenAI's curve, only a model or environment work alongside it.

Next I look at the review slots. When agents run often, people must watch often. Watching everything creates a bottleneck. Watching nothing creates risk. The team must decide what to review and what to pass. I view this choice as team skill. Risky changes get human eyes, repeated changes pass by rule, ambiguous changes pass by sampling. With such layers, quality holds while input grows. Without them, debt piles as input grows. The original does not describe these layers. I hope the coming posts unpack them. How results were selected will outlast how many runs were launched.

Scenes I want verified in the next posts

Willison's post aims to summarize, so detail stays thin. Since more OpenAI writing is on the way, here are the scenes I want to see. First, the concrete range of agent tasks. File edits, experiment design, or result analysis. Wider range makes me ask more about review. Second, the handling of failure. How failed attempts get dropped or kept, and how much human time that choice takes. Third, the list of what changed around late July. If model, environment, and guidance get separated, the curve gains clear meaning.

I like this result, but the data is too thin to generalize from. The OpenAI story will not transfer directly to every lab. Compute budgets differ, code health differs, and team sizes differ. What works in a large organization rarely copies directly into a small team. Small teams need their own method. Pulling many judgments from little compute, dropping failures fast, and keeping review thin. I do not read the OpenAI news with envy. I read it looking for parts to borrow. Environment work transfers across sizes.

One closing question remains. As acceleration grows, what should come first. My answer is to sharpen judgment criteria first. Faster execution makes selection more important. Teams must fix what counts as good, where to stop, and what to keep as record. Without criteria, speed becomes noise. With criteria, speed becomes an asset. If the next posts arrive, I hope they cover criteria. Research speed lives less in how fast runs launched than in what was kept. The news covered here reads closer to a work log than a declaration. Read as a work log, it teaches plenty. I want to verify those lessons in more concrete form next time.