OpenAI's Engineering Decisions Behind Codex: Rust, Open Source, and Automated Code Review

OpenAI's Codex has become one of the most popular AI coding tools today, with over 20 million active users. In this in-depth interview from The Pragmatic Engineer, Codex team lead Thibault breaks down the full journey of this product — from an internal research project to large-scale deployment. He covers why they chose Rust, why they committed to open source, how code review is being restructured, and the deeper shifts happening in software engineering as maintenance costs approach zero.

Why Build Codex in Rust

Codex made a counterintuitive early decision: write the core agent in Rust. At the time, the models weren't great at Rust — they performed far better in Python or TypeScript. The vast majority of other vendors' coding harnesses were built on exactly those languages.

Thibault explained the engineering rationale. From the start, the team treated the "product interface" and the "agent core" as two distinct things. The agent core needed to be robust, safe, and built for efficiency and scale. With years of experience scaling "interesting prototypes" to "the largest data center scale," he understood the weight of early decisions: "Early decisions tend to become very important, as long as you don't sacrifice too much speed."

Rust's static type verification catches a large class of problems at compile time — a major advantage for an agent as well. More critically, Rust's boundaries create a natural architectural separation. If everything is written in the same codebase in the same language, "you get a bit sloppy, you entangle things that shouldn't be entangled, and that blocks future innovation."

He acknowledged that starting with TypeScript or Python and rewriting later could also work, but maintaining a clean separation between the agent and the product is an important principle. This reinforces a key insight: even in the agent era, where rewriting code is easier, having the right scaffolding and architectural baseline still saves enormous amounts of rework.

Rust is a systems programming language released by Mozilla in 2010, designed to achieve both memory safety and high performance without relying on a garbage collector. Through its "Ownership" and "Borrow Checker" mechanisms, Rust statically eliminates at compile time an entire class of runtime errors — null pointer dereferences, data races, memory leaks, and more. This means Rust programs rarely suffer from memory-related crashes or security vulnerabilities in production. For a coding agent that needs to reliably execute arbitrary code in production while managing large numbers of concurrent tasks, these compile-time guarantees are especially critical — a failed agent run inside a sandbox carries far higher costs than a typical application crash. Additionally, Rust has no runtime overhead and allows precise resource allocation, making it easier to optimize latency and throughput at data center scale. The tradeoff is a steep learning curve and slower initial development velocity, which is why most AI tooling teams default to Python or TypeScript.

The Benefits and Costs of Going Open Source

Codex's CLI, SDK, and App Server are all open source — a rarity among major labs, as some competitors have chosen to keep their harnesses closed. Thibault's reasoning was straightforward: if you're building a coding agent, you should point it at itself and let community contributors use it to improve it.

The deeper bet was this: if Codex succeeds, then open source itself and the role of code will change — so rather than standing apart, it's better to be part of the community. "If you don't see the problems firsthand, it's hard to solve them."

Looking back a year and a half later, the benefits are real. The repository is small and transparent, and new hires have often reviewed PRs before their first day — "onboarding is basically already done." You can just use Codex to read the repo and ask questions to get up to speed immediately. There have also been many high-quality community contributions and a genuine sense of team energy from being part of the community.

But the costs are equally real. The open source code is separated from the internal main codebase, sometimes requiring artificial boundaries and multi-repo workflows. Most painfully: when you're building an exciting feature in the open, someone might copy it and ship it before you do. "That's a bit sad, but it's part of the rules of the game." On top of that, the sheer volume of low-quality contributions creates extra "tax" that the team must continuously manage.

Notably, Codex isn't locked to OpenAI's own models — it can connect to third-party models. Thibault sees this as a natural choice: since it's already open source, anyone could easily fork it and add support for other models. Rather than forcing users to run a fork and losing that feedback, it's better to support it natively. This also forces the entire company to compete on merit at both the model layer and the harness layer, rather than through lock-in.

The Convergence of Cloud Execution and Local Development

Currently, Codex runs by default in a sandbox on the local machine, prompting users before any command that requires additional permissions. But this model is evolving — you can opt to run in a cloud-hosted VM (a kata container secure environment), with output streamed back locally. This frees up local CPU and enables greater scale.

Thibault looked back at the history of cloud dev boxes: they were hot in 2022–2023 but never truly took off outside large tech companies, because the upfront and maintenance costs were too high for individual developers or small teams to benefit from. Now that agents are capable enough, all that configuration and synchronization work can be handled automatically by the model.

The direction he envisions: the stronger the model, the more compute and resources it can leverage — far beyond what a local machine can provide — so running locally will eventually become a constraint. The team is exploring hybrid local-cloud execution, freeing developers from the need to always have their laptop open. Just as ChatGPT work already lets you dictate tasks from your phone over coffee, accessing calendars, email, and Slack to complete work automatically.

Kata Containers is a secure sandbox technology that combines lightweight virtual machines (VMs) with a container interface. It evolved from Intel Clear Containers and the hyper runV project and is now a CNCF project. Unlike traditional Docker containers, which share the host kernel, Kata Containers launches an independent micro-VM kernel for each workload, striking a balance between the deployment convenience of containers and the strong isolation of VMs. For the use case of executing arbitrary AI-generated code, kernel-level isolation effectively prevents malicious or accidental code from escaping to the host system — with a significantly smaller attack surface than ordinary containers isolated only via cgroups and namespaces. This explains why Codex uses kata containers as its security boundary for cloud-hosted execution: when an agent has network access, filesystem write permissions, and shell execution capabilities, the strength of runtime isolation directly determines the platform's security baseline.

The Harness Is Always One Step Ahead of the Model

On how the harness and model co-evolve, Thibault offered a sharp observation: the harness is, in a sense, always one step ahead of the model.

Models have certain capabilities, but you need to give them some "crutches" so they can complete tasks with sufficient reliability and in ways that match user expectations — that's the harness's role: providing guardrails, controllability, and the developer message that injects context at the start of each conversation.

Take "running tests" as an example: early models wouldn't run tests automatically, so you had to keep reminding them. Then a better model was trained, one that could better reflect on what the user actually wants — and suddenly you no longer needed to remind it. As models improve, the developer message gets shorter, and the harness gets thinner.

The team uses this to set priorities: faced with a requirement, they first ask whether it should be a harness change or a model change. If it's a model change, they estimate whether it'll be ready in one month, three months, or six — and sometimes they simply wait for the model to solve it on its own, without doing anything in the harness. The entire process is "all agents": they use agents to analyze massive amounts of user feedback, identify themes, and assist in prioritization decisions — across coding, finance, communications, marketing, and every domain where users use agents.

In the AI agent context, a "harness" refers to the execution framework built around a language model — including tool-calling interfaces, context injection logic, error retry strategies, output parsing rules, and more. It's not the model itself, but the scaffolding that drives the model to complete specific tasks. The developer message (system prompt) is the initial instruction the harness injects into the model, used to set roles, constrain behavior, and provide environmental context. Thibault's observation that "the harness is always one step ahead of the model" reveals an important pattern in product development: when model capability is insufficient, the harness compensates through explicit instructions; when the next generation of models internalizes those instructions as default behavior, the corresponding harness logic can be deleted. This means harness complexity is an inverse function of model capability — the stronger the model, the thinner the harness. For engineering teams, this requires always distinguishing between "what the model should learn" and "what the harness needs to catch," to avoid over-engineering that creates technical debt that's hard to remove later.

The Changing Role of Code Review

Inside the Codex team, the most common thing new hires hear is: "Have you asked Codex?" Codex is connected by default to Slack, all documentation, and the codebase — it knows the project state, who's working on what, and why a particular decision was made. The team deliberately works in public channels and maintains open documentation permissions so the agent can reason about the full context.

On code review, Thibault's perspective is striking: its role is changing. The team built a code review model early on that can catch logical and reasoning-level bugs — diving three or four dependency layers deep, identifying invariant violations caused by discrepancies between documentation and third-party implementations — the kind of issues that might take a human expert hours to catch. Those capabilities have now been merged into the main model, and in benchmarks, "code review is superhuman" — not just for correctness, but for security as well. Currently, all OpenAI PRs undergo mandatory automated security checks, and a security finding will block the merge.

He argues that code review has historically served three purposes: correctness, security, and a kind of "small ritual of information exchange" — getting everyone aligned and sparking discussion. The first two are being automated. What remains at the core is a discussion around intent: what exactly are you trying to do, and is this the right way to do it? And that discussion doesn't have to happen around a PR.

The more advanced model is the "box" abstraction: as long as there are strict guarantees around resource usage, data access, and security, the internals of a box can be anything — you don't need to care. What truly requires consensus is what the box does and which invariants it must satisfy. Once that's established, any internal changes to the box no longer require discussion, protecting your attention.

"Boxes and invariants" is the core idea behind modular design in software engineering, with rigorous definitions in formal methods and Design by Contract. An invariant is a condition a module must always satisfy throughout its lifecycle — for example, "queue length is always non-negative" or "user authentication tokens must be encrypted before being written to the database." A "box" is an abstraction unit that encapsulates internal implementation and interacts with the outside world only through a well-defined interface. When a box's interface and invariants are clearly defined and agreed upon by the team, any internal refactoring (including large-scale AI-generated rewrites) requires no line-by-line code review — you only need to verify that the invariants still hold. This idea becomes especially important in the age of AI-assisted development: models can quickly generate or rewrite large amounts of code, but without clear invariants as verification anchors, the faster the generation, the higher the risk of introducing hidden errors. Focusing human discussion on "what the box does" rather than "how each line is written" is the key strategy for maintaining system reliability at high iteration speed.

How Software Engineering Changes When Maintenance Gets Cheap

"Building is the fun part; maintenance is the painful part" — that's a lesson shared across companies from Google and Uber to early-stage startups. Thibault believes maintenance is undergoing a qualitative transformation.

Maintenance is fundamentally a "tax paid over time" — take upgrading a third-party dependency version number. As long as there are good changelogs and documentation, a model can reason through and sweep the entire codebase in a matter of hours. The kind of work that's "not fun but important to the business" and tends to get deprioritized. Timely application of security patches is especially critical, and this will become fully automated — most maintenance will become "nearly free."

Even more exciting is the dramatic drop in the cost of re-architecture. What once took years and significant expense — a full system rebuild prompted by new tradeoffs, new understanding of load, or new features — is now being greatly accelerated. But Thibault emphasizes that the old rules of software engineering still matter: good abstractions and the right "box and invariant" shape let you iterate rapidly within a box without affecting other services.

He specifically noted one shift: thinking about architectural design and long-term maintainability was once the domain of architects or senior engineers. Now all engineers need this awareness and need to plan for it upfront when building software. And GPT models are increasingly good at thinking about long-term maintenance — not just code cleanliness at the file level, but whether the architecture is correct and whether it leaves room for future feature expansion.

The lifecycle of software is being dramatically compressed. In the past, a successful project might have 50 to 100 engineers a year later — you had time to watch it grow, hire, write documentation. Now you might have 100 agents contributing simultaneously over a single weekend, and you're moving at extreme velocity.

On whether there's any sense of loss when models learn to do what you're good at, Thibault admits he occasionally still opens an editor to write code by hand and enjoys that flow state. But his core belief is: if you treat code as a tool for solving problems, then you can solve far more problems — and that only makes you a better engineer. OpenAI is nowhere near running out of problems, and there's still a long road ahead in mathematical breakthroughs, scientific discoveries, and serving humanity.

Advice for Engineers

On what it takes to join a team like Codex, Thibault offers two things: first, a deep curiosity about how things work, and the ability to quickly understand systems — being able to rapidly grok a system, dive into an unfamiliar codebase and make sense of it, ask "five whys," dig deeper and deeper and learn faster and faster. Second, staying in sync with the community you're serving — having clarity about their taste, needs, and expectations, and being able to clearly articulate intent.

"If you can't explain what you're trying to achieve, can't explain your intent, have no connection to the community, and have no taste — it's very hard to do great work." In an era where AI is accelerating everything dramatically, the fundamentals still matter more than ever.