Inside OpenAI's Agentic Software Factory

This post is based on Gergely Orosz's deep dive published on The Pragmatic Engineer, Sep 15, 2026. The author visited OpenAI headquarters and interviewed seven engineering leaders and engineers: Venkat Venkataramani (VP of Engineering, Applied Infra), Sulman Choudhry (Head of Engineering, ChatGPT), Andrew Ambrosino (Lead, Desktop), Joe Gershenson (Lead, Core Agent team), Akshay Nathan (Engineering Lead, Productivity), Ahmed Ibrahim (Engineer, Codex), and Steve Coffey (Engineer, Responses API).

It's rare to work with an unlimited token budget, but at OpenAI, that's what all engineers, researchers, finance colleagues, and marketing folks do. The author visited OpenAI's headquarters a year after his previous trip, and the change is fundamental: Codex has gone from a "nice-to-have" tool to being the backbone of pretty much everything at the company.

1. Codex Takes Over at OpenAI

Starting around January, Codex — and lately Codex and ChatGPT Work — have taken over everything there. Desktop lead Andrew Ambrosino:

"The big theme of the past months has been that everything is now a coding agent. Whether the visible code is your output or not, agents write your artifacts. Think of it like this: your entire life is via software. You have these powerful tools (agents) in your computer, and the ability to loop and reason and write code is the ability to do everything."

Figure 1: Codex usage since August 2025 at OpenAI by department. Source: OpenAI

The numbers: in a four-month period, non-engineering orgs like finance, recruitment, and legal went from ~0% usage of Codex to 90%. Now, almost all OpenAI employees use Codex and ChatGPT Work weekly. What happened?

• Product cadence. OpenAI released the Codex app for Mac in February and for Windows in March, and ChatGPT Work (powered by the Codex harness) in July. Non-engineers then moved all their workflows over to Codex and then to Work.
• Adoption even while the product was hostile to non-engineers. OpenAI got close to 40% adoption across non-engineering teams at a time when the Codex app still showed code on-screen (February–April). Non-technical colleagues still used it because it could do complex work like researching and creating a presentation, document, or spreadsheet. Today, those folks are very heavy users.
• Working longer on more complex things drove adoption. OpenAI added the /goal setting to Codex: you set up a goal for the agent and it keeps working until it is complete. Between April and May, usage surged from 60% to 90%. Andrew believes improvement in the harness's handling of long-running tasks was one cause:

"The number one thing that is changing is that people are starting to use threads for much longer, and this longer usage has been a breakthrough. 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."

"Codex being good at longer-running tasks seems to cause people to do fewer things in parallel. This is 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."

• An "awareness overhang" replaced the capability overhang. Akshay Nathan, Engineering Lead, Productivity: "For a long time, we had a 'capability overhang': the models were capable but the products didn't fully bring that out. Now, we're seeing an awareness gap. Some people have figured out they can use Codex to monitor Slack, update Airtable, or create onboarding materials. But many others still use it for one task and then discover more uses from teammates via word-of-mouth. But there's still so much more, under the surface, that you can do with Codex."
• Role-specific and team-specific plugins are created and distributed. Andrew on why a generic coding agent is not enough: "If you build a product that can do anything, teams need a way to make it their own. You can't just give everyone an empty box. Skills and plugins let teams adapt the agent to their work. Sometimes, we also need a new app capability, like a browser that the agent can use alongside those skills. But the same building blocks already cover a lot of different roles."
• Subject matter experts are embedded in ChatGPT Work engineering teams. In some domains the models have become "smarter" than developers, so devs cannot channel "taste" into the harness there. Domain experts are onboarded onto engineering teams to advise on what a good slide deck, spreadsheet, or business report looks like. (A decades-old best practice, rediscovered every few years in new contexts.)
• OpenAI is fully dependent on Codex and Work. So much so that in the event of even a minor outage, internal messages from colleagues alert the Codex and Work teams at the same time as — or before — automated alerts. From the outside, this dependence on a single shared harness is striking: two years ago, there were no AI agents, only advanced AI autocomplete.

2. Death of the IDE & Pull Requests

Late last year, the Codex team was torn about whether to release the Codex desktop app. Andrew recalls:

"In December 2025, we weren't entirely sure if we would release the Codex app. We had the Codex CLI as a terminal, and there are large, feature-rich IDEs out there. So, would there be space for a dev tool that is between a terminal and an IDE? In my head, there was this future where it would not work out, and be the kind of 'misfit' like the iPad was. A lot of people buy iPads and then never use them: they either use their smaller, more portable smartphone (which could be the equivalent of the CLI in this metaphor), or their feature-rich laptop (the equivalent of the IDE). Also, don't forget that in November, Antigravity came out as a VS Code fork. This added to the feeling that perhaps we should have also forked VS Code for the Codex app. But still, we dismissed the temptation and went with our gut feeling that as AI agents get better, IDEs will matter less."

Indeed, since January, IDE usage has gone down and OpenAI's bet looks like a good one. However, the Codex app is becoming a little more akin to an IDE: for example, the ability to edit files inside the app was shipped in June.

CI/CD Systems Are Seeing Massive Load Increases

Venkat Venkataramani, VP of Engineering, Applied Infra:

"The number of pull requests (PRs) per engineer is growing like a hockey stick (at a very high, accelerating rate). Every part of the build-test-deploy pipeline is seeing dramatically more load. 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."

"That level of acceleration exposes bottlenecks everywhere: version control has to handle far more code being written and pushed, CI/CD systems have to scale with it, and production release processes have to absorb a much higher rate of change. Every month, we wake up to a new set of infrastructure scaling challenges to solve. Just when we think we've created enough capacity for the next phase of growth, the model unlocks another wave of capabilities, which creates a new set of bottlenecks somewhere else in the system."

PRs and Code Reviews Are Being Rethought

"The question we ought to ask ourselves in the middle of all this development acceleration is how do we reimagine many things we took for granted. For example, how do we reimagine the CI and CD process? What does observability mean in this world, and how should people interact with pull requests? If you ask me, the way we do code review today makes less and less sense, and the same is true for pull requests. We're now seeing agentic code reviews that look at code changes through a series of different lenses. In the past, it would have been impractical for a cloud infrastructure engineer and a security engineer to review every single code change. With agents, that becomes possible. We can rethink how code is deployed with agents, too. We are building an agent that 'handholds' a change all the way to production — whether it's a code change or a change behind a feature flag. It observes the relevant monitoring graphs, but can also build its own dashboard to monitor important signals. More of our code changes are going to production with this kind of agent monitoring."

An Increasingly Painful Bottleneck: Native Mobile Releases

When there are ten times more pull requests, backend and web deployment needs more infrastructure. But the real choke point is native iOS and Android app updates: every app update needs to go through Apple's and Google's manual approval processes, which take hours or days.

Sulman Choudhry, Head of Engineering, ChatGPT (formerly at Facebook):

"Back in the 2010s, Facebook had a pretty important breakthrough in how to ship native mobile code faster. App Store releases went from monthly to bi-weekly to weekly. At the same time, experimentation and feature flags let teams ship code before it was ready to launch, then turn features on remotely when they were. That model brought a lot more velocity to mobile. In the age of Codex, I think we're hitting the next version of this problem. Code generation is getting dramatically faster, but getting that code into users' hands on native mobile is not. For Codex in particular, where usage is heavily mobile-first, that gap is already becoming painful for us and users. I expect the pressure here to increase quickly. If software can be written in minutes, waiting days or weeks to get it onto a phone starts to look increasingly absurd. 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."

There's some irony here: shipping a native iOS or Android app has the exact same challenges today as in 2008, when the App Store launched. In 18 years, not much has changed — Apple still does not officially allow apps to bypass the App Store review process to ship meaningful experience changes.

3. OpenAI's Agentic Software Factory

The "software factory" is similar to a physical factory where robots and humans produce autos together — in the software context, AI agents and humans producing software. Some manufacturing sites are fully automated "dark factories" where illumination isn't needed because there are no humans. Could the same fully automated process emerge in software engineering? At OpenAI today, there's a "software factory" running, and it's all built around Codex.

Figure 2: The "traditional" software development pipeline vs OpenAI's agentic infra pipeline today. Source: The Pragmatic Engineer / OpenAI

The Nine-Step Pipeline

1. A human builder defines the desired outcome. A software engineer or product manager specifies the problem and desired outcome. Judgment, prioritization, and taste are becoming more important for this phase. Interestingly, Venkat notes that engineers at OpenAI are becoming more like product managers than traditional systems engineers.
2. Codex gathers context. OpenAI has moved all its documentation inside of the source code. Codex also has access to: Git repositories and GitHub; Slack and Notion; internal data sources (Databricks, Datadog, internal logs, etc.); and internal Codex skills — some of which are maintained by OpenAI's Codex implementation itself. Codex is so "plugged" into OpenAI that new engineers are directed to ask Codex any questions they have during onboarding.
3. Codex implements code changes. Codex gets to work, makes a series of code changes until it reaches its goal, and verifies that the software works as it should.
4. Build & test, then CI. The agent builds the code, runs the tests, fixes the code when it breaks the test, and then creates a pull request. The PR triggers CI to run a more thorough suite of linters and tests. The agent babysits the PR until it's "green", fixing any CI failures and automatically updating the PR. New: a perf harness — the agent also uses a perf harness to send problematic PRs to the Synthetics A/B framework for evaluating performance implications.
5. Agentic code review. Instead of one generic AI code reviewer, OpenAI spins off multiple agents, each with a "domain specialist" configuration. Venkat sees this as equivalent to having a human domain expert from each relevant infrastructure team review every change. Code changes are classified by risk: high-risk changes go through stricter processes (more AI reviews, or a mandatory human review after the agents finish); low-risk changes follow an easier path — areas of the codebase can opt in to an agent that will auto-approve low-risk PRs, removing human acceptance as a bottleneck. Risk assessment also automates when additional compliance input is needed: either via another agent or human review. With the quantity of PRs being produced, humans simply couldn't review all code without assistance.
6. Agentic deploy. After a human approves a change to go to production, it is assigned its own agent with an instruction that could be summarized as: "Handhold this change until it is safely and fully rolled out into production." For a change behind a feature flag, the agent will: read the codebase and figure out where the flag lives; understand what the change does; decide which signals indicate success and failure; build its own monitoring dashboard (a genuinely new practice); and watch the relevant production signals and its dashboard(s). OpenAI's long-term goal is a "per-change autonomous SRE" — an agent that can deploy pretty much autonomously.
7. Observe production. Tools tracking production include dashboards generated by the agent in previous steps, and OpenAI's internal observability stack (custom tools generating logs, metrics, trace & wide event data). The big change since pre-Codex days: engineers used to create dashboards to monitor services; now agents do this at the granularity of per-change deployment.
8. Production monitoring feeds back into development. OpenAI's "Perf Factory" uses agents to sift through alerts and dashboards, de-duplicate signals, identify real latency regressions, root-cause them, and propose fixes — extending the workflow beyond deployment into continuous improvement.
9. Respond to outages. Sevbot is OpenAI's internal incident response agent, built on Codex. When an incident is detected, the bot "wakes up": it collects context about the incident; determines possible mitigations (but never executes any); answers devs' questions (it's part of the Slack channel); and an engineer can tell it to apply a specific mitigation. OpenAI's goal is for Sevbot to take autonomous action when mitigating some outages — the dream is that no humans get woken up outside working hours because Sevbot handles "routine" outages autonomously, with humans reviewing its actions afterward. But as of now, oncall duty is not a thing of the past at the company.

What's Internal vs What You Can Buy

A key caveat — and the article's real thesis: OpenAI's internal version of Codex is a lot more advanced than its external counterpart because it's plugged into pretty much every OpenAI system — similar to how Ramp's Inspect AI agent has been wired up. Conflating this pipeline with the Codex product you can install today is the most common misreading of the diagram.

Stage	What happens	Internal only or shipped in Codex
1 Software builder	An engineer or PM defines the outcome	Human step, not software
2 Codex writes/edits code	Pulls context from source, docs, GitHub, Slack, Notion, internal skills, Databricks, Datadog	Shipped (Codex writes code); the internal context graph is internal only
3 CI: build + test	Pipeline rebuilt for agent-scale load, plus a "Perf Harness"	Shipped (your own CI); OpenAI's scaling work is internal
4 Agentic code review	Parallel review from data, infra, cloud, and security specialist agents, plus risk classification	Internal only
5 Low-risk decision	Low-risk changes proceed; higher-risk get additional human review	Internal only
6 Agentic deploy	An agent "babysits" the change into production, builds its own dashboards	Internal only
7 Production monitoring	The agent watches graphs, signals, and alerts on the internal observability stack	Internal only
8 Outage → Sevbot	Investigates the incident, proposes mitigations, answers questions	Internal only
9 Perf Factory	Filters duplicate alerts, finds latency regressions, proposes fixes	Internal only
10 Loop back	The agent fixes issues until CI and reviews pass, then the builder gets proposed fixes	Describes the internal loop

In other words: outside teams can adopt stages 1–3 today (plus a slice of stage 2), while stages 4–9 describe a direction, not a purchasable feature. That's not a knock on OpenAI — internal tooling at that scale takes years.

4. Cross-Checks from OpenAI's Own Data

OpenAI's Economic Research paper "How agents are transforming work" (June 2026) quantifies the trend:

• Longer-horizon work. By May 2026, 80.6% of sampled individual users made at least one Codex request estimated to exceed 30 minutes of human work; 70.2% exceeded one hour; 25.6% exceeded eight hours.
• Codex became the primary AI tool for every department. Engineering moved first; Legal, Finance, and Recruiting crossed over around April 2026. For the average OpenAI worker, Codex now accounts for more than 85% of output tokens — and 99.8% of weekly output tokens generated within OpenAI.
• Non-developer adoption outpaced developers. Since August 2025, non-developer users rose 137x for individual users, 189x for organizational users, and 12x within OpenAI.
• Role boundaries are blurring. Over one-fourth of work done with Codex by workers in business functions was engineering or coding.
• Heavy parallelism. By June 2026, users at the 99th percentile regularly generated more than 60 hours of Codex agent turns per day, distributed across multiple, parallel agents.

5. A Few Sober Readings

• Harness efficiency is the key variable of the software factory. The jump from 60% to 90% adoption was driven by the harness's improved handling of long-running tasks — not by a bigger model. Factory throughput depends on how long the harness can run unattended and how many useful sub-agents it can spin off, not on single-shot generation speed.
• "The surface area you, as a human, have to manage" is the new metric. Long-running agents spinning off sub-agents actually reduce what humans must manage. When evaluating agent systems, quantify human attention load, not just output rate.
• Review is the new bottleneck; risk tiering is half the answer. With 10x PRs, human review cannot cover everything. OpenAI's dual-track approach: auto-approve low-risk areas, mandate human review for high-risk ones — and automate the decision of when compliance input is needed.
• The last mile of shipping remains unsolved. App Store / Google Play manual review is a physical constraint no agent can route around. Code is generated in minutes but takes days to reach phones — a gap that is becoming the new pain point.
• What stays human. Builders still define outcomes; humans still approve high-risk changes and authorize incident mitigations; Sevbot's actions are reviewed after the fact; oncall rotations still exist. The line that captures the shift better than any stat: "Judgment, prioritization, and taste are becoming more important."

Note: the original article is for paid subscribers. This write-up covers its publicly visible portions (sections 1–3) plus OpenAI's official economic research data; sections 4–7 (engineering tooling & practices, infrastructure for a billion users, API reliability & performance, and how the software engineering job is changing) sit behind the paywall and are not paraphrased here. Subscribe to the original for the full piece.