Research tooling needed a connection to real users
Source 07:46In this Pragmatic Engineer interview, Tibo Sottiaux describes building Codex through research tools, product decisions and changing engineering practices. The recurring question is how to make other people more effective while keeping a fast-changing system coherent.
He corrects an early detail in the conversation: his first Google project was about speeding up the mobile web, before he worked on Maps. The small team tackled difficult technical problems, but the project was cancelled after failing to reach the required scale. He took away a need to question user feedback and impact, even when the technical work was enjoyable.
At DeepMind he worked on research infrastructure and tooling. An internal chat interface for early language models spread among researchers, but turning it into an external product meant dealing with a different organizational and production environment. He later sought a place where research and product could be designed together.
Internal research agents became a product effort
Source 15:48At OpenAI, Sottiaux initially built research infrastructure. Reasoning models made the team ask how those models could accelerate the research work itself. They trained internal models to work effectively in the company's Python codebase and built small agents around them.
That work combined with an autonomous software engineering effort. The aim expanded from helping internal researchers to offering a product to outside users. He describes the initial cloud Codex experience as too high-friction to have strong product fit, while the team also launched and continued developing the CLI.
The path was therefore not simply a model followed by a finished interface. Internal usage, training and product experiments fed into each other.
Rust helped establish a boundary around the agent core
Source 18:53The team treated the product interface and the agent as different things. The agent core needed robustness, security, efficiency and the ability to scale. Rust offered compile-time checks, and the team had strong Rust developers; Sottiaux says their internal models were also capable enough to work in it.
He does not argue that TypeScript or Python would have made success impossible. Those could have worked and later been rewritten. What mattered was having a clean separation so the core could exist independently of a particular product.
Using a different language also reinforced that boundary. If everything lives together, he says, it becomes easier to intertwine pieces that should remain separate and harder to innovate later. The language decision supported an architectural choice, rather than serving as a universal rule for all agent projects.
Open source brings feedback and a maintenance bill
Source 21:39A coding agent with an open repository can be pointed at itself. The team wanted a community that could inspect, improve and experiment with it, while learning from other projects instead of claiming to have all the answers.
Sottiaux describes practical benefits: new hires can already have read the repository, and contributors bring useful changes. Being visibly involved in the community also gives the team energy.
The costs are concrete. Work crosses repository boundaries that would not otherwise exist. Competitors can copy a feature while it is still being built and release first. The project also receives a large volume of low-quality contributions that someone must handle.
Support for other model providers follows a similar logic in his account. Restricting an open harness would encourage small forks just to add that support. Optionality lets users try a model without rebuilding their entire setup and gives the team feedback about what works across models.
Local tools and cloud resources solve different constraints
Source 32:28At the time of the interview, Sottiaux describes sandboxed local execution as the default, with additional permissions requested when needed. He also discusses managed cloud execution, where the agent's work happens in a remote environment and the local device sends input and receives output.
The interviewer points out why local execution remains useful: a developer already has databases, servers and tools configured. Sottiaux's response is that, as agents become capable of configuring and maintaining a cloud development environment, those setup costs can fall.
He presents more seamless combinations of local and cloud resources as a direction of travel. The argument is that stronger agents may need more compute than a laptop provides, not that every local workflow already transfers to the cloud without work.
A harness can be ahead of the model and later become smaller
Source 37:18Sottiaux describes the harness as supplying guardrails, efficiency, control and instructions that help a model behave reliably. A reminder to run tests is an example of a temporary support: a later model may infer that expectation without being told.
This is why training and harness engineering are co-designed. When the team sees a weakness or wants a new capability, it asks whether the fix should be in the model or the runtime. Timing matters: a change expected in training soon may not justify a substantial workaround in the harness.
The goal is not to accumulate instructions forever. As model behavior improves, some instructions and scaffolding can shrink. The team still needs ways to express capabilities and control execution, but it tries to avoid large structures built only around a temporary model flaw.
Explanatory illustration of the model–harness decision described in the interview. It is not an official Codex architecture diagram.
Shared organizational context helps engineers orient themselves
Source 41:57New teammates often hear, “Have you asked Codex?” Sottiaux says the internal system can access code, documents and conversations, making it useful for understanding a project's state or why a decision was made.
That depends partly on how the team works. Public channels and broadly accessible documents make information available to colleagues and their agents. It is a workflow around the tool, rather than a capability generated from no organizational context.
He emphasizes ownership, user value and product coherence. Proposed changes need evidence that they are worth adding and maintaining. Automation handles much of the review, deployment and regression process in his description, while people focus on the purpose of the change.
Review shifts toward intent and explicit contracts
Source 47:52Sottiaux describes models that investigate several dependency levels to find logic errors or broken assumptions, including cases where implementation differs from documentation. He also reports automatic security checks that can block internal pull requests.
Those are his account of the team's tools and evaluations. The human discussion he sees remaining concerns intent: what is the change trying to achieve, and is it the right thing to attempt?
His example is a box with an agreed contract and strict invariants around resource use, data access and security. If the guarantees remain satisfied, changes inside the box can demand less repeated discussion. Reaching a clear agreement about those guarantees is itself valuable engineering work.
Cheaper maintenance does not remove the need for good abstractions
Source 52:36Maintenance remains necessary. Sottiaux expects agents to automate more of it, from dependency upgrades to larger architectural changes, especially when documentation and changelogs give them a sound basis for reasoning.
He also returns to the boundary argument: a well-shaped abstraction lets a component change quickly without disturbing the surrounding services. Lower rewriting cost makes iteration faster, but the structure that isolates changes still helps.
The pace of growth changes too. A project can gain many agent contributors much faster than it would previously have hired and onboarded the equivalent number of people. Documentation, modularity and clear contracts face pressure earlier in that lifecycle.
Bringing local capabilities into a managed cloud product
Source 63:26The conversation's “merge” refers to bringing Codex into ChatGPT. Sottiaux describes the challenge as joining different stacks: a local agent and a managed cloud product built for a much broader audience.
That required infrastructure and efficiency work, as well as reconciling plugins, libraries and product differences. He says Codex also documented the team's debates and decisions during the project.
He describes a more unified experience as an ongoing direction. The intended outcome is access to the same intelligence through the interface a person wants to use, rather than maintaining separate capabilities indefinitely.
Curiosity and clear intent remain part of the job
Source 70:41Sottiaux uses mobile dictation for questions, tailored reports and explorations between meetings. He also builds prototypes to put an idea in front of colleagues; a prototype is something to criticize and learn from, not an automatic decision to ship it.
His advice is to understand systems quickly, ask good questions and stay connected to the people whose problems the work serves. The ability to explain an intention and recognize what users need remains central to doing useful work.
Adapted from The Pragmatic Engineer interview “Building Codex with Tibo Sottiaux.” Product behavior and internal practices are presented as descriptions from that interview, not current configuration instructions. Sponsor segments are omitted.