Summary of Building Codex with Tibo Sottiaux

Overview of Building Codex with Tibo Sottiaux

This episode follows Thibaut “Tibo” Sottiaux’s path from applied mathematics and startup work to Google, DeepMind, and OpenAI, and then into leading Codex. The conversation centers on how Codex was built, why the team chose Rust and open source, how the harness and model work together, what changed in the merge of Codex into ChatGPT, and how AI is reshaping software engineering practices like code review, maintenance, and architecture.

Background: How Tibo Got Into Tech

Early interest in computers

• Growing up in a small village after his parents moved out of Brussels, Tibo turned to computers and the early internet as his main outlet.
• That early exposure became the foundation for his interest in technology.

Mathematics and optimization

• He studied applied mathematics at university and was drawn to real-world problems that could be improved through mathematical reasoning.
• Before the “AI era,” he worked on optimization-heavy problems such as:
  • pharmaceutical supply chains for clinical trials
  • steel industry logistics
  • electrical grid optimization in Europe
• His core motivation was using math to make systems more efficient and useful.

Career path

• Startup world in Belgium
• Google London
• DeepMind
• OpenAI

From Google and DeepMind to OpenAI

Lessons from Google

• He first worked on a project to make the web faster on mobile.
• The project was technically exciting but eventually canceled because it lacked product-market fit and a real feedback loop.
• Key lesson: technical quality alone is not enough; the product has to solve a real problem for real users.

Why DeepMind was attractive

• At DeepMind, he worked heavily on research infrastructure and tooling.
• He was drawn to the challenge of building systems that help other people work faster and better.
• This “tooling for others” mindset carried through into Codex.

Why he joined OpenAI

• He wanted to work on a mission he genuinely believed in.
• OpenAI stood out because research and product were tightly connected.
• He was especially impressed by how small the Codex/ChatGPT teams were relative to the scale of the products.

How Codex Started

Internal research roots

• Codex began as an internal effort to help OpenAI researchers and engineers work faster.
• The team trained models on OpenAI’s Python codebase and built early agents around them.
• The goal was to improve:
  • coding speed
  • code style
  • architectural taste
  • infrastructure productivity

From internal tool to product

• The internal effort merged with the broader ASWE initiative.
• The team eventually launched the early Codex cloud product and then the CLI.
• The product evolved from a research helper into a broader developer tool.

Why Codex Was Built in Rust

The decision

• Codex’s core agent was built in Rust rather than Python or TypeScript.
• This was unusual because Rust was not the dominant choice for AI harnesses.

Why Rust made sense

• The team wanted the core agent to be:
  • robust
  • secure
  • efficient
  • scalable
• Rust’s compile-time checks and strong correctness guarantees fit that goal.
• The internal models were already reasonably good at Rust, which reduced friction.

Architectural principle

• Tibo emphasized a separation between:
  • the product interface
  • the agent/core system
• That separation helps prevent coupling and makes future changes easier.

Why Codex Was Open Source

Strategic reasons

• Codex is a coding agent, so making it open source felt natural.
• The team wanted:
  • community contributions
  • better feedback loops
  • direct participation in the open-source ecosystem
• They also believed code itself and the role of coding tools would change, so being part of that change mattered.

Benefits of open source

• Easier onboarding: new team members can inspect the repo and PRs before joining.
• Strong community contribution potential.
• Public building creates momentum and energy.

Downsides

• Competitors can copy features before release.
• More noise and low-quality contributions to manage.
• Extra overhead from maintaining separate repos and boundaries.

Why Codex Supports Other Models

Design philosophy

• Tibo argued that a good coding harness should not be tightly coupled to a single model provider.
• Supporting multiple models gives users optionality and avoids unnecessary forks.

Product advantage

• Users can switch models without changing their whole setup.
• OpenAI benefits from seeing how Codex behaves with different models.
• The team wants to win on:
  • model quality
  • harness quality
  • product experience
  • not lock-in

How Codex Works Today

Local-first and sandboxed by default

• Codex typically runs sandboxed on the user’s machine.
• Anything that needs extra permissions prompts the user.
• The local setup has been the default for over a year.

Cloud execution

• Users can also run Codex in the cloud using a managed VM.
• This is closer to the ChatGPT Work environment.
• Cloud mode is more scalable and less dependent on the user’s laptop.

Future direction

• The long-term direction is a mix of:
  • local execution
  • cloud execution
  • eventually more seamless orchestration across both

The Relationship Between Harness and Model

Harness leads, model follows

• Tibo described the harness as usually being “a step ahead” of the model.
• The harness adds:
  • guardrails
  • permissions
  • instructions
  • steering behavior
  • reliability improvements

How improvements happen

• Sometimes missing behavior is fixed in the harness.
• Sometimes it’s better to solve it in the model through training.
• Over time, both the harness and the developer instructions shrink as models get better.

How the Team Sets Goals

Co-design between engineering and research

• The Codex team works closely with research to decide whether a problem is:
  • a harness issue
  • a model issue
• They prioritize based on:
  • how soon the model can learn the behavior
  • how important the product gap is
  • how much reliability is needed

Using agents to improve agents

• Codex and similar tools are used internally to analyze feedback and find patterns.
• The team looks across many domains, not just coding:
  • finance
  • comps
  • marketing
  • other workflow-heavy areas

How OpenAI Work Has Changed

New onboarding style

• New hires are often told: “Have you asked Codex?”
• Codex has access to:
  • Slack
  • docs
  • code
  • internal context
• That means a lot of onboarding and orientation can happen through the agent itself.

Process has become more automated

• Code review, deploys, and regression checks are increasingly automated.
• Engineers spend more time on:
  • intent
  • architecture
  • product usefulness
  • user value

Principles that matter

• Care about the user.
• Keep the product coherent.
• Avoid building giant “crutches” to work around model flaws if the model can improve instead.

Code Review Is Changing

What the old system did well

• Human code review provided:
  • correctness checking
  • knowledge sharing
  • architecture discussion
  • bus-factor reduction

What AI now handles better

• Codex and related models can already do very strong review for:
  • logic errors
  • dependency issues
  • security vulnerabilities
• OpenAI now blocks some pull requests automatically if security issues are flagged.

What humans still do

• Humans are increasingly focused on the discussion around intent:
  • What are we trying to do?
  • Is this the right thing to build?
• The actual mechanical review is moving toward automation.

Maintenance and Re-architecture Are Getting Cheaper

Maintenance as a “tax”

• Upgrading dependencies, applying patches, and keeping systems healthy has traditionally been expensive and annoying.

What changes with agents

• Agents can now take on much of this work:
  • dependency upgrades
  • refactors
  • keeping codebases current
• The cost of mistakes and architecture changes is falling dramatically.

Why architecture matters even more now

• Good abstractions and clean boundaries help agents make changes safely.
• Designing the right “box” with clear invariants matters more because more work happens faster.

The Merge of Codex Into ChatGPT

What made it hard

• Codex started as a local coding agent.
• ChatGPT is a fully managed cloud product.
• Merging them meant reconciling two very different stacks and operating models.

What the merge achieved

• Codex became available inside ChatGPT Work.
• The goal is a unified product where users can access the same intelligence in whatever form factor they prefer.

Role of Codex in the merge

• Codex helped with:
  • infrastructure work
  • documentation
  • tracking debates and decisions
  • identifying differences between systems
• Tibo described Codex as acting almost like a journalist for the project.

How Tibo Uses Codex Personally

Daily workflow

• He uses Codex and ChatGPT Work as a personal agent for:
  • notes
  • questions
  • reports
  • slide decks
  • code explorations
• He relies heavily on:
  • dictation
  • mobile workflows
  • Slack, Notion, Google Docs context

Practical use cases

• Checking public sentiment on features
• Looking at production usage
• Finding deprecations
• Understanding what other teams are doing
• Running exploratory tasks overnight

Advice for Engineers Who Want to Work on Systems Like This

What matters most

• Deep curiosity about how systems work
• Ability to understand new codebases and systems quickly
• Asking good “why” questions repeatedly

Be tuned to the user/community

• Strong engineers need clarity about:
  • who they are building for
  • what the user needs
  • what the product is supposed to accomplish
• Taste and intent matter as much as raw technical skill.

Fundamentals still matter

• Despite rapid AI progress, the basics remain important:
  • system design
  • abstraction
  • clarity
  • user empathy
  • speed of learning

Key Takeaways

• Codex began as an internal tool and evolved into a major product through close collaboration between research and engineering.
• The team chose Rust, open source, and model-agnostic design for long-term scalability and correctness.
• AI is changing software engineering from both ends:
  • code generation
  • code review
  • maintenance
  • architecture
• The biggest shift is not just speed, but the collapse of many previously expensive engineering tasks into fast, agent-assisted workflows.
• Even in an AI-heavy future, strong engineering judgment, user understanding, and system thinking remain essential.