这期播客是《The Pragmatic Engineer》对Thibault（Tibo）的采访，他是OpenAI Codex团队的负责人…

这期播客是《The Pragmatic Engineer》对Thibault（Tibo）的采访，他是OpenAI Codex团队的负责人，讨论了Codex的诞生、技术决策、工程文化以及软件开发实践的演变。 https://x.com/GergelyOrosz/status/2097798203613516142/video/1… 以下是关键要点： 个人经历与加入OpenAI Thibault是比利时人，拥有应用数学背景。他最初在一家初创公司优化制药供应链，然后在Google参与一个加速移动网页的项目（后来被取消，这让他学会了始终审视项目的真实影响）。之后，他在Google Maps处理评论，然后转到DeepMind。在DeepMind期间，他参与开发了一个内部聊天机器人——本质上是ChatGPT，但早了一年。它在内部迅速传播，每个人都分享对话，但DeepMind缺乏将其作为产品发布的机制，所以它从未推出。 后来，他得知ChatGPT仅由约20人维护，这让他震惊并极具吸引力——个人影响力巨大的潜力。所以他加入了OpenAI，立即投入推理模型的冲刺。大约一个月后，o1预览版发布了。 为什么用Rust构建Codex 这是一个反直觉的决定——当时模型对Rust的支持不佳，行业中的其他AI编码工具大多用TypeScript或Python构建。但团队从第一性原理出发，认为代理的核心需要健壮、安全和高效，Rust的编译时验证功能天然适合代理场景。使用不同语言也强制了产品界面和代理核心之间的清晰边界，避免了代码耦合。实践中，Rust“迅速证明非常适合代理开发。” 开源与模型无关策略 Codex CLI和SDK都是开源的，并支持非OpenAI模型——这在大型AI实验室中是独一无二的。理由非常务实：如果你不开源，别人可以用十行代码分支它来支持其他模型，为什么不自己构建支持呢？开源的好处包括新员工在加入前就熟悉代码库、社区贡献，以及迫使你通过模型和产品体验而非锁定来赢得用户。 显然的缺点是：竞争对手会在你公开开发的功能发布前就复制它们，这“确实有点痛”；还有大量低质量的PR需要处理。 工程文化与代码审查的演变 新员工入职后最常听到的话是“你问过Codex了吗？”——因为Codex集成了Slack、文档和OpenAI内部的所有代码，几乎能回答任何问题。 代码审查正在经历根本性转变。OpenAI开发了一个专门的代码审查模型，在逻辑推理和安全漏洞检测方面达到“超人水平”——它可以深入依赖三到四层，发现由文档错误引起的不变性违规。安全审查现在是强制自动化的，发现问题会阻止合并。一个PR可以提交并在同一天部署到ChatGPT的数十亿用户。 代码审查的角色正在从“正确性检查”转向“意图讨论”——你真正想实现什么？值得做吗？这些讨论甚至不需要围绕代码本身。 维护成本与重构的本质变化 维护一直是软件工程的“税”，但现在许多部分（依赖升级、安全补丁）可以完全自动化。更重要的是，重新架构的成本暴跌——过去需要数月甚至数年的事情现在可以更快发生。但良好的架构设计更加重要：设计坚实的“盒子”和不变性，你可以在盒子内调整而不影响其他部分。 工具架与模型的关系 一个有趣的见解：工具架（工具/脚手架）总是“领先于模型”。Codex团队的工作本质上是为模型构建拐杖——提醒它运行测试、保持目标等。然后，下一代模型在训练中内化这些能力，拐杖可以移除，开发者消息变得更短。最新的模型不再需要/goal命令来维持长期任务的焦点——“你只需告诉模型工作一周，它就会实际做到。” Codex与ChatGPT的合并 这是一个重大的工程挑战：Codex最初完全在本地运行，而ChatGPT是托管的云服务；统一两个完全不同的技术栈。目标是使云版本匹配本地版本的能力，同时足够高效以适应每月20美元的Plus计划。ChatGPT Work模式本质上是在云虚拟机中运行完整的Codex工具架，硬件强大到足以让用户在其中训练模型或安装Blender进行3D建模。 有趣的是，Codex在整个合并过程中也扮演了“记者”的角色，访问所有Slack讨论和文档，记录团队的辩论和决定。 Thibault的个人使用与建议 他在手机上大量使用ChatGPT Work，通过语音下达任务，使用自定义技能和指令生成他能高效消化的报告和幻灯片。任何问题——公众情绪、生产日志、功能使用分析、团队动态——都能在30分钟内得到答案。周末，他使用Codex进行代码探索和原型设计，“在一天内将头脑中的想法变成可展示的东西。” 他对工程师的建议：保持深度好奇心，训练自己快速掌握系统（不断问“五个为什么”），并保持与所服务用户群的同步——如果你无法清晰表达意图，就很难做好工作。