Inside OpenAI Codex: How AI Coding Agents Are Reshaping the Software Development Lifecycle

OpenAI Codex has become one of the most popular AI coding tools around, surpassing 20 million active users. But how exactly did it evolve from an internal research project into a product used by hundreds of millions? In a deep-dive episode of The Pragmatic Engineer podcast, Thibault, the head of the Codex team, shared the technical decisions, team culture, and profound changes AI is bringing to software development.

From Internal Tool to Open-Source Product: The Birth of Codex

Thibault's career path is anything but conventional. He fell in love with computers at age eight when his family moved to a Belgian village of just 200 people and he had "no other choice." He studied applied mathematics, founded a startup doing pharmaceutical supply chain optimization, and later worked at Google Maps and DeepMind before eventually joining OpenAI.

One little-known story: a full year before ChatGPT launched, Thibault was involved in an internal DeepMind project that resembled ChatGPT. That tool spread "like wildfire" internally — people constantly shared conversation screenshots — but DeepMind had no product mechanism to bring it to market at the time. That experience partly explains why he later joined OpenAI: he wanted to be on a team where research and product were genuinely co-designed.

Codex's predecessor was an internal project codenamed A-SWE (autonomous software engineer). The team initially trained models specifically targeting OpenAI's Python codebase, with the goal of helping researchers write code faster. With support from Greg Brockman and Sam Altman — especially Greg's insistence on "not just serving ourselves, but benefiting the world" — the internal research project eventually evolved into a product.

Why Build in Rust? And Why Open-Source It?

One of Codex's counterintuitive decisions was building the core in Rust, even though model support for Rust wasn't nearly as mature as for Python or TypeScript at the time. Thibault explained the first-principles thinking behind it: from the very beginning, the team treated the "product interface" and the "agent core" as two distinct things.

"Early decisions often matter a lot, as long as you don't sacrifice development speed too much." He noted that Rust provides compile-time static validation, which is a massive advantage for an agent — many errors can be caught at compile time. More critically, Rust's boundaries create a natural architectural separation: if everything is written in the same codebase in the same language, "you'll inevitably get a bit sloppy, entangling things that shouldn't be entangled," which blocks future innovation.

Another distinctive decision was open-sourcing. Codex's CLI, SDK, and app server are all open-source and not locked to OpenAI's own models — users can pair it with models from other providers. This is quite rare across major AI labs, where competitors typically ship closed-source coding harnesses.

Thibault openly acknowledged that open-sourcing has both benefits and costs. On the benefit side: new hires need almost no onboarding, since they've already read the codebase and PRs; community contributions bring energy and great ideas. The costs are equally real: the core codebase is separated from the rest of the company's code, sometimes requiring work across multiple repositories and drawing "artificial boundaries"; and what's "a bit painful" is that when the team publicly builds a feature, "sometimes others copy it before we ship." There's also the extra overhead of managing a flood of low-quality random contributions.

On not locking users to their own models, Thibault's logic is "earn users through merit, not through lock-in." Since the code is open-source and anyone could fork it and add 10 lines to support another model provider, they might as well support it natively from the start. This also forces the entire company to stay competitive at both the model and tooling layers — no coasting allowed.

Rust's core advantage lies in its "ownership" memory model — the compiler enforces memory and concurrency safety at compile time, eliminating entire classes of runtime errors like dangling pointers and data races. For an AI agent that needs to run autonomously for extended periods, call external tools, and manage system resources, this means many potential crashes and undefined behaviors get caught before code ships. Python, by contrast, is flexible and rich in model ecosystem support, but its dynamic typing and GIL (Global Interpreter Lock) make it better suited for rapid prototyping than for a high-reliability agent core. The trade-off of "developer experience for runtime reliability" is a long-standing principle in the Rust community, and the Codex team's choice is a direct embodiment of that philosophy at the AI infrastructure layer. Notably, this decision carried real forward-looking risk at the time: around 2021, large language models' ability to understand and generate Rust code was noticeably weaker than Python, meaning the team was trading short-term toolchain costs for long-term architectural health.

The Harness Always Stays One Step Ahead of the Model

One of the most insightful observations in the interview is Thibault's description of the relationship between the harness and the model: the harness always stays one step ahead of the model.

He explains that a model has certain capabilities, but you need "crutches" to help it actually do things well — reaching a level that's reliable, efficient, and meets user expectations. That's precisely the harness's job: providing guardrails and safety guarantees to make the model more controllable and efficient. The harness is also responsible for injecting "developer messages" at the start of each turn, shaping the agent's behavior.

A concrete example: early Codex wouldn't automatically run unit tests after editing code — users had to manually remind it. Later, the team trained models with a better understanding of "user intent," making the reminder unnecessary. As model capabilities improve, developer messages shrink — and the harness itself shrinks too.

This creates an interesting dynamic for how the team works. When they want to implement a capability, they ask: should this be a harness change or a model change? If it's a model change, how long will it take — one month? Three months? Six months? Depending on the answer, they decide whether to build a temporary harness solution first, or simply wait for the model to handle it. The team uses agents to analyze massive volumes of user feedback — not just coding-related, but finance, legal, marketing, and more — to surface themes and inform prioritization decisions.

The term "harness" (the tooling layer or execution framework) has a specific meaning in the AI agent space worth unpacking. It isn't the model itself; it's the entire software infrastructure wrapping the model — responsible for task scheduling, environment interaction, context injection, and safety boundary enforcement. In the context of a coding agent, a harness typically includes: dynamic generation logic for system prompts or developer messages, routing and execution for tool calls, sandboxed environment isolation and resource limits, and state management across multi-turn interactions. The insight that "the harness stays one step ahead of the model" reveals a recurring pattern in AI product engineering: model capability improvements tend to be discrete, gated by training cycles, while user expectations grow continuously. The gap between the two must be filled by harness engineering iteration. This also explains why leading AI product companies can still deliver vastly different user experiences even when their underlying models are comparable — the depth of harness design is where real differentiation lives.

Code Review, Maintenance, and Architecture: Rethinking the Dev Workflow

Thibault previously worked at Google, a company renowned for its rigorous code review culture, which makes his thinking on the changing role of code review especially worth noting.

The Codex team collaborated early with the research division to develop code review models capable of catching logic and reasoning errors at a depth that would take a human "hours of digging through dependencies" to reach. That capability has since been merged into the main model, and team benchmarks show its code review performance "surpasses humans." On the security side, code review has become a mandatory step for all pull requests at OpenAI — PRs flagged with security vulnerabilities are blocked from merging, entirely automatically.

So what role do humans still play? Thibault argues that code review historically served three purposes: correctness, security, and the social function of being "a small ritual for information exchange." The first two are being automated, and what genuinely remains — requiring deep human discussion — is intent: "What exactly are you trying to do? Should this even be done?" He suggests that this kind of discussion can happen outside the pull request, without necessarily revolving around the code itself.

He uses the metaphor of a "box" to illustrate future collaboration models: as long as there are strict guarantees around resource usage, data access, and security, "what happens inside the box barely matters." What you actually need to align on is "what this box does and what invariants it must satisfy." Once that contract is established, no changes inside the box require repeated discussion — which "protects your attention."

Maintenance costs are also dropping sharply. Thibault points out that work like upgrading third-party dependencies and applying security patches — "things that used to get delayed but matter enormously to the business" — is moving toward full automation. The even bigger shift is that re-architecting is becoming extremely cheap. What once took years and was an extraordinarily expensive engineering undertaking can now be dramatically accelerated.

This also means the software lifecycle is being compressed dramatically. A successful project used to take a year to grow to 50–100 engineers; now "a single weekend might see 100 agents contributing code." As a result, good abstractions and modular architectural design matter more than ever — a skill once reserved for architects and senior engineers is now essential for every engineer on the team.

Kata Containers is a technology that combines the security isolation of virtual machines with the lightweight deployment advantages of containers, originally open-sourced by Intel. Unlike traditional Docker containers that share the host kernel, each workload in Kata Containers runs inside its own lightweight virtual machine (backed by hypervisors like QEMU or Firecracker) with its own kernel instance. This means that even if code inside a container exploits a kernel-level vulnerability, it cannot affect the host or other users' workloads — making it ideal for running AI agent tasks submitted by users with unpredictable behavior. For Codex's cloud version, users can have agents execute arbitrary shell commands, install packages, or even train models. These high-privilege operations are inherently security risks in a multi-tenant environment. The choice of Kata Containers reflects OpenAI's engineering trade-off between "openness of functionality" and "multi-tenant security isolation" — sacrificing some startup speed (milliseconds instead of microseconds) in exchange for strong isolation guarantees.

Merging Codex into ChatGPT — and AI as Its Own "Reporter"

From the outside, integrating Codex into ChatGPT looks like just "adding an entry point." But Thibault reveals it involved massive engineering challenges. ChatGPT is a fully managed cloud architecture, while Codex was originally entirely local. The essence of the "merge" was: how do you replicate all the capabilities of a local coding agent in the cloud, efficiently enough to be bundled into a $20/month Plus subscription — "because $20 doesn't even come close to covering what this project costs to run."

Today, Codex's cloud version runs on a powerful managed virtual machine (a Kata Container), and users can even get creative — installing Blender for 3D modeling or training models, since it has internet access. By default, Codex runs in a local sandbox, requesting user authorization for commands that need additional permissions; users can also opt into running it in a managed cloud VM.

One fascinating detail: throughout the entire merge process, Codex itself played the role of "reporter." Because it was connected to all Slack conversations and documents, it could fully document the team's heated debates about "how to merge, what to name things, when to introduce what." Thibault calls this OpenAI's "toggle era" (the introduction of work toggle). The podcast host also admitted there's a faint "Big Brother is watching" quality to it — AI is always present as an observer — but this may well become the new normal for startups.

Advice for Engineers: Curiosity and Clear Communication

On what it takes to be a builder at a place like the Codex team, Thibault offers two pieces of advice:

The first is a deep curiosity about how things work, and the ability to rapidly understand systems. People who thrive at OpenAI can quickly grok a system, dive into an unfamiliar codebase, and untangle the logic. He champions the "five whys" approach — keep drilling down, and learning accelerates dramatically.

The second is staying in sync with the community and users, combined with the ability to think and communicate clearly. "If you can't explain what you're trying to accomplish, can't express your intent, have no connection to the community, and have no taste — doing great work becomes much harder."

On whether AI takes the fun out of engineering, Thibault admits he still occasionally opens an editor and writes some code, savoring that "late-night focus, deep problem-solving" sense of craft. But he emphasizes more strongly: if you think of "code as a tool for solving problems," then being able to solve more problems is itself a massive enabler. "I've yet to meet anyone who says this is bad or not fun." As for the loss that comes with "the model mastering skills I've worked hard to develop," his attitude is: problems will never run dry, and humanity still has a long road ahead — mathematical breakthroughs, scientific discoveries, and finding profoundly human ways to benefit people.