▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=sLSTM9znQNs
• Original title :: Building Codex with Tibo Sottiaux

Tibo Sottiaux, who leads OpenAI's Core Products & Platform org and was there when Codex started, walks Gergely Orosz through the decisions behind the product: why the agent core is Rust, why the CLI is open source and model-agnostic, how the harness and model co-evolve, what code review and maintenance look like inside a team where agents write most of the code, and what merging Codex into ChatGPT actually involved.

Getting here

Belgium, a village of 200 people, a computer at age eight. Applied mathematics at university, an early graduation, and a startup optimising pharmaceutical supply chains for clinical trials — Monte Carlo simulation and stochastic multi-stage optimisation, later applied to steel and to European electrical grids.

Then Google London in 2015, starting on a project to make mobile web faster inside the ads organisation. It was cancelled after two years, and he treats that as the formative lesson: no product-market fit, no real users, no feedback loop, and a product manager whose "it's going well" he should not have trusted. Everyone was surprised when the VP flew in. After a year on Maps reviews he moved to DeepMind, where he spent most of a decade on research infrastructure and tooling — a theme he says has defined how he works: build things that make other people faster.

At DeepMind he was on the team that built an internal chat product on top of a large language model roughly a year before ChatGPT. The models were barely coherent, but the thing spread through the company like wildfire and stopped feeling like a research tool. There was appetite to launch it externally; DeepMind was not set up for that, and Google's blessed production stack, however well optimised, was a hard place to genuinely innovate.

He left because he wanted a mission he believed in and a place where research and product co-design rather than hand off. What clinched it was learning ChatGPT was run by about 20 people. He joined pre-reasoning, sprinted, and a month later the company shipped o1-preview.

From research tooling to Codex

The precursor to Codex was internal: models trained to be proficient on OpenAI's Python codebase with good taste in architecture and style, plus small agents, so researchers could build infrastructure faster. Greg Brockman pushed for it to benefit the world rather than just OpenAI, at which point the effort merged with the internal "A-SWE" (autonomous software engineer) project. That produced the first cloud Codex, which lacked product-market fit because it was too high-friction, and the Codex CLI.

Why Rust

The counterintuitive call: the agent core was written in Rust when the models were off-distribution for it, while every other harness went with TypeScript or Python.

The reasoning was that the product interface and the agent are different things, and the agent core needed to be robust, secure, and engineered for scale from the start. Their internal models weren't bad at Rust, compile-time verification helps agents, and it became clear Rust would suit agents quickly if they invested. He concedes TypeScript would also have worked and they'd have rewritten it later — but the real value was the boundary. Same codebase, same language, and you get sloppy: things intertwine more than they should and that blocks later innovation. The Rust boundary enforced the separation.

Why open source, and why it works with other models

They built a coding agent, so of course they pointed it at itself and wanted a contributor community doing the same. It also seemed clear that open source itself and the role of code were about to change, and being outside that community meant not witnessing the problems firsthand. Nobody had the answers about what a good harness looks like, so publishing theirs made the playing field level and encouraged tinkering.

Benefits after a year and a half: new hires have already read the repo and reviewed PRs, so onboarding is essentially done on day one; plenty of good contributions; and the team gets energy from actually paying a cost for the community rather than just claiming to care. Costs: the repo sits apart from the rest of their code, forcing artificial boundaries and cross-repo work; competitors copy features before release, which he admits stings even though it is the contract you sign with a permissive licence; and a tsunami of low-quality contributions to triage.

On supporting non-OpenAI models: coupling an excellent coding harness to your own model "didn't feel right". Anyone could fork it and add ten lines for another provider, and then you have an ecosystem of forks for no reason. Optionality also means users can try a new model without changing their setup, and OpenAI gets the feedback either way. Orosz's read — it forces the company to compete on the model layer and the harness layer independently — draws agreement: Tibo wants to win on best models, most efficient models, best product, not on lock-in, and thinks lock-in wouldn't attract the best people to work on the product either.

Local, sandboxed, and increasingly cloud

By default everything runs on your local machine inside a sandbox; anything needing permissions outside it prompts you. Cloud execution runs the same managed VM you get through ChatGPT work, in a Kata container, with only input and streamed output crossing to your laptop.

The direction is toward a mix, because as models get more capable they can use far more compute than a laptop has. On the objection that local wins because your Postgres, MCP servers and tools are already there: cloud dev boxes never took off outside big tech because of upfront and maintenance cost, but if the agent can do the setup and keep it in sync for free, that cost disappears. He expects a resurgence of fully cloud-orchestrated machines — he already starts his day dictating tasks into ChatGPT work next to the coffee, with access to calendar, email and Slack.

The harness is always a step ahead of the model

His framing of how versions improve: the harness gives the current model crutches — guard rails, efficiency, steerability, and the developer message injected at the start of each turn. Early on you had to remind Codex to run tests; then a model was trained to reflect better on what you actually want, and the reminder became unnecessary. Over time both the developer message and the harness shrink.

Planning therefore means asking, for each gap, whether it is a harness change or a model change, and if a model change, whether it lands in one month or six — sometimes the answer is to build nothing and wait. Feedback gets analysed by agents across coding, finance, comms, marketing and other domains to produce themes and priorities.

Orosz's own reaction in the outro: as a dev, building crutches that the next model makes obsolete sounds a little demotivating — though he suspects the durable part is the tooling models use (protocols, skills, plugins), not just the crutches.

"Have you asked Codex?"

That is the answer new joiners hear most. Codex at OpenAI is plugged into Slack, documents and all the code, and new starters are still surprised they can ask it anything — the state of a project, who is working on what, why a decision was made. The team deliberately works in public channels and opens documents with broad permissions so agents can reason over the information.

Shipping is surprisingly uniform: a PR can go out the same or next day, to Codex's 20M+ users or to ChatGPT's billion. What's asked for is evidence the change will be well received, is worth adding, and is worth maintaining — and the maintenance side of that calculus has changed a lot. Review, deploys and regression-catching are largely automated. The principle he cites: if you're building a 10,000-line crutch around a model flaw, you're probably doing the wrong thing. The north star is a delightful, simple personal AGI — one you control through natural language, that knows your schedule and goals, can take risky actions on your behalf and push you a notification to verify.

Code review is changing shape

One of his early Codex projects was a code review model built with research, aimed at catching logic and reasoning errors that would take a human hours — the kind that require going three or four levels into dependencies to find that the documentation was wrong and your invariants don't hold. Those capabilities are now in the mainline models, which benchmark as superhuman at code review, and the same applies to security: security flags now block merges across all OpenAI pull requests, automatically.

What's left is the social half. Review was always partly a ritual for information exchange and for having a discussion that ideally happened earlier. He argues that discussion is really about intent — what are you trying to do, and is it the right thing to attempt — and it doesn't have to happen around a diff. The shape he expects: agree on the box and its contract, with strict guarantees on resource utilisation, data access and security; what happens inside the box then barely matters, and changing it needs no discussion. Orosz adds the honest counterpoint that reviews were often a pain — blocking, context-switching — so the upside is attention no longer spent on things that don't need it.

Maintenance as an automatable tax

Maintenance is a tax you pay to keep things running, and most of it is about to be automated: dependency upgrades you would previously have punted on, despite mattering for security, can be blasted through the codebase in a couple of hours given a decent changelog.

The bigger shift is re-architecture. A rewrite to accommodate new trade-offs or a new understanding of the workload used to cost years; now it is dramatically accelerated. Which makes the old rules matter more, not less: good abstractions and the right boundaries are what let you change things inside the box quickly without touching everything else. Design for fast iteration. Orosz connects this to Peter Steinberger, who doesn't read the code but holds the architecture in his head and re-architects constantly so a hundred contributors don't step on each other. The models themselves are getting good at this kind of thinking — not just "is this file clean" but "is this architecture right for future extension".

The consequence is compressed lifecycles: what used to be a year of gradually adding engineers, with time to see the growth coming and write documentation, can now be a hundred agents contributing over a weekend.

Does it sting?

Asked whether losing skills he was good at to the model bothers him, Tibo grants a craft aspect — he still opens an editor sometimes, and has fond memories of late nights in Vim with a Coke Zero. But the glamorous version omits the three hours into a refactor that turns out to be a dead end. If code is a tool for solving problems, being able to solve far more of them should make you a better engineer: benchmarking something you were unsure about is now 30 seconds of launching a background job and getting real numbers to make the trade-off with. He hasn't met anyone at OpenAI who finds this unfun, and they are not running out of problems.

On long-running work: /goal was a crutch to keep the model on a single objective for days or weeks, and with the new generation of models it is no longer needed — you can just tell the model to go work for a week.

The merge

Bringing Codex into ChatGPT meant joining two completely different stacks: ChatGPT fully managed, cloud-based, built for scale and efficiency; Codex fully local. The task was reproducing the local agent's capabilities in the cloud, efficiently enough to include in the Plus plan — which means running the full Codex harness alongside a genuinely powerful cloud computer with internet access. People have discovered how permissive it is: you can get it to install Blender and do 3D modelling, or even train another model in there.

The engineering also involved unifying plugin architectures and libraries so that nothing is possible in one surface and impossible in the other. The "work toggle" is explicitly a temporary state on the way to full unification.

A detail both of them enjoy: Codex acted as journalist for the whole project, present in the Slack conversations and documents, producing a full recounting of the debates — including what to name things and what to merge into what. Orosz notes the slight big-brother feel of an AI always watching, and says he hasn't decided how he feels about it, while suspecting it becomes the new normal.

Advice

Two things. A deep curiosity about how things work, plus the trained ability to grok a system or an unfamiliar codebase quickly — helped by agents, but grounded in asking good questions and digging. And being in tune with the community you're solving for: clarity of thought about intent and taste. If you can't explain what you're trying to achieve, great work is much harder.