OpenAI’s lawyers and recruiters now work through Codex

Some of OpenAI’s build, test and deploy systems now carry roughly ten times the load they did six months ago. Meanwhile, Codex agents write, review and deploy code through an automated pipeline the company calls its software factory. Venkat Venkataramani, VP of Engineering for Applied Infra, described both the load and the pipeline in a September 17 report from The Pragmatic Engineer.

The newsletter spoke with seven OpenAI engineers and engineering leads, and its first finding has nothing to do with infrastructure. In about four months, non-engineering orgs such as finance, recruitment and legal went from roughly 0% Codex usage to 90%, and nobody above them mandated it. Almost every OpenAI employee now uses Codex and ChatGPT Work each week, and every employee has an unlimited token budget.

Why finance and legal moved over

The Codex app reached Mac in February and Windows in March. ChatGPT Work, which runs on the Codex harness, followed in July. Non-engineering adoption at OpenAI hit close to 40% while the app was, in the newsletter’s words, hostile to non-engineering users: between February and April it still showed code on screen. People used it anyway because it could research a topic and produce a presentation, document or spreadsheet. One caveat applies to the internal build. It is plugged into almost every OpenAI system, so it can do far more than the public version.

The jump from 60% to 90% came between April and May, after OpenAI added /goal. With that setting, the agent keeps working until a stated goal is met. Andrew Ambrosino, who leads Desktop, believes better handling of long-running tasks in the harness was one cause of the jump:

“It’s surprising to see the sheer length of time that people spend on a thread – even days! They often set a goal and then have the model crank.”

Longer runs also meant people ran fewer tasks in parallel, Ambrosino said, “because a long-running agent often spins off other agents to do other things, reducing the surface area that you, as a human, have to manage.”

Akshay Nathan, engineering lead on the Productivity team, calls the current gap an “awareness overhang”. For a long time the models could do more than the products drew out of them. Now the gap is in what people know to ask for. Some employees use Codex to monitor Slack, update Airtable or write onboarding material, Nathan said, while others use it for one task and pick up new uses from teammates by word of mouth. Each team now packages its own role-specific workflows as plugins. “You can’t just give everyone an empty box,” Ambrosino said.

The newsletter also reports two side effects. Domain experts now sit on ChatGPT Work engineering teams: in some fields the models have become “smarter” than the developers, so the developers can’t bring taste to the harness there, and someone has to tell them what a good slide deck or business report looks like. And OpenAI depends on Codex and Work so heavily that during even a minor outage, colleagues’ messages reach those teams at the same time as the automated alerts, or before them.

A bet against the IDE

In December 2025 the Codex team was not sure it would ship a desktop app at all. Ambrosino said he could picture it becoming a misfit stuck between the CLI and full IDEs, the way he sees the iPad sitting between phone and laptop. When Antigravity launched as a VS Code fork in November, the team was tempted to fork VS Code as well. It went instead “with our gut feeling that as AI agents get better, IDEs will matter less.” IDE usage at OpenAI has fallen since January. The app has also picked up some IDE features: in June it gained the ability to edit files directly.

How the factory runs

Venkataramani’s pipeline starts with a human. An engineer or product manager defines the problem and the outcome they want, and he said OpenAI engineers are becoming more like product managers than traditional systems engineers. Codex then gathers context. OpenAI has moved its documentation into the source code, and the agent can read Git repositories and GitHub, Slack, Notion, Databricks, Datadog, internal logs and a set of internal Codex skills, some of them maintained by Codex itself. New hires are told to take their onboarding questions to Codex.

The agent writes the change, builds it, runs the tests and fixes whatever breaks, then opens a pull request. It watches the PR until CI is green and pushes fixes for any failures. A newer addition, a perf harness, sends suspect PRs to a Synthetics A/B framework that measures their performance impact.

Review is split among several agents, each set up as a domain specialist. Venkataramani compares this to having an expert from every relevant infrastructure team look at every change, which he said was impractical when the reviewers were human. Gergely, who writes the newsletter, said he first doubted that an agent told to act as a cloud infra specialist would review any differently from a generic one. He concluded that it comes down to how these agents are set up and what context they can reach: every Codex agent has full access to OpenAI’s code and docs, and each one spends its limited context window on its own domain.

Changes are also sorted by risk. High-risk changes can get more AI reviews, or a required human review once the agents finish. Parts of the codebase can opt in to an agent that auto-approves low-risk PRs, which removes human sign-off from that path.

Once a human approves a change for production, it gets its own agent with an instruction along the lines of “Handhold this change until it is safely and fully rolled out into production.” For a change behind a feature flag, the agent finds where the flag lives, works out what the change does, decides which signals mean success or failure, builds a monitoring dashboard for that one change and watches production. Before Codex, engineers built dashboards per service. Now agents build them per deployment. The long-term aim is what OpenAI describes as a “per-change autonomous SRE”.

Two more loops start in production. Perf Factory has agents go through alerts and dashboards, de-duplicate signals, find real latency regressions, trace their root causes and propose fixes. Sevbot, the incident agent, is also built on Codex. It wakes up when an incident is detected, collects context, works out possible mitigations and answers questions in the incident’s Slack channel. It never executes a mitigation itself. An engineer has to tell it to apply one. OpenAI wants Sevbot to handle routine outages on its own eventually, with humans reviewing what it did when they are back at work. For now, people at OpenAI are still on call.

Ten times the load

The number of pull requests per engineer is “growing like a hockey stick,” Venkataramani said, and every stage of the build-test-deploy pipeline is feeling it:

“We’re talking about roughly a 10x increase in load on some systems. At most companies, that kind of growth might happen over two or three years. At OpenAI, we see it in about six months.”

Version control, CI/CD and release processes have all hit bottlenecks, he said, and “every month, we wake up to a new set of infrastructure scaling challenges to solve.” He also questions the review model itself: “the way we do code review today makes less and less sense, and the same is true for pull requests.”

Native mobile releases are an increasingly painful bottleneck, because every iOS and Android update still goes through Apple’s and Google’s manual review, which takes hours or days. Sulman Choudhry, Head of Engineering for ChatGPT, saw Facebook move in the 2010s from monthly to weekly App Store releases and ship unfinished code behind remotely switched feature flags. He thinks fast code generation brings the next version of that problem, and that for Codex, whose usage is heavily mobile-first, the gap already hurts.

“We should be aiming for a world where shipping code on native mobile is as fast as shipping on the web. Getting there will probably require some creative rethinking of what we ship, when we ship it, and what can be activated remotely. Today, we’re nowhere close.”