When Code Becomes the Universal Interface: Inside OpenAI’s “Software Factory”

When tech writer Gergely Orosz stepped into OpenAI headquarters again, only a year had passed since his previous visit, yet the underlying foundation of how work is done had completely transformed. Codex evolved from a "nice-to-have" coding tool into a shared operational portal for engineering, research, finance, recruiting, legal, and marketing teams alike; ChatGPT Work, designed for general knowledge work, is also built atop the Codex harness execution framework. Employees may not produce code as their final artifact, but agents write code, invoke tools, and generate documents and spreadsheets behind the scenes to turn objectives into deliverable results.

This account draws from seven interviewees: VP of Applied Infrastructure Engineering Venkat Venkataramani, Head of ChatGPT Engineering Sulman Choudhry, Desktop Lead Andrew Ambrosino, Core Agents Team Lead Joe Gershenson, Productivity Team Engineering Lead Akshay Nathan, Codex Engineer Ahmed Ibrahim, and Responses API Engineer Steve Coffey. Accounts across these disparate roles assemble a coherent trajectory: agents first change how individuals work, subsequently multiply code output, and ultimately compel testing, review, deployment, and live site operations to be re-architected in unison.

A crucial evidentiary boundary must be made explicit here. Metadata for the original report lists the full piece at 7,686 English words behind a paywall; the currently public page offers only the introduction, Sections 1 through 3 in full, and the opening paragraph of Section 4—amounting to roughly 3,536 words, or approximately 46% of the complete article. Subsequent body sections covering internal tooling and debugging, billion-user infrastructure, API reliability and performance, and shifts in engineering roles remain unpublished. The following explainer addresses solely the publicly accessible content that can be verified point by point, without reconstructing arguments for the second half based on table-of-contents previews.

From a Coding Tool to a Company-Wide Work Portal

The inflection occurred rapidly. The Codex desktop app launched for Mac in February and Windows in March, followed in July by ChatGPT Work powered by the Codex harness. Within a few months, non-engineering teams like finance, recruiting, and legal went from barely touching Codex to the majority using it weekly. This viral spread did not stem from managerial mandates.

Figure: Codex's share of monthly output tokens for the average user across departments. Source: OpenAI / The Pragmatic Engineer.

Even more noteworthy is that the product was not polished at the time. Between February and April, the Codex app still displayed raw code directly on the screen—quite unfriendly to non-technical users—yet adoption among non-engineering teams still approached 40%. The reason was pragmatic: even with an interface resembling a developer tool, it could already handle complex tasks such as research, building presentations, generating documents, and crunching spreadsheets, yielding enough value to outweigh the usability barrier.

Subsequently, long-horizon task capabilities pushed adoption from around 60% to 90%. Users could state an objective via /goal and let the agent work continuously, with threads persisting over multiple days. Andrew Ambrosino observed a counterintuitive shift: the longer agents worked, the fewer concurrent tasks humans managed, because a single long-running thread would spawn other subagents to tackle subproblems in parallel. Human responsibility narrowed from juggling numerous fragmented conversations to stewarding a handful of overarching goals and verifying their deliverables.

Another driving force was what Akshay Nathan termed the "awareness gap." The underlying model capabilities had existed for some time, but many employees did not know which everyday workflows could benefit from them. Someone would first use Codex for a single task, then learn from a colleague that it could also monitor Slack, update Airtable, or prepare onboarding materials. Use cases spread through word of mouth, and teams subsequently packaged mature workflows into role- or team-specific plugins. The general-purpose agent thus ceased to be an empty text box, entering specific roles loaded with business context and familiar tools.

This tailoring also revealed the boundaries of the engineering team's expertise. Developers knew how to construct harnesses, but did not necessarily understand the standards of an exceptional presentation, financial model, or commercial briefing. Consequently, OpenAI embedded domain experts into the ChatGPT Work engineering team, allowing specialists to directly define the taste and requirements of "high-quality outcomes." The point is not that models outperform experts across every discipline, but that developers cannot rely on their own intuition to set quality benchmarks for every specialized field.

Internally, Codex at OpenAI integrates with far more proprietary corporate systems than the public offering, which limits direct external analogies. This integration runs deep enough to create operational dependencies: even during minor hiccups, messages pinged to the Codex and Work teams by colleagues often arrive alongside or ahead of automated monitoring alerts. External organizations cannot simply install the same product by name and assume identical outcomes will follow naturally.

Data later released by OpenAI complements these interviews, but statistical accounting boundaries must be strictly maintained:

• For the average OpenAI employee, Codex accounts for more than 85% of their AI tool output tokens; across the company, Codex generates 99.8% of all weekly output tokens. This reflects output-token share, not headcount or hours worked.
• Among OpenAI daily active users, 99th-percentile power users log over 60 hours of agent-turn runtime per day across multiple parallel agents. Parallel runtime can easily exceed the 24 hours in a calendar day and cannot be equated to a human working 60 hours in a single day.
• In a May 2026 sample of individual users, 80.6% submitted at least one prompt estimated by the model to represent over 30 minutes of human work, 70.2% submitted at least one representing over 1 hour, and 25.6% submitted at least one representing over 8 hours. These figures represent the model's directional estimates of "equivalent human task duration," not the actual clock time the requests took to run, and certainly not independently measured productivity.

While these metrics demonstrate a migration from short query-response loops to long-horizon delegation, they do not independently prove that code quality improved, that staffing requirements decreased, or that any other company replicating the setup would achieve identical productivity.

The IDE Did Not Disappear; The Basic Unit of Work Changed First

The Codex desktop application was almost never released. In December 2025, the team already had the Codex CLI, and fully featured IDEs existed across the market, making it unclear whether an intermediary tool between a terminal and an IDE held standalone value. Andrew Ambrosino likened this concern to the iPad: users might prefer a more portable phone or a more powerful laptop, leaving the middle device without a natural home.

Meanwhile, Antigravity emerged in November as a VS Code fork, further tempting the team to build atop an established editor. Yet OpenAI ultimately decided against forking VS Code. Their bet was that as agent capabilities matured, developers would spend less time directly manipulating an IDE, shifting their focus toward outcome definition, task delegation, and result evaluation. A decline in internal IDE usage starting in January suggests this transition is underway; however, the Codex app also added file-editing capabilities in June. This set of facts is better interpreted as "the IDE no longer monopolizes the entry point to development," rather than a declaration that the IDE is dead.

What truly changed is the fundamental unit of work. Previously, developers authored line-level edits within an editor; today, humans specify an outcome, allowing the agent to locate context, modify multiple files, run verifications, and incorporate downstream feedback. When the unit of production expands from "editing a block of code" to "fulfilling a goal," the pace of code generation outstrips the design capacity of traditional engineering infrastructure.

Venkat Venkataramani observed a hockey-stick surge in PRs per engineer, with certain build, test, and deployment systems absorbing nearly a tenfold increase in load over roughly six months. Where other companies might take two or three years to encounter comparable growth, OpenAI ran into a fresh set of scaling bottlenecks almost every month: version control needed to absorb more code, CI/CD had to run more jobs, and deployment pipelines had to ingest higher-frequency changes. With every step forward in model capabilities, the bottleneck traveled further downstream.

This is why traditional PRs and code reviews began to feel obsolete. If every code delta still relied entirely on humans conducting manual, line-by-line inspections, human cognitive throughput would impose a hard ceiling. Yet abandoning code review is unviable, as it simply flushes risk straight into production. OpenAI's approach breaks review into specialized agents, risk routing, and explicit human gates, enabling review capacity to scale alongside change volume.

Native mobile development highlights another category of bottleneck that internal automation cannot eliminate on its own. iOS and Android updates must still clear Apple and Google app store reviews, which often take hours or days. Sulman Choudhry recalled how Facebook in the 2010s gradually accelerated mobile releases from monthly to bi-weekly and then weekly, relying on experimentation systems and Feature Flags to ship code bundled in client builds while remotely controlling when features went live. That strategy dramatically accelerated mobile velocity back then, but still feels sluggish against today's software changes that can be generated in minutes. Codex usage at OpenAI leans heavily toward mobile, yet native mobile app deployment remains far from the immediacy of web deployments.

This case illuminates the true constraints of the software factory: agents can compress internal production time, but they cannot conjure away store reviews, compliance mandates, and production risks. Once generation accelerates, previously negligible external wait times emerge as the dominant bottlenecks in delivery cycles.

The Nine-Step Closed Loop: Code Generation Is Merely One Step in the Middle

The "software factory" borrows an analogy from manufacturing: humans and robots assemble cars together; in software, humans and agents collaboratively build, release, and maintain systems. Manufacturing even features "lights-out factories" that require no illumination, but OpenAI's current workflow is not an uncrewed system. Humans define outcomes and approve production releases; incident agents currently only suggest mitigations and will not execute them without explicit authorization from an engineer.

Figure: After humans define outcomes, Codex forms feedback loops with context, CI, review, deployment, production observability, Perf Factory, and Sevbot. Source: The Pragmatic Engineer.

The end-to-end workflow comprises nine interconnected, mutually reinforcing steps:

1. Humans define outcomes. Software engineers or product managers first articulate the problem and desired outcome. Venkat observed that engineers are increasingly functioning like product managers: as coding is largely delegated, judgment, prioritization, and taste matter more. Agents can amplify execution, but they cannot decide for an organization what is worth building or what standard of outcome is acceptable.
2. Codex assembles context. OpenAI co-located documentation within source repositories, allowing code and explanations to evolve in lockstep. Codex can also access Git repositories and GitHub, Slack and Notion, Databricks, Datadog, internal telemetry logs, and team skills; some internal skills are even maintained by Codex itself. Because integrations run so deep, newly hired engineers are advised to ask Codex directly when navigating system architecture.
3. Agents implement and verify changes. Codex iteratively modifies code toward the objective until requirements are met, verifying software behavior along the way. Public materials do not state that a specific sandbox is mandated, nor do they limit verification strictly to local environments; undisclosed runtime environments should therefore not be treated as established facts.
4. Build, test, and await passing CI. The agent builds code, runs tests, refines the implementation based on failures, and creates a PR to trigger the broader linter and test suites. It continuously shepherds the PR, resolving CI failures and updating changes. An additional performance harness submits only PRs flagged as potentially problematic to a Synthetics A/B framework to evaluate performance impact; not all PRs undergo this expensive performance testing suite.
5. Specialized reviews, risk routing, and compliance dispatch. Instead of invoking a single general-purpose code reviewer, the system spawns multiple review agents configured for specific domains. Gergely was initially skeptical: simply prompting a model to "act as a cloud infrastructure expert" does not automatically produce expert judgment. The viability of this approach hinges on giving agents access to relevant code and documentation while focusing bounded context on a narrow domain. Low-risk PRs can only be auto-approved by agents if the affected code area explicitly opts in; higher-risk changes trigger additional AI reviews or mandate human inspection. The system also automatically determines, based on risk, when additional automated compliance checks or human compliance inputs are required. Coding agents continue to monitor review comments and remediate issues.
6. Agents escort releases. Only after a human approves a change for production does the system assign a release agent to it. The agent identifies the relevant Feature Flags, understands the delta, determines which signals denote success or failure, spins up its own monitoring dashboard for the release, and continually watches rollout health. OpenAI's long-term aspiration is to cultivate capabilities approaching "an autonomous SRE for every change"; this represents an engineering ambition, not an already realized state of fully autonomous deployment.
7. Observe production at change-level granularity. Observability sources encompass the dashboards generated in the preceding step alongside OpenAI's internal observability stack emitting logs, metrics, traces, and wide events. Where engineers previously constructed static dashboards for entire services, agents can now spin up telemetry views scoped to an individual change, making "is this specific commit healthy?" an independently trackable question.
8. Production signals loop back to development. Perf Factory filters signals from alerts and dashboards, deduplicates noise, isolates genuine latency regressions, pinpoints root causes, and proposes remediation code. While the report's introduction summarizes that it can spin up Codex agents to tackle performance issues, the publicly described workflow confirms only that it proposes fixes; one cannot extrapolate that patches bypass review to automatically merge or deploy.
9. Sevbot assists in incident response. When an outage strikes, Sevbot aggregates context, evaluates potential mitigations, and fields questions from developers in Slack channels. It currently does not enact mitigations autonomously; an engineer must designate a specific action before authorizing it to execute. OpenAI hopes that Sevbot will eventually manage a subset of routine incidents autonomously so on-call engineers are spared off-hours awakenings—with actions audited retrospectively—but for now, human on-call rotations remain active.

Examining these nine steps collectively reveals that the essence of the factory is not "one model writing all the code," but rather three interlocking capabilities keeping each other in check: machines handle high-frequency execution and continuous observation, automated systems deliver verifiable feedback, and humans retain ultimate accountability for outcomes, risk boundaries, and production operations. Absent any single layer, heightened code throughput risks merely manufacturing queues, noise, or outages at a faster rate.

Current Human Checkpoints versus Future Automation Directions

Based on present realities, humans still guard three pivotal checkpoints: defining the problem and desired outcome at the outset; granting final approval before code touches production; and issuing explicit authorizations whenever Sevbot carries out a concrete mitigation. Higher-risk code may also be forced into mandatory human review. Describing OpenAI's current setup as a completely uncrewed "lights-out software factory" is inaccurate.

Yet this does not imply the boundary will remain stationary. OpenAI is actively exploring endowing release agents with more comprehensive change-level SRE responsibilities, and envisions Sevbot eventually resolving certain routine incidents autonomously. The true evolutionary path is to first construct sufficiently dependable context, risk categorization, automated testing, and production signals, and only then incrementally broaden the perimeter of autonomous execution. The present baseline and long-term ambitions must both be recognized: the vision should not be conflated with capabilities already achieved, nor should today's human checkpoints be assumed permanent.

What Other Teams Can Actually Learn

OpenAI's operational model rests on conditions rarely found together: co-locating documentation with code; granting agents access to GitHub, Slack, Notion, Databricks, Datadog, internal logs, and custom skills; fast-feedback build, test, CI, and production telemetry; automated risk stratification and compliance routing; and substantial token and compute budgets. The public materials reflect interview observations and official metrics within OpenAI; they do not prove this operating model has been universally validated as safe, nor that it can be transplanted wholesale into every organization.

A more transferable sequence is to first make systems machine-comprehensible, test-verifiable, and constrained by production feedback before ramping up raw code generation volume:

• Co-locate documentation that genuinely governs implementation alongside code, establishing accountability mechanisms to keep them synchronized;
• Equip agents with the comprehensive context needed to complete tasks, while explicitly demarcating boundaries for read/write permissions, audit trails, and production operations;
• Build tight feedback loops spanning tests, CI, performance benchmarking, and production observability to surface regressions as early as possible;
• Calibrate the depth of agent reviews, compliance inputs, and human sign-offs based on change risk, rather than subjecting all code to a monolithic pipeline;
• Benchmark how much throughput downstream build, review, deployment, and operational systems can absorb before deciding to further accelerate generation velocity.

The most fundamental lesson of this software factory is that code is no longer the sole scarce resource. When agents drastically compress the cost of implementation, scarcity migrates toward high-fidelity context, actionable judgment, rigorous verification capabilities, and the willingness to shoulder operational risk. What engineering organizations must transform is not merely the entry point of an editor, but the entire chain from goal definition to production feedback.