Building Codex with Tibo Sottiaux

The Pragmatic Engineer 1h14 5 min #101
Building Codex with Tibo Sottiaux
Watch on YouTube

Summary

  • Tibo Sottiaux leads the Codex team at OpenAI; this episode covers his path from applied mathematics and supply-chain optimization through Google and DeepMind to building Codex, the open-source, Rust-based coding agent that now runs both locally and in ChatGPT, and how AI is reshaping software development practices at OpenAI.

Tibo’s path to OpenAI

  • Grew up in a tiny Belgian village; got into computers early as his only window to the world.
  • Studied applied mathematics, ran a startup optimizing pharmaceutical clinical-trial supply chains (Monte Carlo, stochastic multi-stage optimization), then joined Google in 2015.
  • At Google: first on a “make the web faster on mobile” project (cancelled after two years — taught him to always question impact and product-market fit), then Google Maps reviews, then DeepMind research infrastructure.
  • At DeepMind: part of a small group that built an internal chatbot a year before ChatGPT using early LLMs; it spread virally inside DeepMind but Google’s product-launch machinery made external release nearly impossible.
  • Joined OpenAI in 2024 because he wanted a mission-driven culture where research and product co-design, a tight feedback loop with users, and a small, autonomous team (ChatGPT had ~20 engineers at the time).

The early days of Codex

  • Started as an internal research-infrastructure effort: train models on OpenAI’s Python codebase to help researchers code faster.
  • Merged with the “ASWE” (Autonomous Software Engineer) effort; Greg Brockman pushed to make it a product for the world, not just OpenAI.
  • First launch: cloud Codex (high friction, no PMF), then Codex CLI; continuous push to let models do more of the work.

Why Codex was built in Rust

  • Deliberate separation between the agent core (Rust) and the product interface (TypeScript) to enforce clean boundaries and prevent intertwining.
  • Rust gives compile-time correctness, security, efficiency, and scales well; internal models were already decent at Rust.
  • Turned out Rust is also a good fit for agents because static verification catches errors early.
  • Could have succeeded in TypeScript/Python and rewritten later, but the Rust boundary forced architectural discipline from day one.

Why Codex is open source

  • A coding agent should be able to improve itself; open source enables a community of contributors using the agent to improve the agent.
  • Early stage: no one has all the answers; building in the open invites tinkering, exploration, and learning from the broader community.
  • Benefits: instant onboarding (new hires already know the repo), good external contributions, team energy from visible community engagement.
  • Downsides: artificial repo boundaries vs. internal monorepo, competitors copying features before release, flood of low-quality contributions requiring triage.

Codex plays nice with other models

  • Coupling the harness to OpenAI models would feel like lock-in; users would just fork and add 10 lines for another provider.
  • Optionality benefits users (try new models without changing setup) and OpenAI (gets feedback on what works elsewhere).
  • Enterprise customers demand model optionality; winning on merit (best model + best harness) attracts better talent than winning on lock-in.

How the harness works today

  • Default: runs sandboxed on the user’s local machine; asks permission for commands needing outside-sandbox privileges.
  • Optional: “cloud mode” runs the same harness in a managed Kata-container VM (same as ChatGPT’s code interpreter), streaming only I/O to the laptop.
  • Future: seamless hybrid — partial local, partial cloud — because models will leverage more compute than laptops can provide.
  • Cloud dev environments never took off due to setup/maintenance cost; agents now make that setup nearly free (agent configures the remote box).

Harness and model improvements

  • Harness is “a step ahead of the model”: provides guardrails, developer messages, crutches so the model behaves reliably today.
  • Over time, model training absorbs those behaviors (e.g., running tests automatically), so the harness and developer messages shrink.
  • Co-design process: research and engineering jointly decide whether a gap is a harness fix (fast) or a model fix (months); agents analyze feedback across all coding domains to prioritize.
  • North star: a delightful, simple, personal AGI that knows you, has access to resources, can take risky actions with verification, controllable via natural language/voice.

The SDLC behind Codex

  • Onboarding: “Have you asked Codex?” — Codex is plugged into Slack, docs, code; new hires use it to understand projects, decisions, people.
  • Work in public channels, broad doc permissions so agents can reason across context.
  • Principles over process: care about user, product coherence, model trajectory; avoid building 10k-line crutches for model flaws.
  • Shipping: PRs can go to millions of users same/next day; ownership and care replace heavy gates; automation handles reviews, deploys, regression detection.

Code reviews at Codex

  • Built superhuman code-review models (logic, security, deep dependency reasoning); now baked into mainline models.
  • Security reviews mandatory and automated: PRs blocked on critical vulnerabilities.
  • Human review shifting from correctness/security (automated) to intent discussion: “What are you trying to do? Is that the right thing?”
  • Future: agree on the “box” (invariants, resource limits, data access); internals of the box can change freely without discussion.

Maintenance and architecture

  • Maintenance = tax to keep things running; large parts becoming automated (dependency upgrades, security patches via changelog reasoning).
  • Re-architecture cost plummeting: what took years now happens in weekends; good abstractions (“boxes with invariants”) still matter to enable fast iteration.
  • Models increasingly capable of long-term architectural thinking (modularity, future extensibility).
  • Software lifecycle compresses: 100 agents can contribute in a weekend; engineers must design for that velocity from the start.

How AI tools expand what engineers can do

  • Not about losing craft; about staying in flow and solving more ambitious problems.
  • Benchmarking, trade-off analysis, prototyping now take seconds; engineers become better by focusing on outcomes.
  • OpenAI uses this to run inference more efficiently, deploy more effective compute.
  • No one at OpenAI has said “this isn’t fun” — the problem space (scientific breakthroughs, human-centric AGI) is far from exhausted.
  • Personal workflow: dictates tasks to ChatGPT/Codex on mobile between meetings; gets reports, slide decks, code explorations in minutes; builds prototypes on weekends to “flush ideas out of the system.”

The Merge: ChatGPT + Codex

  • Major engineering challenge: merging fully local Codex stack with ChatGPT’s managed cloud stack, efficiently enough for the $20 Plus plan.
  • Result: Codex harness runs in a powerful cloud VM (internet, Blender, model training) accessible via ChatGPT “Work” toggle.
  • Unified system goal: same capabilities whether in Codex or ChatGPT; temporary toggle state.
  • Codex itself acted as project journalist — ingested all Slack, docs, debates, decisions — creating a full recounting of the merge process.

How Tibo uses Codex and ChatGPT

  • Calendar is “Tetris” but cheerful because agents multiply throughput.
  • Mobile-first: dictates tasks/questions to ChatGPT Work (custom skills/instructions for report style); gets answers in 30 min.
  • Uses it for everything: public sentiment, production logs, deprecation lists, team status, code explorations, weekend prototypes.
  • Long-running tasks: /goal command (harness crutch) kept model on track for days; new models need it less — can just say “work for a week.”

Advice for engineers who want to work in AI

  • Deep curiosity + ability to grok systems quickly; agents accelerate this but the drive to ask “why” five levels down is core.
  • Be in tune with the community you’re building for: crisp taste, clear intent, ability to explain what you’re achieving and for whom.
  • Fundamentals still matter: clarity of thought, architectural judgment, understanding invariants — these become more valuable, not less, as implementation gets cheaper.
Back to The Pragmatic Engineer