Tibo Sottiaux 谈 Codex：从研究工具到软件工程智能体

简要描述Brief Description

Tibo Sottiaux 讲述了自己从应用数学和初创公司工作经历一路进入 Google、DeepMind 和 OpenAI 的历程，随后解释了 Codex 如何构建、发布并在组织内部使用。对话探讨了 Rust、产品集成、工程工作流、代码审查、维护，以及 AI 如何改变软件构建的成本和实践。Tibo Sottiaux discusses his path from applied mathematics and startup work to Google, DeepMind, and OpenAI, then explains how Codex was built, released, and used inside the organization. The conversation examines Rust, product integration, engineering workflows, code review, maintenance, and how AI changes the cost and practice of building software.

目录Table of Contents

• 从应用数学到 Google
  From Applied Mathematics to Google
• 从 Google 到 DeepMind
  From Google to DeepMind
• 加入 OpenAI 与 Codex 的起源
  Joining OpenAI and the Origins of Codex
• 使用 Rust 构建 Codex
  Building Codex in Rust
• Codex 团队的工作方式
  How the Codex Team Works
• 发布、 安全与交付实践
  Shipping, Safety, and Release Practices
• 代码审查与工程工作流
  Code Review and Engineering Workflows
• 维护与重建软件
  Maintenance and Rebuilding Software
• ChatGPT 中的 Codex 与产品集成
  Codex in ChatGPT and Product Integration
• 领导力与软件开发的未来
  Leadership and the Future of Software Development

从应用数学到 GoogleFrom Applied Mathematics to Google

Tibo，欢迎来到播客。很高兴你能来。谢谢你的邀请。Tibo, welcome to the podcast. So good to have you here. Thank you for having me.

很高兴再次见到你。很高兴能这样做。上次我们是当面进行的。It's so good to see you again. It's good to do this. Last time we did it in person.

现在，我们正在录制视频。首先，我想问问你，你是怎么进入科技行业的？你是什么时候第一次意识到自己想从事计算机相关工作的？Now, now we're doing our video. First, I wanted to ask you, how did you get into tech? When did you first know that you want to work with computers?

这是个好问题。那已经是很久很久以前的事了。我的父母当时决定搬离我出生的布鲁塞尔，觉得买一栋小房子并把它翻修一番挺不错的。不过，那房子位于一个村子的中心地带，周围没什么可做的。It's a good question. It was a long long time ago. my my parents actually decided to move out of Brussels where I was born and just thought it was great to just buy a small house and refurbish it. But it was in the middle of the middle of a village with not much going on.

我觉得那里大概住着200人左右。没多少人是我想和他们聊聊，或者你知道，能和他们交朋友的。所以我有点被困住了——那时我还很小，大概八岁。I think there was like roughly 200 people living there. Not many that I felt like I wanted to talk to or you know could make friends with. And so I kind of got stuck this is like very early like 8 8 years old.

我算是卡住了吧，因为你知道，电脑嘛，而且那时候对我来说，互联网还处于早期阶段，你知道，那就是我了解各种事情的方式，所以后来的一切基本上都源于此。我觉得我得感谢我的父母，因为他们搬到了一个偏僻得几乎什么都没有的地方，然后你知道，我别无选择，只能开始对电脑产生兴趣。你高中毕业之后，就继续去上大学了，对吧？I kind of got stuck cuz like you know computers and you know it's like early days of like the for me the internet and you know that was my way to learn about things and so just the rest is just like you know came from that. I sort of like I owe it to my parents to you know have moved into the middle of nowhere and then you know I had no choice but to get interested in computers. Once you you finished high school like you went on and went to university, right?

确实是在认真学习它。是的，我在大学学习的是数学，应用数学。Actually studying it properly. Yes. I studied mathematics, applied mathematics at university.

我去那里挺挺早的。所以我毕业也很早。就像是，我很长一段时间都觉得自己可能根本坚持不下来，会退学。我当时有一些小公司，也做一些小型咨询业务；比如在读书期间，我还为银行工作。I went there quite quite early. and so I graduated early as well. Like I thought for a long time that I would actually not make it and that I would drop out. I had like small companies and small consulting business like like while I was studying I was like working for banks.

我当时的工作与供应链和应用数学问题有关，我对此非常感兴趣，也算是通过推销这方面的服务并从中学习了很多。后来我进入了比利时的创业圈，在那里工作了一段时间，之后搬到伦敦，先是在 Google 工作，后来去了 DeepMind，现在又来到加利福尼亚的 OpenAI。I was working for I was like very interested in supply chain and applied mathematics problems and I sort of like selling that and learning a lot through that. Eventually ended up in the startup world in Belgium. I did that for for a little while and then moved to London to work initially at Google and then Deep Mind and then now you know moved to be here at OpenAI like this California.

我喜欢加利福尼亚的天气。我们可以聊聊这个。天气一直都很好。你大学毕业后就开始了——你创办了一家初创公司，对吧？I love the California weather. We can talk about that. it's been very good. Right after university you started you you've founded a startup right?

你骨子里就有创业或企业家的那股劲儿。对。所以这家初创公司主要做的是医药供应链，研究临床试验中的供应链，并试图对其进行优化和决策：比如，是否应该生产更多药品、应该把药品送到哪里、该如何调度，以及如何避免浪费，从而提高临床试验的效率。我们当时使用的是传统的非 ML 技术，也就是传统的优化方法、求解方法、蒙特卡洛模拟之类的技术，本质上是随机多阶段优化问题。我们还把这些方法应用到了钢铁行业，也应用到了欧洲的电网。总之，只要某个问题具有优化问题的形态，我们就会对此产生兴趣。直到今天，这家公司仍然存在，而且我觉得他们现在做的工作依然非常有意思。当然，随着现代 AI 的发展，情况也在发生很大变化。 不过这很有意思，因为你刚才说：“对，那不是 ML，只是传统方法。”然后你又讲到了蒙特卡洛模拟、优化和算法。我感觉你当时就是一路深入钻研：有一个问题空间，然后你会想，怎么运用自己学过的数学知识，以及那些还没学过的东西，不断地深入下去。我这样理解对吗？ 对，正因为如此，我才会痴迷于应用数学。核心就是这样一个想法：你可以研究理论数学，或者理论科学和物理学；在那里，你做这些事情，是因为有东西等待被发现，因为其中有某种美感，因为一切都与模式有关，也因为你在不断推动知识的边界。但你不一定总是知道，最终要如何应用它。然后，现实世界就在那里——周围有各种各样很酷的问题。我当时非常感兴趣的是：如何让这个世界变得更好？所以，我如何把复杂的数学应用到身边的世界中，对它进行优化？这就是那家初创公司背后的很多理念。 后来，在初创公司之后，你去了 Google。最开始是在 2015 年的 Google 伦敦办公室。我记得，2015 年的 Google 是一个非常非常难进的地方——就行业竞争性或声望而言，可能和今天的 OpenAI 一样难进。You had the startup bug in you or the entrepreneur entrepreneurial bug. Yeah. So this this startup was all about pharmaceutical supply chain looking at the supply chain for clinical trials and like try to optimize and decide like hey you know should you produce more medicine where should you send it where should dispatch it like how do you avoid waste and through that making clinical trials more efficient and this was using traditional like nonML techniques like traditional like more optimization solving Monte Carlo simulations these kinds things stochastic multi-stage optimization problem really and we also applied it on steel industry and we applied it to electrical grid as well in Europe it's like anything that sort of had the shape of like an optimization problem we sort of like get interested in and you know to this day like this this this company still exists and I think they do some of the most interesting work still but it's changing a lot you know with with modern AI for sure but it's interesting because you kind of said like oh yeah that wasn't ML it was just the traditional stuff and then you go into like Monte Carlo simulation and optimization and this algorithm I get a sense that you kind of just went deep right that it was like okay like here's a problem space like how can I use mathematics stuff that I learned stuff that I didn't learn to just go deeper and deeper do I sense that correctly yeah that's that's why I was obsessed with applied mathematics is just really this idea of you have theoretical mathematics or you have theoretical science and physics and like there you just you you do it because there's something to be discovered and something beautiful about it and it's all about patterns and pushing the frontier but you don't necessarily always know like how you're going to apply it and then there was like the real world right this like you know there's all these cool problems that just lie around and I was like very interested in seeing like you know how can I make the world better and so like how do I apply like you know sophisticated mathematics you know to just optimize the world around me and that was like a lot of the thesis behind that startup yeah and then after a startup you ended up at Google and first at Google London it was in 2015 and I remember 2015 Google is a really really competitive place to get into like maybe as competitive as open AI is today in terms of the industry or terms of prestige.

你最初在地图部门工作，后来转去了 DeepMind。能不能谈谈你当时做了些什么，以及为什么要离开一个你显然很喜欢的、已经非常有趣的领域——比如优化、物流以及所有这些事情？好的。You worked on maps initially and then you moved over to deep mind. Can you talk a little bit what what you worked on and and then why did you move on from a already really interesting space that you clearly loved you know like optimization logistics and all these things? Yes.

我并不是，我并不是从 Google Maps 开始的。我开始做的是一个旨在让网页加载更快的项目，尤其是让网站在移动设备上运行得更快。当时，你知道，Google 也正处于从桌面端向移动端过渡的阶段，越来越多的流量转向手机，所以我们想提前布局。I didn't I didn't start on Google Maps. I started on a project that was meant to make the web faster. and make to me to make websites faster especially on mobile. At the time you know Google was kind of so like seeing the transition from desktop to mobile and like more and more traffic going to like you know mobile phones and so like wanted to get ahead of that.

因此资助了许多倡议和项目。我当时正在参与其中一个项目。这真的非常非常有趣，因为它实际上是广告部门内部的一个小组。So funded like a number of a number of initiatives and projects. I was working on one of them. This was like really really fun because it was a small group within actually the ads organization.

这个项目本来是想抵消广告收入因流量转向移动端而造成的损失，我大概做了两年。后来项目被取消了。虽然那段经历是我在解决高难度技术挑战时最开心的一段时光，但我也从中学到了很多：没有产品市场契合度、没有正确的用户、没有合适的反馈闭环，以及当产品经理说项目进展顺利时，不能盲目相信他们——因为实际上项目可能根本进展得一点都不好。后来有一天，一位副总裁从加利福尼亚飞过来，然后就像这样说：“是的，很遗憾，我们要取消这个项目。你们现在只有几百名用户，这显然还达不到 Google 的规模。”这简直令人难以置信，但大家似乎都很惊讶。我觉得这里面有一个我一直铭记至今的教训：永远要质疑，永远要不断深入思考自己正在产生的影响，同时也要重视自己参与的整体项目究竟有多重要。It was meant to sort of like you know offset the loss for the ad revenue loss because of the shift of traffic to mobile and worked on it for roughly two years. and then it was cancelled and although it was like the most fun I've had on, you know, solving hard technical challenges. I learned a lot from not having product market fit, not having the right users, not having the right feedback loop, not trusting your product manager when they say the project is going well when in fact it's not going well at all. And then you know one day it's just like this VP flew in from California and then it was just like oh yeah it's like you know we're canceling this project you know unfortunately you only have you know hundreds of users and this is clearly not Google scale and then it's unbelievable but people were surprised and I think there's a lesson there that I that I carry with me of course is you know just always always question always go to like always you know deeply think about the impact that you're having but also like the importance of the overall project that you're contributing.

然后我转到了 Google 地图。Google 地图非常有趣。我参与了评论功能的开发。And then I moved into Google Maps. Google Maps was super fun. Worked on reviews.

然后大约一年后，我再也无法忽视 DeepMind 了。它就是一个非常特别的地方，总部位于伦敦。那里正在发生许多很棒的事情。And then after roughly a year, I couldn't ignore like Deep Mind. It was just it was this special place. headquartered in London. So many great things were happening.

那确实还是非常早期的时候，你知道，当时已经有一些像 AlphaGo 这样的事情初现端倪，而它们似乎正在做着非同寻常的事情，你知道，真正去攻克那些能够挑战的最最困难的问题。以我的背景来说，我显然被这些吸引了，于是就从那里开始了——我参与了大量研究基础设施和研究工具方面的工作。这是一个我延续了将近十年的主题，而且这也在很大程度上体现了我的……This was like really the early days, you know, with rumblings of things like AlphaGo and they just seemed to be doing extraordinary things and you know, just really tackling the very very hardest problems that you can tackle. And like with my background I was obviously drawn to that started there like I worked on a lot of like the research infrastructure research tooling. This is a theme that I carried on for almost a decade and it's like this is very much also the like how I

从 Google 到 DeepMindFrom Google to DeepMind

我处理事情的方式是：我怎样才能构建出工具和产品，帮助其他人提高效率，并为他们带来大量实用价值。最初我这样做是为了研究，后来随着时间推移，你知道，我开始以一种更加、更加普遍的方式去思考问题，越来越泛化，最终就走到了现在的位置。嗯。approach things is how can I build tooling and products that help make others more efficient and bring a lot of utility to them. Initially I was doing this for research and then like over time you know I got like into thinking about things in a much more like more general and general and general way you know eventually like you know ending up where where I am now. Yeah.

还有一个你最近也在 X 上分享过的有趣故事：你曾参与团队开发了这个 Google 内部机器人。可以这么说，它和 ChatGPT 类似，但比 ChatGPT 早了一年。你能谈谈这件事吗？这是个全新的故事，我以前从没听说过。And a fun story that you recently shared on X as well is how you were part of the team that built this internal Google bot that was you know if you want to say similar to Chad GPT but a year before Chad GPT can you can you talk about that? That's a that that is a new story. I haven't heard it before.

这属于 DeepMind 的一部分。当时还有多个类似的项目。此外，当时还有一个独立的 Brain 项目。This was part of deep mind. There were like multiple efforts as well. There was like brain as well that was separate at the time.

他们在大型语言模型方面也有自己的努力，但这确实是当时正在探索的方向。它并不是 DeepMind 的主要着力点。DeepMind 当时非常关注并忙于思考宏大挑战和游戏之类的问题，你知道，他们思考的是强化学习，而不是语言方面的强化学习。They had their own efforts on large language models, but it was definitely something that was being explored. It was not the main thrust of of deep mind. Deep mind was like very much worried and and busy like thinking about grand challenges and games and you know thinking about RL not in the language sense.

当时有这么一个团队在推动大语言模型的发展，他们思考的是：如果大型文本语料库就是一切呢？如果只是把语言推向极限，不断扩展语言模型的规模，这是否就足以实现通用智能？那在当时是一个非常热门的争论，后来有一方决定真正沿着这条路深入推进。与此同时，在和其他人一起为研究搭建工具时，这一切感觉也非常自然：你会想，我们能用这个模型做什么？应该如何把它呈现给研究人员？他们又该如何调试输入和输出？最终，你就会自然而然地得到一个聊天系统。And so there was like this group that was pushing on large language models and you know thinking about you know think what what if what if large text corpuses are everything. What if you just pushed language to its maximum and you just scaled language models like you know would that be enough to get to general intelligence? That was like a hot debate at the time and then one one group decided to just really push on that and then it it felt really natural like you know as I was building tooling you know with others for for research is like you know obviously you're like hey you know what can we do with this model like how do we present it you know to the researcher like how can they sort of like you know debug the inputs outputs and eventually you sort of like end up with you know like a chat system.

所以我们在内部构建了那个东西。我们玩得非常开心。起初，这些模型有点荒诞，几乎就是那种不太连贯、也不怎么实用的东西，但摆弄它们确实很有趣。后来它的发展速度像野火一样迅猛；这个应用就是这样，大家都在 DeepMind 内部分享一些对话。它给人的感觉不再只是一个研究项目，或是一个供研究人员使用的项目。So we built that internally. We had a lot of fun. initially the models were like you know kind of like almost like a little bit absurd like you know not very coherent. not super useful but it was a lot of fun to sort of like tinker with them that caught up like you know like wildfires like you know this application is just sort of like you know everyone was kind of like u sharing little conversations within deep mind. It felt more than like a research project or like a research a project for researchers.

因此，随着时间的推移，大家就产生了把它作为一个外部产品推出的想法。但 Deepine 当时并没有做好这样的准备，你知道，Google 有一套正确的产品发布方式。有一整套你知道的、关于如何完成这件事的机制，也就是那套经过正式认可的生产技术栈。And so then there was this desire over time to like launch it as an external product. But Deepine was just like not set up, you know, there was like the right way to launch products at Google. There's like, you know, the whole machinery of like, you know, how you do that., you know, the whole like blessed production stack.

多年来，你们显然已经把事情做得非常非常优化、非常出色，但同时也让这里成为一个真正很难进行创新的环境。然后我想问，是什么让你开始环顾四周，或者甚至考虑加入 OpenAI？不过我觉得你刚才已经部分回答了这个问题。设身处地地想，如果当时是 2024 年或 2023 年，你身在 Google，那里不断发表非常出色的论文，开展非常优秀的研究，你做着超级有趣的事情，不断突破此前的极限；而且你所在的是一家你已经为之迁居的公司。对于那些目前对自己的处境感到相当舒适或满意的人——我想你当时一定也是这样——究竟是什么让你仍然愿意继续探索，想看看外面还有什么？嗯，我当时在自己的岗位上确实非常舒适。那里是个很好的地方，但我确实渴望认识优秀的人，也希望加入一项我真正相信的使命。我觉得那里的人的确忠于这项使命，并且非常在意以一种非常积极、深刻的方式影响世界，同时也是直接地产生影响，而不是说：“对，我们只是在这里做这些工作，至于如何让它真正发挥作用，那是别人需要解决的问题。”You obviously very very optimized over the years to do things well., but also very very hard as an environment to truly innovate. And then I I wanted to ask what made you you know look around or or or maybe even consider open AI but I feel you partially answered this question just putting myself back into your shoes like you're you know if it's it's 2024 or 2023 you're inside of Google who are publishing amazing papers doing really good research you're doing super fun stuff right that pushing the limits of what what's been done before it's inside a company where you already moved you know for people who are feeling kind of comfortable or good about where they are right now which I imagine you must have been like what made you still explore all right like what else might be there? Yeah, I was I was very comfortable at my it's it's a good place, but really I had a I had a desire to, you know, meet great people, but also join a mission that I truly believed in and that, you know, I felt like the people were true to the mission and cared deeply about impacting the world in in a very in a deeply positive way, but also in a direct way, not not being like, oh yeah, it's just like, you know, we just do this work over here and then it's like it's the job of someone else to figure out you know how to how to make this useful.

就像是我想加入这样一个团队：你知道，所有参数都被放在一起考虑，研究和产品真正共同参与设计。Open 当时简直势不可挡。我以为 chatbt 正在起飞。It's like I wanted to join a group where you know like all the parameters were sort of like considered together where you know research and product were like really co-designing. Open was just like crushing it. I thought chatbt was like you know taking off.

我当时是这样：我遇到了几位来自 OpenAI 的人，然后我就想，等等，你知道吗，你们在做 Chad 的时候，团队里竟然只有大约 20 个人？这实在是少得惊人，肯定会让人拥有极大的自主权。你们究竟是怎么做到的？只有 20 名工程师，却要维护一个如此大规模、如此高度自主的产品，你们是怎么管理的？后来我不断深入了解，发现那真是一群令人惊叹的人，有着令人惊叹的使命——他们才华横溢、动力十足。这一切都把我吸引了进去。于是我马上加入了早期的推理工作。典型的 OpenAI 风格：我加入时，事情大概是这样的——“没错，现在有一件事正在进行，我们要推出推理模型，这是一个全新的范式。”然后我们就开始全力冲刺这件事。大约一个月后，公司推出了 01、01、01 preview，能够参与其中令人无比振奋。我想加入一个行动迅速、重视影响力、能够与世界保持同步的地方；一个真正倾听、不断吸收反馈的地方。这也是我一直带在身上的理念：无论是在构建 Codex，还是在打造产品，都要拥有一个社区，倾听这个社区，真正专注于建立一个非常紧密的反馈循环，然后打造出一个你真正愿意投入心力、真正关心它为世界提供的实用价值的东西。当然，之后你很快就开始参与 Codex 的工作了。所以你是在 2024 年加入的。I was like I was I met a couple people from OpenAI and then I was like wait what you know you only have like 20 people working on Chad like that is that is an insanely small number that that must be like extremely empowering like you know how does that work? How do you manage to maintain you know a product with that level of scale and with that level of autonomy with you know only only 20 engineers and then you know as I kind of dug and dug and dug and it's like it was just a an amazing group of people amazing mission you know super talented super driven and like it was it was like drew me in and then I joined pre-ereasoning efforts immediately like typical openi fashions like I joined it was like oh yeah you know like there's this thing going on like you know we're going to launch reasoning models like you know it's like some new paradigm and then you know start sprinting on that and like you know like a month later like the company launched 01 01 01 preview and that was exhilarating to be part of I wanted to be part of like a place that moves fast cares about impact would be in tune with the world and you know just really listen and sort of like that's also to me like you know what I've carried with me like when when building codecs when building products is like having a community listen to the community just really focus on like a really intense feedback loop and then building something that is just like you know you just really want to care about it and like you know care about the utility of it that it provides to the world and then of course you started to work pretty quickly on codeex. So you joined in 2024.

你能带我们回顾一下吗？你刚加入时，那里对于 AI、LMS 以及代码的思考是什么样的？我知道当时有一项 ASWE 工作。我们在 The Pragmatic Engineer 做的那次深度访谈中也谈到过，也就是自主软件工程师 AS3。Can you take us back what the thinking back there when you joined was about AI or LMS and and code? I know there was this ASWE effort back then. The we talked about it in the deep dive as well that we did in the pragmatic engineer the autonomous software engineer AS3.

是的，这就是它在内部的发音。我们现在已经不再有 A3 项目了，你知道，它就是 Codex。不过对我来说，实际情况是，我加入之后开始为研究构建基础设施；我之前做的大量工作都是大规模数据存储和分析，以及帮助我们理解训练运行的工具。这些年来我做了很多不同的事情，但始终都是在为其他人构建东西，让他们更快，并且真正关心如何从根本上把这些事情做好，然后通过工具和基础设施让新的可能成为现实。所以当我加入 OpenAI 时，我也是抱着同样的想法；但后来有了 one preview，以及你知道的一些后续模型，我们很清楚，必须利用模型本身来帮助我们加快速度。Yeah, that's what it's it was pronounced internally. we we don't we don't have an A3 effort anymore like you know it's it's it's codeex. but really for me it was I joined I started building infrastructure for research like my a lot of what I did before was large scale data storage analysis and then tools to understand training runs. I I did a lot of different things over my years., but it was always about building for others and making them faster and just really caring about, you know, fundamentally doing that well and then through tooling and infrastructure making new things possible. And so when I joined OpenAI, I was like with the same idea and then with the re with with one preview and like you know some some of some some of the later models, it was very clear that we had to use the models themselves to help us go faster.

因此，我真的开始痴迷于这样一个想法：这些模型的局限性是什么？我们要如何利用这些模型本身来开展研究？于是，我和研究领域的其他人一起开始训练模型。And so I just really got obsessed with this idea of what were the limitations, how were we going to use those models for research itself. So got together with other folks in research. We started training models.

我们开始构建一些小型代理。这些确实是 Codex 的前身。我们当时在训练内部模型，使其非常熟悉 OpenAI 的 Python 代码库，同时也让它们在架构设计和代码风格方面具备良好的品味。We started building little agents. Those were truly the precursor to to to Codex. And like this was like we were training internal models to be very proficient on the Python codebase of OpenAI and then very proficient with you know having like good good taste in architecture, good taste in you know like code style.

当时就只有 Python，然后我们的想法是，你知道，我们可以用它非常快速地构建基础设施，同时也帮助研究人员更快地编写代码。然后，我们的推进速度会更快。随着时间推移，当你不断推动这件事，并把它简化到核心时，你会发现，我们可以非常快速地取得大量进展，也能非常快速地学习。Greg 和 Sam 都是非常支持我们的人，而且 Greg 非常坚定地认为，我们不应该只关注自己，也应该关注如何让世界受益。所以，他一直鼓励我们思考：这不只是 OpenAI 自身使用的工具，也应该是我们真正打造出来的一款产品。于是，我们将这项研究工作与 AS3 工作合并，开始构建同一个东西。之后，这促成了一次冲刺，推出了最初的云端 Codex，但它并没有真正实现 PMF，因为使用门槛有点太高了。随后，我们还推出了 codeex CLI，并继续推进，但始终围绕着这样一个想法：我们如何让模型真正提供帮助。你提到，最开始你们开始构建这个模型，是为了在……上进行训练。It was like Python only and then the idea was like you know we would sort of like use that to build infrastructure very quickly and you know help researchers code faster as well. and then you know and then we would move faster and then over time when you just kind like push that and simplify it to its core you're making a lot of you know we found like you could make a lot of progress very quickly and then learn very quickly and then Greg and Sam are you know people with they're immensely supportive and also Greg was very adamant that you know we would we would not just focus on ourselves but we would also focus on benefiting the world and so he just sort of encouraged that we would be thinking about this not just as a tool for OpenAI itself but also as something that we would actually make into a product and this is when we merged this research effort with this AS3 effort and we started building one thing and then that led to a sprint which was like the initial cloud codecs that we launched which didn't really have PMF because it was like a little bit too high friction and then we also launched the codeex CLI and we continued to push but it was always this idea of hey how do we get models to really help here. You mentioned that first you started to build this model to train on

加入 OpenAI 与 Codex 的起源Joining OpenAI and the Origins of Codex

Python 代码实际上有助于构建得更好，但后来你做了一个有趣的决定：对于 Codex，你用 Rust 构建了它。当时模型在 Rust 方面还没有经过充分训练，对 Rust 的支持不如 Python 或 TypeScript，对吧？为什么会做出这样的决定？你是不是预计它最终会迎头赶上，或者认为性能更重要？因为这非常反直觉：其他大多数构建的 harness 实际上都不是用 Rust 构建的，而是基于 TypeScript、Python 或其他语言构建的。是的。the Python code and and actually help build in for better but then you made this interesting decision where for codeex you built it in Rust and at the time the model was not on distribution for Rust right it wasn't as good as in Rust and it was in Python or Typescript why did you make that kind of a decision was was it kind of like did you expect that it'll catch up or or you figure that performance is more important or because it was very counterintuitive most of the other harnesses built were actually not built in Rust. They were built on distribution on TypeScript or Python or something else. Yes.

从最初的基本原则出发，我们很早就开始把产品界面和智能体视为两个不同的东西。因此，以一种稳健且安全的方式构建智能体的核心非常重要；也就是说，它需要针对效率和规模进行工程设计。多年来，我们做过一些项目，它们一开始只是“嘿，这东西挺有意思”，后来变成“嘿，我们需要把它扩展到像最大的​​数据中心那样的规模”。在这种情况下，早期的决策最终会变得非常重要，前提是你不能牺牲太多推进速度。所以这是一种权衡。不过，我们内部有很多非常出色、经验丰富的 Rust 开发者，我们的内部模型对 Rust 的表现也不差，而且你还能在编译时获得大量验证——它是静态验证的，诸如此类。这些特性对智能体同样很有帮助。所以事实证明，很快就可以明确看出，如果我们愿意投入一些精力，Rust 作为一种语言其实非常适合构建智能体。但我们主要关注的是正确性，同时也非常关注效率。From first principles like we very early on we were thinking about the product interface and the agent as different things. So it was very important to build the core of the agent in a way that was robust, that was secure as well, that was you know engineered for efficiency and scale and having worked through projects over the years that go from hey this is a fun thing to like, hey, we need to scale this to the scale of like the largest data center is the ear decisions early on are like really turn out to be quite important as long as you don't sacrifice too much of the velocity and so it's like it's a it's a trade-off but we had very prolific and amazing Rust developers our internal models were not bad at Rust and then you get a lot of validation as well at compile time it's like you know statically verified and all these things and that is great for agents too so turns out you know it was quite clear that you know Rust as a language would actually be quite good for agents fairly quickly if we decided to put some effort into it. But primarily we were focused on correctness and we were focused on efficiency as well.

有意思。所以你的意思是，你知道在你的情况下，提前考虑好希望这个东西最终发展成什么样是值得的，比如语言选择之类的事情。显然，现在有了智能体，重写大量内容比过去容易多了，但你仍然可以说，通过搭建正确的——我想应该说是脚手架，或者说你正在构建之上的基线——来避免自己日后返工。我们当时如果用 TypeScript，或者甚至 Python 来编写，应该也能成功，之后再找个时间重写也没问题。但让智能体本身与产品实现彻底分离，使其能够独立于产品存在，这是一个非常重要的原则。如果你把所有东西都放在同一个代码库、使用同一种语言来编写，那么你不可避免地会有些马虎，会让各部分之间产生超出应有程度的交织，进而阻碍之后的进一步创新。Interesting. So you're saying you know it's it's worth in your case it was worth thinking ahead of where you want this thing to be and for example thing like a language choice. Obviously with agents you can rewrite a bunch of stuff and easier than in the past, but it's still like you can say save yourself reworking by putting in the right I guess scaffolding or or or well the you know the baseline of of what you're building on right I think we could have been successful if we had written it in Typescript or you know maybe even Python and then it would have fine and then you know we would have rewritten it at some point but having a very clean separation between the agent itself which can exist irrespective of the product. it was a very important principle and if you write everything in the same codebase in the same language it's like inevitably you're going to be a little bit sloppy and you're going to intertwine things more than you should and then it's going to prevent further innovation after that.

所以，事情就是这样——从某种意义上说，Rust 边界非常重要，在这方面确实很有用。你做出的一个有趣决定，是在所有主要实验室中都很独特的：内置的开源这一点，对吧？CLI 是开源的，SDK 和应用服务器也都是开源的。你们是什么时候、为什么决定这样做的？这并不是理所当然的，尤其是，你知道，过去人们还会拿 OpenAI 的东西是封闭的开玩笑，但你们这里实际上正好相反：这是开放的，而一些竞争对手会发布闭源的工具框架。当然，我觉得很容易理解为什么有人会想要把它做成闭源的，但你们为什么想让它开源呢？ 让代码开源这个想法确实很酷，因为从根本上说，你们构建的是一个编程代理。所以我们当时大概就在想，如果你有了这样一个东西，你显然会把它指向它自身；而且，也许你可以建立一个贡献者社区，让他们使用它来改进它，然后你也能从中学到很多东西。And so that was that was very important like the rust boundary in a sense like was very useful for that. One interesting decision that you made which is unique across all of the major labs is having this built-in open source right the CLI is open source the SDK and the app server are all open source when and why did you decide that it's not a given especially you know there used to be jokes about open AI having things closed but this this is actually the opposite where like this is open whereas like some competitors would would ship closed source harnesses which again I I think it's very easy to understand why you would want something closed source why did you want it open source There was something really cool about the idea of having the code open source because fundamentally what you're building is you're building a coding agent. And so we were sort of like thinking about well if you have that you know you're obviously going to point it at itself and you know maybe you know you can build a community of you know contributors that use it to improve it and then you know you can learn a lot from that.

另外，当时我们非常清楚地感觉到，如果我们要取得成功，开源本身会发生变化，代码本身所扮演的角色也会发生变化。因此，成为这个社区的一部分似乎很重要，而不是与它割裂开来。我觉得，如果你不亲自去见证这些问题，就很难解决它们。还有一点是，这一切当时仍然感觉很早期——事实上，那时候确实非常早。我们觉得自己可能会有一些把事情做好的解决思路。我们也在和训练、研究一起共同设计这些东西，而这一切都在于以最灵活、最好的方式展现模型的能力；但我们并没有所有答案，所以我们会非常坦诚地说：一个好的 harness 应该是什么样的？我们是如何看待这件事的？Also, it felt at the time is like, you know, very clear to us that if we were going to be successful, open source itself would change and the role of code itself would change and so being part of that community seemed important instead of divorced from it. I think, you know, it's it's it's hard to solve problems if you don't sort of like witness them yourself., and then the other thing was just it still feels like early, but it was very early at the time., it felt like we would have some ideas for how to solve things well., and we were co-designing these, you know, with with with with the training and and and and the research and it's it's all about expressing like the capabilities of model in like the most flexible and the best way, but also we didn't have all the answers and sort of being very open about, hey, this is what a good harness looks like. This is how we think about it.

我们确实做过几次非常技术性的深度解析，也写过一些博客文章，还经常讨论这件事。我们想，嘿，世界这么广阔，外面有很多聪明得不可思议的人，我们也会从其他开源项目中获得灵感，所以不如把这变成一个公平竞争的环境，在这个阶段鼓励大家多做尝试、多探索。 现在已经过去了一年，或者说一年半了。以现在的 AI 时间尺度来看，这已经是很长的一段时间了。但回头看，或者结合这段经历，你觉得开源带来了哪些好处？比如工程方面的收益、对工程团队的好处？坦率地说，开源有哪些比较棘手的地方？肯定也有缺点吧。我们就想听听你对正反两面的真实看法。 是的，肯定有缺点，开源确实是要付出代价的。不过它的好处在于，几乎所有东西都可以公开构建。拥有一个小巧的代码仓库也很棒。比如每当我们招聘一个人，让他加入 Codex 团队时，他们通常都已经看过这个代码仓库了。We did like a couple of like very technical like deep dives and blog posts and we talked about it a lot and we thought you know hey it's just like the world is vast out there's like you know crazy smart people it's like you know we're we're going to get inspired by other open source project as well and so let's just make this a level playing field and sort of like encourage a lot of tinkering and exploration at this stage. Now this has been now you know like a a year later a year and a half later which is a very long time in right now in this AI time frame but looking back or taking the experience what are the benefits you've seen the kind of engineering benefits the engineering team's benefits from being open source and just honestly what are things that are kind of hard about being open source right like there must be downsides like just try trying to get an honest take on both sides yeah there there there are definitely downsides it it it comes at a cost Right. the benefits are it's almost something to build in the open. it's awesome to have like a small a small repo as well. Like whenever we hire someone and they join the Codex team, it's like they've seen the repo before.

他们已经看过 PR 了。他们觉得入职培训已经完成了。你知道，已经、已经完成了。They've they've looked at PRs. They're like onboarding is done. You know, it's it's it's done.

是的。就像入职培训时，你可以使用 Codex 查看代码仓库，和它交流并向它提问；但这并不是什么秘密，你可以很快提高工作效率。我们收到了许多很有价值的贡献。Yeah. It's like in onboarding is just like you use Codex to look at the repo, you know, with you and you ask them questions, but it's like it's not it's not a secret issue that you can get productive right away. We get a lot of good contributions.

尽管我们也会收到一股——你知道——海啸般的随机内容。显然，你和其他所有人都一样，对吧？开源正在发生变化。我认为这就是其中一个例子。Although we get like you know an a tsunami of like random stuff as well. Obviously you and everyone else right open source is changing. I think this is one of the examples.

没错。然后对我来说，也对团队中的很多人来说，成为社区的一员并直接做出贡献，会带来很多能量；而不是只说我们关心这个社区，而是真正去做一些事情，你知道，你能看到这确实在耗费我们的精力，对吧。呃，我们其实没必要这么做。缺点是，你知道，它与我们其余的代码是分开的。所以，你知道，有时候我们得划出一些人为的边界，而且，你知道，That's right. And then to to me it just and and to a lot of the team it just brings a lot of energy to just be part of the community and like be directly contributing not just saying that we care about the community but actually doing things that you know you can see it's it's costing us effort right. U we don't have to do it. the downsides are, you know, it's it's separate from the rest of our code. so, you know, sometimes we have to draw like artificial boundaries and, you know,

使用 Rust 构建 CodexBuilding Codex in Rust

跨多个代码仓库协作。当我们在做一些特别令人兴奋的事情时，而且你知道，我们是公开开发的，那么有时候我们会发现，其他人会在我们来得及发布之前就把它复制了。说实话，这多少有点令人难过，但这也是游戏规则的一部分。毕竟，你是在公开开发。work across multiple repos. when we're working on something particularly exciting, and you know, we're building it in the open then, you know, at times we find that you know, others copy it, you know, before we have the time to release it. And it's like it's just a little bit sad., but also it's like it's part of the game, you know. It's it's like you're building in the open.

就像，你知道，你签署的那种合约大概就是这样：你可以复制它。我们的许可证也非常宽松，但当你投入精力做某件事时，心里多少还是会有点刺痛。然后第三点就是，其他所有人也都一样：我们都被各种随机贡献淹没了，而且还得处理由此带来的额外负担。不过这也促使我们去尝试解决这个问题，对吧？我觉得这是好事。除了开源之外，Codeex 有一件事让我感到意外，而且直到最近我才知道：它并不绑定 OpenAI 的模型，你可以在 Codeex 中使用其他模型。你知道，如果换位思考，站在供应商的角度，这一点可能并不明显，因为我看到的其他供应商在推出 CLI 时，基本上都是让你配合使用他们自己的模型。话说回来，是什么让你决定在“使用其他模型”或“允许使用其他模型运行你的 harness”这件事上采取如此宽松的态度？如果你是这个社区的一员，而你的目标是构建一个出色的编码 harness，那么把它和你自己的模型绑定起来又有什么意义呢？It's like, you know, that's that's sort of like the contract that you signed is like, you know, you can copy it., we have a very permissive license as well, but it does sting a little bit when you're working on something and you're like, you know, and then the third thing is just like everyone else is like, you know, we are overwhelmed with, you know, random contributions and, you know, we have to deal with that additional tax., but then that pushes us to, you know, also like try and solve for it, right? which I think is good. And on top of the open source, one thing that surprised me about Codeex, and I didn't even know about it until recently, it's not tied to the OpenAI models, you can use other models with Codeex, you know, like putting myself if in a vendor's shoe, it it might not be very obvious because again, all the other vendors I look at when they do a a CLI, it's kind of use it with our models. again what made you decide to be this permissive about you know using or allowing to use your harness with with other models? It it felt quite natural if if you are part of this community and building an excellent coding harness is like why would you couple it to your model?

做出那个决定感觉，嗯，怎么说呢，相当令人失望。所以那感觉并不对。总的来说，我想你知道，我会尽量做出那种让我觉得“是的”，你知道，就是我能够大致解释清楚、能够证明这是正确的决定。你知道，这和它一开始就是开源的，背后的道理是一样的。That that that felt like sort of like quite disappointing to make that decision. So it didn't it didn't feel right. and in general it's like I think you know it's like I kind of try to make decisions that I'm like yes you know just like I can just sort of like explain it you know it is correct. It's the same reasoning with you know it is open source in the first place.

任何人都可以轻而易举地将它分叉，然后添加对另一种东西的支持。但这样一来，你其实是在鼓励大家去使用那个分支，结果突然之间就产生了额外负担；而你之所以要维护一个分支，仅仅是因为想改动大约 10 行代码来支持另一个模型提供商，这感觉实在很没必要。所以说，既然如此，为什么不一开始就直接支持它呢？It would have been trivial for anyone to fork it and then add support for another thing. But then but then you're just encouraging people to just like you know go and use that fork and then now suddenly you have overhead and the only reason you have a fork is because you know you wanted to change like 10 lines of code to add support for like another model provider that feels very silly. So like you know why not just support it in the first place.

另一点是，我们从能够提供选择性中获益良多。比如说，也许今天你非常喜欢使用 OpenAI 的模型，并且借助它们的效率非常高；但明天推出了一个新模型，你想试试。为什么要强迫你为了尝试一个新模型，就彻底更改自己的配置呢？这样一来，我们也能从原本无法获得的反馈中受益——比如说，也许那个模型有某些地方是你喜欢的。The other thing is we benefit a lot from like being able to just give optionality. So, you know, it's like maybe today, you know, you you you love using OpenAI models and you know, you're super productive with them, but like tomorrow there's a new model that comes out, you want to try that. Why force you to go and completely change your setup just to try a new model and then we benefit from the feedback that we didn't get which is like, you know, maybe there's something that you liked about that model.

也许它实际上运行得并不理想。但对我们的用户和社区友善一些，你知道，在这里感觉像是正确的做法。然后，我们也会尝试其他模型，对吧？我们会在同一个测试框架中对它们进行测试，而这一切都很好。此外，这种可选择性对于与我们合作的公司来说通常也非常重要。这是我们绝对会积极拥抱的方向。Maybe it actually didn't work well. But it's sort of like being nice to our users and to the community is like you know feels like the right thing to do here. and then you know we also you we also try like other models right so and you know we try them in the same harness and you know it's just all all good and then this is all also often like this optionality is very important to companies that we work with. This is something that, you know, we we absolutely lean into.

我认为最后这一点，你知道，任何一家认真经营的公司，都希望拥有选择权，也希望使用能赋予你这种选择权的工具。但我其实很欣赏这一点，因为在我看来，这显得相当坦诚——它迫使整个公司在模型层和工具链层面都做到最优，与开源方案以及可选择的模型展开竞争；它不会让你得以放松下来，说：“好了，我们完成了。我们现在可以暂时歇一会儿了。”是的。This last point, I think, you know, as any serious company, you want to have optionality and you want to use a tool that gives you that optionality. But I kind of appreciate it cuz I feels to me like it's kind of honest like look like it forces the whole company to be to compete the best in everywhere in the model layer and the harness layer with open source with with choosable models and it kind of like doesn't doesn't allow you to like kick back and say like, "All right, we're done. We we can we can we can hang back for a little bit for now." Yeah.

我希望我们通过拥有最好的模型、最高效的模型和最好的产品来赢得用户，然后，你知道，如果我们把这些事情都做好了，我们就会拥有一段美好的时光。如果我们因为某一件事而强迫你使用这个产品，那我觉得这也不会吸引最优秀的人来开发这个产品。而且，你知道，我们正在这里做出自己最好的工作。I want us to win users by having, you know, the best models, the most efficient models, the best product, and then, you know, if we do all of these things, it's like we're going to have a good time. If we sort of like force you to use the product because, you know, this one thing, it's just like then I don't think that will attract, you know, the very best people to work on this product either. And like, you know, it's like we we're doing our best work here.

我们非常重视体验。你知道，它应该让人感到愉悦；也就是说，无论背后的模型是什么，它都应该让人感到愉悦。我喜欢凭实力取胜，而不是靠锁定用户来取胜。We care a lot about the experience. It should feel delightful, you know, like it doesn't irrespect of the model that powers it, it should feel delightful. I love the idea of winning based on merit, not based on lockin.

现在正是提到本季赞助商 Entire 的绝佳时机，他们也遵循同样的规则。不管你喜欢与否，Git 正在成为现代代理密集型软件开发的瓶颈。开发者正借助代理创建更多代码。And this is a perfect time to mention our season sponsor, Entire, who also play by the same rules. Like it or not, Git is becoming a bottleneck for modern agent heavy software development. Devs are creating more code with agents.

这些代理正在推送更多代码。许多开发者正在运行更多并行代理。这些代理又推送了更多代码。These agents are pushing more code. Many devs are running more parallel agents. These are pushing even more code.

GitHub 显然难以跟上需求，并且经常发生服务中断。那么解决方案是什么？Entire 由 GitHub 的最后一位 coza 创立，他从零开始为智能体时代重建了 Git 托管。GitHub is clearly struggling to keep up and has frequent outages. So what's the solution? Entire was founded by GitHub's last coza and he rebuilt git hosting for the agentic era from scratch.

Entire 的构建目标是实现极高的速度，并让你的代码仓库在地理位置上更接近你，从而降低延迟，使代理集群能够并行推送。他们公布了一些数据：Entire 每秒可处理 418 次推送。Entire was built to be very fast and to have your repos regionally close to you to reduce latency allowing for fleets of agents to push in parallel. Some numbers they published. Entire can handle 418 pushes per second.

这比市场上的所有竞争对手都快，最高可达 89 倍。即使 GitHub 宕机，你仍然可以继续工作，甚至不需要从 GitHub 迁移。你只需注册 entire，该平台就会镜像你的代码仓库。That's up to 89 times faster than every competitor on the market. When GitHub is down, you can still keep working and you don't even need to migrate from GitHub. You just sign up to entire and the platform mirrors your repo.

还有一件很酷的事：你是否曾好奇，究竟是哪个提示词生成了这段特定的代码？对我来说，提示词以及与代理的对话所承载的信息，比 PR 本身更多。Entire 会将与你的代理的全部提示词历史直接记录在代码仓库中，方便随时查阅，而且还提供了一个颇具创新性的 UI，用于展示所有这些内容。And one more neat thing, have you ever wondered what prompt resulted in this specific code being generated? I find that the prompt and conversation with the agent carries more information than the PR itself, at least for me. Entire captures all the prompt history with your agent right in the repo easy to check back and has a pretty innovative UI to show all of this.

如果你正在寻找一种即使 GitHub 宕机也能正常工作的 Git 托管服务，请访问 entire.io/pragmatic、io/pragmatic，安装 CLI，然后点击一下即可镜像你的仓库。我已经这么做了。对了，我有没有提过它兼容任何代理，而且是开源的吗？If you're looking for Git hosting that works even when GitHub is down, head to entire.io/pragmatic, io/pragmatic, install the CLI, and mirror your repo with a click. I've already done it. Oh, and did I mention that it works with any agent and it's open source?

我还想提一下我们本赛季的赞助商 Anticys。Tibo 谈到了你所使用的软件的体验应该让人感到愉悦。愉悦的体验不应包含恼人的错误。I'd also like to mention our season sponsor, Anticys. Tibo talked about how the experience of the software you use should feel delightful. Delightful includes no annoying bugs.

但是，当你使用代理来编写代码时，如何避免引入错误？随着代理生成的代码量不断增加，逐行审查代码正变得越来越困难，这也是为什么 Antithesis 远不止于代码审查。Antithesis 会在恶劣的模拟环境中运行你的整个系统。But when you're using agents to write your code, how do you avoid chipping bugs? Reviewing every line of code is becoming a challenge with the amount of code that agents generate, which is why antithesis goes well beyond code review. Antithesis runs your whole system in a hostile simulation.

此模拟包含定向测试和随机测试。通过运行此模拟，它会在用户发现之前找出每个错误。而且由于该模拟完全确定，它不仅能发现错误，还能为每个问题提供完美的复现结果，从而大大简化问题修复。This simulation includes both targeted testing and fuss testing. By running this simulation, it finds every bug before your users do. And because the simulation is fully deterministic, it doesn't only find bugs, it gives you a perfect reproduction of every issue, which makes it much easier to fix issues.

我听说 Antithesis 时想到的第一件事是：自动化漏洞发现和完全确定性的测试听起来像是科幻小说，但其底层实际上是硬核工程。Jane Street、Fly.io 和 Etscd 社区都能满怀信心地交付由智能体编写的代码，因为他们知道这些代码已经通过 Antithesis 验证。要查看更多案例研究和详情，请访问 antithesis.com/pragmatic。The first thing I thought when I heard about antithesis is that automated bug discovery and fully deterministic testing sounds like science fiction, but it's actually hardcore engineering under the hood. Jane Street, Fly.io, and the Etscd community ship agent written code with full confidence because they know it's been verified by antithesis. To see more case studies and details, head to antithesis.com/pragmatic.

有了这些，我们回到 Tibo，以及工具之间的竞争为何是And with this, let's get back to Tibo and why competition between tools is

Codex 团队的工作方式How the Codex Team Works

太好了。是的，我觉得作为一名工程师，我总能看到，每当存在竞争时，作为工具的使用者，体验总是非常棒。就像我记得微软和 JetBrains 之间曾经发生过 IDE 大战，后来各家云服务商也在各种功能上相互较量。现在当然还有各种 harness 和模型。作为一名用户，这很棒，因为我们现在有了更多选择，它们的开发速度也更快了。我想，我们的声音也更容易被听见一些。great. Yeah. And I think as as an engineer like I always see that whenever there's competition as someone who's using tools it's it's always amazing like I remember like when Microsoft had with Jet Brains the IDU wars and then there's the clouds battling with each other with all the features and now of course we have the harnesses we have the models and as a as a as a user it's great because now we have more more choice they just develop faster I guess our voice gets heard a bit better.

所以，听到这个消息真是太好了。说到这个 harness，你能告诉我它现在是如何工作的吗？比如说，当我启动一个 codeex 任务时，它总是在我的机器上运行吗？还是会选择云端？So it's it's great to hear. Speaking of the harness, can you tell me how it works today in the sense of like when I start a codeex task, does it run always on my machine? Does it choose the cloud?

它使用沙箱吗？我该如何控制这一点，或者如何了解这一点？作为一名工程师，我应该对这方面了解多少？是的。Does it use a sandbox? And how do I control this or or know this or how much should I know about this as as an engineer? Yes.

所以，默认情况下，它是在沙盒中运行的。也就是说，如果有某个命令需要额外权限、需要在沙盒之外运行，它会向你这个用户请求许可；但默认情况下，每一次工具执行都会在沙盒内完成，并且完全运行在这台机器，也就是你的本地机器上。这种情况已经持续了一年多了。不过，这件事也在不断演变和变化：你可以选择让它在云端运行，届时它会在一个受管理的虚拟机中运行，这就是你通过 ChatGPT Work 获得的同一个虚拟机。你可以对它进行一定程度的检查，但它运行在 Kata 容器中，这是一个安全环境。因此，一切都会在那个虚拟机内运行，而不会在你的机器上运行。你的机器上唯一发生的事情，就是接收你的输入，然后将输出流式传回给你。这样显然会大大减轻 CPU 和本地机器的负担，而且你可以实现多得多的扩展。这只是一个起点：未来使用云端机器会变得更加无缝；你也许可以让一部分任务在笔记本电脑上执行，另一部分任务在云端机器上执行。而我们真正认为非常自然的一点是，随着模型变得越来越好、能力越来越强，……So, by default, it runs in it runs sandboxed. it everything that if there is like an an a command that should run with additional permissions outside of the sandbox, it will ask you as a user for permission, but everything every tool execution happens within the sandbox by default and it runs entirely on the machine your local machine. And this has been the case for you know more than a year now. But it is something that is evolving and shifting where like you can select to run this in the cloud which then runs in like a managed VM where it's the same VM that you get through chatk work and you can you can sort of like inspect it but like it runs in a kata container it's like a secure environment and so everything runs inside of that VM and it doesn't run on your machine and then the only thing that happens on your machine is like the your input and then the streaming back of the output and so that you know obviously then is like much nicer on your CPU and and your machine and you can scale much much much more and this is like just a step it's going to be much more seamless in the future to like you know use cloud machines and then you know maybe have a combination of like partial execution on your laptop partial execution on on on cloud machines and really The thing that we're thinking about that is very natural is as models just get better and more capable.

它们可以利用比本地机器上可用的计算能力和资源多得多的资源，因此，如果只限制在本地机器上执行，迟早会成为一种约束。是的，它在本地运行有一点非常棒，而我想这也是我喜欢它在本地运行的原因。They can leverage so much more compute and many more resources than are available on your local machine and so it would be a constraint at some point to just limit execution on your local machine. Yeah. One thing that is great about it running locally, and I think the reason I love it when it runs locally.

当然，这确实挺麻烦的，因为如果我在做一些工作，就会出现这种情况：你知道的，我有好几个代理，它们会占用 CPU。如果我想合上笔记本电脑，我不能就让它半开着，对吧？有一次我在一家 AI 公司的办公室里，就把电脑半开着，他们问我：“你在运行代理吗？”我说：“对，我在运行一个。”他就说：“我懂了。”但我之所以这么做，是因为我有本地工具，还有本地的 Postgress 数据库。Of course, it's a pain because if I'm doing some work, it's like, you know, I have several agents, it's it's eating CPU. If I want to close my laptop, I I cannot kind of leave it like half open, right? When I was in one of the offices of an AI company, I had it half open and they're like, "Are you running agents?" I'm like, "Yeah, I have one running." He's like, "I get it." But the reason the reason I do it because I have my local tools, I have my local Postgress database.

我有我的这个、这个和那个。你怎么看云端这件事？云端很棒，但它没有这样的配置，或者说配置起来实在太麻烦了。你是在考虑，或者说，你有没有在尝试搭建这些配置？这让我想起了我们之前聊过的一个话题：云端开发环境。大概在 2022、2023 年的时候它们很火，后来我们更多地讨论了 AI。但没错，我觉得除了大型科技公司之外，云端开发盒子基本从来没有真正普及过，因为前期成本非常高，之后还需要支付维护成本。而且对于像单人开发者或小团队来说，以当时的能力水平，你并不能真正从中受益。但现在代理的能力已经达到这种程度，配置成本几乎为零了，对吧？所以，如果你的代理有能力完成这些事情，那么这些配置成本和维护成本——它应该直接替你完成。I have my my this this and that. How are you thinking about the cloud is amazing but it doesn't have this setup or it's just a pain to set it up. are you thinking or or are you experimenting with you know making the these setups and I'm kind of reminded of a topic that we talked about prea which is cloud development environments and like 2022 23 they're hot and then we talked about AI more but yes I think outside of large tech companies like cloud dev boxes really never took off because there's a very big upfront cost and then you need to pay like a maintenance cost as well and you just you know don't benefit from it as like a a solo developer or like a small team with the level of capabilities that we have in agents now is like the setup almost is free, right? So like this the setup cost and this maintenance cost is like if if your agent is capable of doing it, you know, it should just do it for you.

所以比如说，如果你说：“嘿，你知道，我有本地的 SQLite，或者我有一个本地服务器、MCPS 之类的东西。”那么，实际上要在云端开发机上配置完全相同的环境并保持同步，到底有多难呢？嗯，如果模型直接替你完成这些工作，也许并没有那么难。So for example, if you're saying like hey, you know, I have like I have my local SQLite or I have a local server and MCPS and whatnot. It's like how hard is it to actually configure exactly the same setup and keep it in sync on a cloud dev box? Well, maybe it's not that hard if the model just does it for you.

所以我认为，我们将会看到一种全面由云端编排的机器重新兴起，这样你就不再受笔记本电脑的束缚了，对吧？我们在 Chatwork 上看到非常成功的一点就是，它可以直接在手机上使用。我每天开始工作时，都会在喝咖啡的同时口述一堆任务给它，然后它就会把这些任务完成。And so I think we're going to see a resurgence of, you know, fully cloud orchestrated machines which then frees you from your laptop, right? It's like one thing that we've seen a ton of success with with chat work is like it's just available on your mobile. I start my day just dictating a bunch of tasks into it. next to the coffee and it just does it.

它可以访问我的日历，也可以访问我的电子邮件。它可以访问 Slack，而能够四处走动、处理各种事情，不必到哪里都带着笔记本电脑，实在是太棒了。我觉得这和我们推出 Codex remote 是同一类事情：执行仍然是在你的笔记本电脑上进行的，但如果不必一直开着笔记本电脑，那就太好了。你能不能跟我讲讲，过去你们是如何改进 Codex 的？It has access to my calendar. It has access to my my email. it has access to Slack and it's just so awesome to just be able to walk around and you know get stuff done without having to you know carry my laptop everywhere and I think it's the same things like you know we shipped like Codex remote where you know execution is like still happening on your laptop but it would be wonderful if you know you didn't have to keep your laptop open. Can you tell me a bit on how in the past how did you improve codecs?

因为我记得我第一次使用 Codeex 的时候，那还是早期版本之一，你知道，它可以和你对话，也能做一些事情。但比如说，我说“好吧，做这个改动”，它确实做了那个改动，而我当时还有单元测试，但它并没有运行测试。后来过了几个月——具体是什么时候我也说不准——它就开始自动运行测试了。是你们改进了那个运行指令的脚本吗？就是我不太确定你们到底怎么称呼那个引导脚本之类的东西。它是在改进模型吗？作为开发者，我该如何理解你们是怎样让每个版本变得更好的？也就是说，工具框架和模型之间分别是如何改进的，它们之间又有什么联系？ 这是个好问题。某种意义上说，工具框架总是比模型稍微领先一点。 真的吗？为什么？ 我的意思是，你有一个模型，它能够完成某些事情，但随后你会给它配上一些“拐杖”，这样它才能以一定的可靠性真正完成任务，而且这种方式还要高效，并且符合你作为用户所期待的行为。这大概就是工具框架的作用，对吧？比如提供防护栏，确保安全；让它更高效；让它更容易引导、更易于控制。通常，工具框架还负责我们所说的“开发者消息”，它有点像是被注入上下文中的内容，位于……Because I remember when I first used codeex this was one of the early versions you know like you could talk to it did stuff but for example I said like all right make this change and it did that change and I had unit tests and it didn't run it and then later a few months later I don't know exactly when it just started to run it automatically. were these things did you improve the you know the script that runs you know the instructions I'm not sure how exactly you call the you know the bootstrapping script or whatever that is is it improving the model like as a dev how can I imagine you making each version better between the harness and then between the model and like what's the connection between the two yeah this is a good question so the harness in a sense is always a little bit ahead of the model oh really how so? Oh, what what I mean by that is that you you have the model, it's capable of certain things, but then you set it up with like a couple of crutches so that it can actually do the thing to a level of reliability and in in in a way that is like efficient and also with the behavior that you expect as a user. And sort of like that's the role of the harness, right? is like you know provide guard rails like safety, make it more efficient, make it more like steerable, controllable and then the harness usually is also responsible for you know what we call like the developer message which is sort of like infected in the context at the

交付、安全与发布实践Shipping, Safety, and Release Practices

每一轮开始时。因此，这显然会影响其目的，也会影响智能体在整个回合中的行为。你拥有的很多内容，都是运行框架和模型最初共同作用的结果；比如，你可能会想：“哦，它不运行测试。”start of of each turn. And so that affects obviously like the purpose of that to affect like the behavior of the agent throughout throughout the turn. A lot of what you have is like the result of of the harness and the model initially like maybe you're like oh it doesn't run tests.

所以，你知道，你必须提醒它运行测试，然后我们训练了一个对战模型，它能够更好地反思：当你提出某个请求时，你真正想要的是什么。这样一来，你实际上就不再需要继续告诉它这些事情了。随着时间的推移，我们看到的是，系统中的开发者消息会变短，而在 Codex 团队内部，测试框架也会不断缩减。你们有具体的目标吗？So you know you have to remind it to run tests and then you know we train a battle model that is just you know capable of like better reflecting on what is it that you really want when you ask for something and then you know you don't actually have to tell it anymore. So over time what we see is like the system the developer message shrinks and then the harness also shrinks inside of the codeex team. Do you have specific goals?

你是说，现在 Codex 作为一个 harness 和模型的组合，在这方面并不是很擅长，或者说它会犯一些挺傻的错误之类的？那么，作为工程团队，你们是如何想象、或者说如何推进下一版本 Codex 的开发的？因为作为一个开发者，有件事我不太理解：模型对我来说是某种神奇的东西，当然它肯定会变得更好，我相信你们也有一些反馈渠道；但你们还有 harness，也就是你们正在构建的工具——这可能就是团队主要负责的部分。那你们究竟是如何设定目标的？在传统软件开发中，你会说“我们要构建这个功能”，然后就去构建它，因为你知道该怎么做。但这个开发过程对我来说感觉要模糊得多。 是的，确实如此，这也是为什么我们会共同设计大多数东西。这个过程是研究团队和工程团队之间的协作，工程团队主要负责构建核心的 agent harness。我们总是在问这样一个问题：好，我们现在看到，我们非常擅长这个，但不太擅长那个；同时，我们还希望实现另一件事，因为那会成为一个非常酷的产品功能。然后我们总会审视它：好，这应该通过修改 harness 来实现，还是应该通过修改模型来实现？如果是模型方面的改动，那我们多久能做到？一个月内可以吗？三个月、六个月可以吗？我们会逐步分析这些问题，然后根据我们能在模型中修复它的速度，以及需要进行哪一层级的训练来决定。Do you say like all right now the codeex as a hardness and and model to combine is not very good at this or it's kind of doing silly mistakes or here or how can I imagine how as the engineering team how you're working on the next you know version of of codeex is because the thing that I don't really get as a as a dev is like okay there's a model which to me is this magical thing which will get better of course I'm sure you have some feedback channels but you also have the harness which is the tools that you're building like that's probably what the team is responsible for how do set even your goals right like in traditional software you'll be like we will build this feature and you build that feature because you know how to do it but it feels a bit more fuzzy to me this this development process. Yeah it is and it's why we we co-design you know most things and it's it's a process where it's a collaboration between research and the engineering team like primarily building the core the core agent harness. It's always it's always a question of like okay we see today that you know we are very good at this but we're not very good at this and you know we have a desire to do like another thing because it would be a very cool products feature and then you know we always like look at it it's like okay this should this be like a harness change or should this be a model change and if it's a model change like how soon can we have it can we have it in a month can we have it in you know three months six months and we sort of like work through that and then depending on you know how soon we can just fix it in the model at which level of training.

那么，我们甚至可能决定完全不在 harness 中做任何事情，而只是等待模型自行解决。你知道，这一路都是代理，对吧？所以，我们会使用代理来分析大量反馈，归纳出主题，帮助我们进行这些讨论并确定优先级。Then we might decide to not even do something in the harness at all and not and just wait for for for the model to to solve it. You know, it's it's agents all the way, right? So we use agents to analyze like a lot of the feedback to like, you know, come up with themes, you know, to just help us have these conversations and decide on priorities.

但我们会在整个编程领域对它进行分析。我们也会在其他各个领域进行分析，比如金融、通信、营销，以及如今用户使用这些代理的所有场景。这些领域内部还会细分成不同的子类别，然后我们大致了解自己的表现如何，并且始终在推动前沿发展。有一点很有意思：随着我们的预训练模型变得更好，随着我们让整体模型变得更强，所有方面都会一起提升；但有时，我们会对某些方面给予更多关注。你提到过，他会一直对代理进行全方位的分析。But we analyze it across all of coding. We analyze it across like all of like know the other domains like finance, coms, marketing, you know, all the things where our users are using these agents nowadays and there's like you know subcategories within those and then we roughly know like you know how well we perform and then we're always pushing the frontier and there's a thing that is interesting is like as we make you know as our pre-training model gets better as we make the overall model better like the whole thing lifts up but then there are sometimes things that we pay a little bit more attention to. You mentioned you know he analyzes agents all all the way.

我们能聊聊 Codeex 上的软件开发生命周期吗？我的意思是，每当有一位新工程师加入任何一个团队时，通常都会想：“好，这里是怎么做事的？”你知道，在 AI 之前，如果你加入 Uber 或 Google 这样的公司，他们会告诉你：事情的流程是这样的——我们有一个想法，或者 PM 有一个想法；我们制定计划；大家聚在一起；做一些估算；拆分工作；编写代码；测试；进行代码审查；发布；使用功能开关；然后，你知道，我们还要负责值班——过去基本就是这样。 当有人加入 Codeex 团队时，你知道，他们显然已经为开源部分做出了贡献，但如果他们是一个完全的新手，你会告诉他们什么？这里的事情是怎么完成的？我会把他们介绍给一些很棒的人，然后他们最常听到的一句话——每当他们提出问题时——就是：“你问过 Codex 了吗？” Codex 在 OpenAI 内部默认就已经接入了一切：它可以访问 Slack、所有文档以及所有代码。新员工仍然会对这一点感到惊讶，因为你基本上可以问它任何事情，而它往往真的能给出非常好的回答。所以，想了解一个项目的当前状态、谁在负责某件事，或者某个决定为什么会做出，最简单的方式就是——Codex 了解内部的一切。你只需要利用这些信息。 出于这个原因，我们在公共频道里开展了大量工作。我们会公开文档，并设置相当宽泛的权限，这样每个人都能访问这些信息，你的智能体也可以浏览这些内容、进行推理。除此之外，我们还有一些对团队生产力和协作非常有帮助的功能，目前还没有发布，但之后会陆续推出，其中一部分会在 def day 上发布。 所有这些都会让你非常扎实地了解团队的情况，并与团队其他成员保持同步，也让你能够非常非常快速地理解当前状况，并亲自产出成果。Can we talk about the software development life cycle on codeex in the sense of whenever a new engineer joins a team any team it's like okay how are things done here and you know back preai it would have been you join the company like Uber or Google and they would tell you that cool the way it works is we have an idea or the PM has an idea we make a plan we get together we do some estimations we break up the work we code the work we do tests we do code reviews we release we do feature flags and then you know we we were on call that that you know that's how it used to be when someone joins the codeex team you know they they've clearly been contributing to the open source part but what what do you tell them how do things get get done here if they're like a brand total newbie I introduce them to great people and then the thing that they hear the most about like when they have a question is like have you asked Codex and Codex like is just by default at openi is like plugged into everything so it has access to slack it has access to all the documents, access to all the code, and it still surprises new starters that you can basically ask it anything. and it will very often just like come up with like a really good response. and so the easiest way to understand the state of a project or who's working on something or why a decision was made is like critics knows about it all internally. and so you just you just use all of that. We do a lot of work in you know for that reason we do a lot of work in public channels. we open up documents with like you know fairly broad permissions and so that you know everyone has access to this information as well and so that you know your agent can go through things and like you know reason through things and then you know we have a couple of other things that are just really very helpful for team productivity and team collaboration that we haven't released yet but are are going to come like some of it at def day. All of that just sort of like makes you very grounded and in tune with the rest of the team., and allows you to like, you know, just very very quickly like understand the state of things and and and produce things yourself.

总体建议就是：要关心用户，关心产品的一致性，关心模型以及它们的发展方向。如果你正在做某件事，而且你知道自己是在构建这样一个包含一万行代码的支架，用来绕过模型的缺陷，那你很可能做错了事情。 所以，我们确实有一套原则。但在这一点上，它更像是一种团队文化和理念。你知道，这种文化会延续下去：当有人加入时，团队会带着他们熟悉情况、教他们如何开展工作。然后，当我有一个想法，觉得这是个好想法时，我会和 codeex 讨论，也可能会和一些同事讨论。比如：“这里有个很酷的新功能，我想把它作为我对 codeex 的第一个贡献，或者第一个重大贡献来构建。我应该怎么做？” 显然，我会用 codeex 把它写出来，也会进行测试，确保它能正常工作。之后的流程是什么？你们仍然有代码审查，或者 AI 代码审查、验证、发布，以及分阶段发布和验证之类的流程吗？毕竟，codex 本身面向数百万人推出——我刚刚突破了两千万活跃用户这个大关。但如果是 ChatGPT，那它面向的用户数量还要多得多。 是的，不过无论是在 codeex 上发布，还是在 ChatGPT 上发布，这个流程出奇地相似，尽管 Chibd 面向的是十亿、十亿左右的活跃用户，而且这个数字还在增长。你可以提交一个 PR，可以做出一个改动，然后让它在第二天，甚至当天就上线，随后它就会直接触达十亿用户，而且一切都没问题。我们真正灌输的是一种主人翁意识和责任心，所以人们会非常……The general recommendation is just like, hey, care about the user,, care about the coherence of the product, care about the models and where they're going., if you're doing something and you know you're building like this 10,000 lines of code crutch to work around the model flaws, like you know, you're probably doing the wrong thing. So, we have a set of principles. but it's just really sort of like a team culture and ethos at this point and you know it's just very much so like carries on you know when people join it's just like through the rest of the team just like you know sort like teaching the ropes and then when I have an idea I think it's a good idea I talk it through with codeex maybe I talk it through with some my colleagues like here's a cool new feature I'm going to build as my first first contribution or first major contribution at to codeex how do I go about that obviously I code it down with codeex I obviously test it and make sure that it works from there on what's the process do you still have the concept of code review or AI code review of verification of rolling out of verifying of stage rolled out you know the things because codex itself it goes out to millions of people like I just crossed a big 20 million active user mark but if it's chat GPT then it also goes out to like even a lot bigger number of people yes but it's it's surprisingly like a similar process whether you ship on codeex or chat even though Chibd goes out to like a billion a billion you know active users and growing you can ship a PR you know you can make a change and you know get it shipped like the next day or like even the same day and it just goes out to a billion users and it's fine we just really instill a sense of ownership and care so you're like people are very

代码审查与工程工作流Code Review and Engineering Workflows

被赋予了进行更改的权力，甚至是大幅更改。通常所要求的内容，某种程度上来说，就是一些证据，证明它会受到良好接受；证据表明它是一个有价值的补充；证据表明，你知道，它值得长期维护，同时维护成本也确实已经大幅降低了。 所以，我们现在思考这些问题的方式，与比如两年前或三年前相比，已经略有不同了。另一点是，我们会尽可能地实现自动化。empowered to make changes even large changes the general thing that is being asked is like sort of like evidence that it's going to be wellreceived D evidence that is like a worthy addition evidence that you know it's like it is worth maintaining over time but also like the cost of maintenance is like just really as you know gotten done significantly as well. So we we we think about these things slightly differently than you know say like two years ago or 3 years ago. The other thing as well is like you know we automate as much as possible.

所以，像代码审查、部署以及发现回归问题之类的流程，基本上都已经自动化了。这样一来，你就可以专注于真正的想法，以及它将如何帮助我们的用户；你会在意整个方案的连贯性，也会在意 agent 的整体能力，以及如何让事情变得更好。我们还有一长串想要实现、但目前还没来得及完成的事情。 然后，还有一个大致上的北极星方向：打造一个令人愉悦、简单易用的个人 AGI。它了解一切与你有关、且它需要知道的信息，能够访问合适的资源，有时还可以代表你采取一些有风险的行动；之后，它会向你发送推送通知，你可以核实这些操作。作为用户，你会对它有很深的理解；同时，它也了解你的日程和目标，能够主动采取行动，而且应该极其自然。你可以通过自然语言、语音来控制它；也许它还应该能够理解你的情绪。比如，如果它有摄像头画面输入，那么它应该成为世上最自然的存在。它不应该是一个带着十几个不同按钮和配置项的东西。So like a lot of like the process of like code review and deploys and you know catching regressions is like you know all of that is like pretty much automated. and so like you know you get to just focus on just really the idea and you know how it's going to help our users and you care about you know the coherence of it all and so like the overall power of the agent and making things better and like we don't we have a long long list of things that you know we sort of like aspire to do and haven't gotten to yet. And then there's like the sort of like the northstar direction which is a delightful simple to use personal AGI that you know knows everything about you like you know that it needs to know has access to the right resources can take like you know sometimes risky actions on your behalf but then you know you get like the push notification and then you know you can verify that and it's like a thing that you know you deeply understand as a user but also it knows about your schedule it knows about your goals it can be proactive and it should be like extremely natural it should be something that you can control through like natural language, voice, you know, like maybe it should understand, you know, your emotions like if it has like a camera feed, it should be the most natural thing on earth. It's like it should not be like a thing with 10, you know, different buttons and configurations.

这就像 AGI 应该易于使用一样。刚才你只是简要提到了代码审查，但我想再回到这个话题上。你曾在 Google 参与开发过一款产品——Google 地图——它的用户规模达数亿，而 Google 也因其非常严格的代码审查文化而闻名。我想他们有两层代码审查。It's like AGI should be simple to use. Now, you kind of mentioned just briefly the review the code review, but I wanted to go back to it. you you worked at Google on a on a product used by you know like hundreds of millions which is Google maps and Google is very well known for their culture of very strict code reviews. They have I think two layers of code reviews.

有语言正确性审查，而且我认为他们在很长一段时间里确实已经在整个行业中把这件事做得非常完善了，他们也确实相信它有效，并且一直在使用它。你觉得这一部分具体是如何变化的，尤其是人工审查？因为在很长一段时间里，直到大概一两年前，我都会说代码审查有这些好处：知识共享、第二双眼睛、降低单点故障风险，因为现在有其他人理解这部分内容，而当那个人不在时，他们可以介入；大家讨论的是架构，而不仅仅是代码本身。但现在，代码量明显更多了，那么代码审查的价值是什么？There's a language correctness review and they they've taken I think they've really perfected it across the industry for for a long time and they do believe that it it works and they they use it. How do you think that part is changing specifically the human review? Because for a very long time until maybe a year or two ago, I would have said you code review has all these benefits that knowledge sharing the second pair of eyes removing the bus factor because now someone else understands and when that person is out that they can jump in conversations are happening about architecture not just not just the code but now there's you know there's a lot more code and what was the value of code review?

具体是哪些情况？另外，鉴于你们团队在这方面走在前列，你们认为在审查阶段，哪些环节仍然需要人类或开发人员参与才有价值？哪些情况下则可以不参与？What in what cases? And so on your team, because you guys are so ahead of this, where do you see humans still being or developers being involved in the review stage valuable? And and where is it fine?

你觉得把它交给一个代理来处理没问题吗？是的，代码审查的角色正在发生变化。我在 Codex 上早期做的项目之一，就是与研究团队合作开发一种代码审查模型，使它能够发现逻辑和推理上的错误，达到这样一种程度：人类需要花上几个小时，甚至可能多个小时，才能发现同等级别的错误，因为这需要真正深入挖掘依赖关系，深入三四层，并且理解文档可能其实是错的，或者某个第三方依赖的实现方式与你预期的不同，因此你的不变量没有得到保持，等等。除非你是那个库的专家，否则你根本不会知道这些，于是就产生了一个 bug。于是我们开发了这些代码审查模型，并将它们发布了出来。如今，具备这种通过深度验证来发现错误的能力和水平的模型，已经成为主线模型的一部分。我们对它们进行基准测试时发现，它们在代码审查方面已经超越人类，而且这不仅仅适用于正确性。Did you find it find it fine to hand it off to an agent? Yeah, the the role of code review is changing. One one of the early projects that I did on Codex was like working with research on developing a code review model that was going to be to a level where it can spot mistakes in logic and reasoning. to a degree where it would require humans like you know multiple like potentially multiple hours to capture the same level of mistake because it requires like really digging like you know three four levels deep into like the dependencies and like you know understand that maybe the documentation actually was wrong and like the implementation of like this third party dependencies like different from what you expected and so therefore your invarants are not upheld and these things it's just like you know unless you're an expert in that library you wouldn't know and therefore you have a bug and so we developed like these code review models and you know we we we released them and now they're like the same level of like capability and like ability to spot these mistakes by doing like you know deep verification are like just part of the mainline models like when we benchmark them it's like they're like super human in code review and this is not just true for correctness.

安全性也是如此。比如说，你能够进行跨领域的推理，处理非常非常复杂的问题，然后指出：“嘿，你这里存在一个严重的安全漏洞。”现在，所有 OpenAI 的拉取请求都必须遵守这一要求：如果我们发现其中存在安全问题，就会阻止拉取请求合并，而且这一切都是自动完成的。 我认为，代码审查的作用一直都在于正确性，一直都在确保代码能够正常工作；但它也有点像一种信息交换仪式，用来让大家达成共识，并鼓励进行讨论——理想情况下，这些讨论本应更早发生，但有时却只会围绕代码展开。因为代码一旦合并，就会真正运行在生产环境中，开始执行实际操作，之后还需要对其进行维护。所以，这其中也包含一种社会层面的因素。 我认为，所有这些都在发生变化。正确性、网络安全、安全性，我想这些都会被自动化。我们真正看到的，至少我看到的，是围绕拉取请求中的意图展开的一种讨论：你到底想做什么？尝试做这件事是否正确？我认为，这种讨论完全可以在拉取请求之外进行。This is also true for security for example where you're capable of like reasoning across like you know very very complex things and then you know coming up with like hey you know you have a critical security vulnerability here which is now mandatory across like all of OpenAI pull requests like we block pull requests from merging if you know we flag them with like a a security issue and this is like all automatic and the role of code review now is like I think it was always about correctness it was always about you know ensuring that things worked but it was also sort of like a little ritual for information exchange and you know bringing people on the same page and like you know encouraging like a discussion which ideally would have happened before but sometimes it just only happens like around the code because once it merged it just actually runs in production it's doing stuff and then you have to maintain it so there's like this social aspect to it as well it's I think all of it is changing like the correctness the cyber the security is like I think that will be automated really what we see and I see is there's a sort of really discussion around the intent that takes place around the poll request. It's like what are you even trying to do? and is that a right thing to attempt to do? I think you can have that discussion outside of the poll request.

不一定非得围绕代码展开。所以，也许这能帮助我们更明确地认识到：哪些地方需要进行讨论，哪些地方之所以会这样，是因为当时我们可能还没有现在这样的工具。是的，我觉得这会带来改变，它就像一个强制推动因素，因为你必须进行那场讨论——最好是在合并代码、让它变成生产代码之前就讨论清楚。不过我觉得，还有其他方式可以进行这些讨论，一起做设计，确保意图是好的。这样一来，代码本身就没那么重要了。有意思的是，当我回想自己经历过的所有代码审查时，当然，我记得有些时候很棒，我们进行了很好的讨论，或者我学到了非常有意思的东西；但老实说，很多时候，那简直让人烦透了。It doesn't have to be around code. So, so maybe this helps crystallize the you know like where a discussion needs to happen versus versus where we we did it because maybe we didn't have the type the type of tooling that we have right now. Yeah, I think this is going to change and it was like a forcing function because you know you have to have that discussion where like it's good to have that discussion before you merge it and it becomes production code but I think there are other ways to have these discussions and you know design things together and make sure that the intent is good and then the code doesn't matter as much and it's interesting because when I think back of all my code reviews like of course I have like memories where like it was great we we had a good discussion or I learned something really interesting but a bunch of times honestly It was such a pain in the ass.

就像我当时正试图拿回我的东西一样。你来付钱。嘿，你能把我的代码移除吗？Like I was trying to get my stuff. You're paying. Hey, could you remove my code?

就比如说，不，我现在正忙着呢。不，我真的需要这个来帮我解困。然后你就切换上下文。And like, no, right now I'm busy. No, I really need this to unblock me. And then you context switch.

然后我觉得，一直以来不都是有好有坏，对吧？所以我觉得，无论我们做什么，总会有利有弊。不过现在它们只是在不断发展变化。所以我想，一个好处是，作为一名工程师，你可能不必再把注意力放在那些本身并不需要你亲自参与的基础事务上。And then I feel it's always been like good and bad, right? So I feel whatever we do there will be always upsides and and downside, but there now they're just moving. So I guess one upside is as an engineer you might have to not give your attention to just kind of basic stuff that doesn't need your input per se.

是的，这能节省时间，而且我认为我们逐步会看到的情况还包括：你们对这个“盒子”以及它应该完成什么的整体契约达成一致，然后至于盒子里面是什么，只要你们在资源使用、数据访问、安全性等方面有严格的保障即可。就像……Yes, it saves time and I think progressively what we're going to see is also like you have an agreement on you know the box and the overall contract of what it's supposed to do and then you know what is inside the box as long as you have like strict guarantees in terms of resource utilization, data access, security, these kinds of things. It's like what

维护与重建软件Maintenance and Rebuilding Software

盒子内部发生什么，你知道，实际上可能是任何事情。就像是，你其实不太需要去在意；真正需要达成共识的是：这个盒子到底做什么，以及必须满足哪些不变量。我觉得，这才值得大家认真地讨论一番——当然，也许可以在你喜欢的智能体辅助下进行。但一旦你明确了这些，也有了这种理解，那么在盒子内部更改任何东西，就不需要再专门讨论了。这样确实能更好地保护你的注意力，维护成本也降下来了。 每当我们在 Google、Uber 这样的公司，甚至是初创公司里构建东西时，维护总是一个非常热门的话题。构建本身是有趣的部分，但之后的维护却很痛苦。那时我们才意识到，构建这些东西并不是……等等。在 Codex 和 OpenAI 内部，你认为维护会如何变得更便宜？从你正在构建的东西、目标，或者我猜是自定义工具之类的角度来看，会发生什么变化？ 维护从某种意义上来说，就像是你随着时间推移而支付的一种税，只是为了让一切持续运行。它一直都是必要的，今后也仍然会是必要的。但我认为它发生变化的地方在于，其中很大一部分将会被自动化。比如，你有一些第三方依赖，需要升级版本号。happens inside the box is you know it could be literally anything. it's like don't really need to care and like really what you need to agree on is like what does the box actually do and what are the invariants that must be satisfied and I think that is then worthy you know having like a really good conversation on you know maybe assisted by by your favorite agent but then once you have that and you have that understanding it's just like changing anything within the box is like you know doesn't require for discussion and it's like you know just really preserves your attention the cost of maintenance has gone down you know maintenance is always such a hot topic whenever we build thing inside of all these companies like Google, Uber, even startups like building was the fun part but then maintenance was the painful and that's when we learned like okay it was not we're building it etc inside of codeex and open AAI what do you see maintenance becoming cheaper changing in terms of instead of what you're building what the ambition is the I guess custom tooling those kind of things maintenance is really like sort of like a tax that you pay over time just to keep things running and it's It's it's it's always been necessary. It will continue to be necessary, but where I think it changes is like a lot of it is just going to be automated. So, you know, it's like okay, you have you have this third party dependencies like you need to upgrade the version number.

这就像是一个点赞（笑），你完全可以把这件事自动化，你知道的——如果你有完善的变更日志，而且代码文档也写得很好，模型就可以自己推理这些内容。你知道，你可以直接快速地处理整个代码库，几个小时就搞定。以前你可能会把这事儿先搁置，因为它并不是最有趣的工作，但实际上它对你的业务非常重要。所以，这对你的项目来说真的很重要，尤其是涉及安全漏洞的时候。你希望让一切保持最新，对吧？It's like a like [laughter] you can fully automate this you know if you have good change log and you know and the code is well documented and like you know and and the model can just like reason through it like you know you can just like blast through your codebase do it in a couple of hours and you know previously you would have like punted on it because it's not the most fun thing to do but it's actually really important for your business. So it's like really important for your project, you know, especially for security vulnerabilities. You want to stay up to date, right?

你想应用所有这些补丁。我觉得这将会完全自动化。所以，很大一部分维护工作基本上是自动完成的，对吧？You want to apply, you know, all these patches. I think that's just going to be fully automated. So a large part of like maintenance, it just kind of comes for free, right?

然后我觉得，去想一想这一点也很棒：以前，当你想要彻底重构时，你得做一个全新的架构，因为你在试图为新的、不同类型的权衡腾出空间，或者你对工作负载有了新的理解，或者你想适配一个新功能，然后突然意识到，当前的系统实在太受限了，你需要彻底重新架构它。这曾经是一项非常非常昂贵的工作，对吧？所以，有时候可能要花好几年，而我觉得现在这一切也被极大地加速了。这样一来，犯错的成本，我会说，是在下降的。但与此同时，那些老生常谈的软件工程原则——比如要有良好的抽象——我觉得确实非常有帮助。又回到刚才说的那个带有不变量的盒子：如果你划定了正确的边界，就能在这个盒子内部更快速地修改东西，而不会影响其他服务或基础设施的其余部分。我觉得，为非常快速的迭代而设计非常重要。 我记得以前和 Peter Shamberger 聊过，那是在他加入 OpenAI 之前，我们聊的是 OpenClaw，以及他是如何思考这个问题的。他告诉我，他并不阅读代码，但他一直在思考这些事情。我能看出来，他其实把整个架构都装在脑子里；他还告诉我，他经常重新设计架构，并且会思考如何让系统模块化，如何让 100 名贡献者各自构建自己的部分，同时又不互相妨碍。 所以，我听懂你的意思了：这种关注、这种规划、这种结构化设计，可能已经变得重要得多了。过去，这通常是架构师、资深工程师或者有经验的人在做的事情，周围的其他工程师则负责构建一些较小的部分。但听起来，现在所有工程师在构建软件时，都需要意识到这些问题，并为此做好规划，对吧？是的，而且 GP 模型在这方面也变得越来越好了——比如会考虑长期维护、良好的架构之类的。这就是很自然的下一步，对吧。And then I think it's it's awesome to also think about before like you know when you wanted to just completely react re you have to do like a new architecture because you're trying to make space for like a new you know different kind of trade-offs or you have a new understanding of like the workload or you're trying to fit a new feature and like suddenly you realize like your current system is just very limiting and you need to completely rearchitecture it that was like a really really costly endeavor right so you know like sometimes like multiple years and I think this is also like super super accelerated now. So you like the cost of mistakes you know I would say like you know is going down but then at the same time the good old rules I would say of software engineer of like you know having good abstractions like really help like you know is going back to this like having the box with invariance like you know if you sort of like draw the right shape you're going to be able to change things much more quickly within the box and like not affect the rest of the of the services or the rest of your infrastructure and I think it's important it's important to design for very quick iteration and I remember when I talked with Peter Shamberger that was before he joined OpenAI but about open claw and how he thinks about it like you know he told me that he doesn't read the code but he kept thinking about like I could see that he's holding the architecture in his head and he was telling me how he rearchitects a lot and he thinks about how to make it modular how to allow 100 contributors to each build their thing without stepping on each other's toes. So I'm hearing what you're saying that this this care this this planning this this structuring has become maybe just a lot more important to like which which which was which which was something back in the day you know it was like the architect or the staff engineer or experienced folks were doing this thing and other engineers around them were kind of building this you know smaller parts but it sounds like now all engineers need to be aware of when you're building your software right and plan for it yeah and and the GP models are getting better and better at this as well of like you know thinking about long-term maintenance and like good architecture and like this is like a natural sort of like next step right.

这不仅仅是代码质量的问题，也不只是说“这份文件里的代码是否整洁”，而是，你知道，这个架构是否真的正确，能否随着时间推移降低维护负担，同时为未来产品或功能的扩展或变更留出空间。归根结底，这就是一种随着时间进行工程建设的过程，而我觉得，模型现在开始越来越有能力很好地思考这类问题了。理解我们所构建的软件正在以快得多的速度经历整个生命周期，真的非常有意思。对吧？你知道，以前你可能是从一个小团队开始的，可能团队里就你自己，再加上一两名工程师；然后你会慢慢增加工程师。接着，也许一年之后，如果它非常非常成功，你可能会有 50 名工程师在做这个项目，或者 100 名工程师在做这个项目。It's like not just about code quality in the sense of like oh is this code clean within this file but like you know is this like is the architecture actually correct to reduce maintenance burden over time and like you know make space for like future u product or feature extensions or changes and just really this act of like you know engineering over time that's kind of like something that models are starting to become capable of like thinking about very well I think it's just kind of fascinating to understand that the software that we're building is just going through the life cycle much much faster. Right? Like you know before you had you know you were you were scaling you were starting it you know maybe as like a small team of you know yourself maybe a couple of engineers and then you would add engineers like slowly and then you know maybe after a year you know it's like if it's very very successful you would have 50 engineers on it or like a 100 engineers on it.

你会有时间看到它正在发生。你会有时间去了解，比如说，船上的人类，你也会有时间去思考文档之类的所有事情。但现在，这一切更像是——突然之间，有大约 100 个代理在为这个东西贡献力量，这种情况可能一个周末就发生了。所以，相比以前，你是在以极其极其快的速度推进。好吧，但你和 OpenAI 的人是怎么应对这一切的？这不会让你觉得有点难以置信吗？我的意思是，你已经在这个行业干了相当长的时间——几十年，或者至少也远远不止一段很长的时间——我们曾经习惯了一种节奏。显然，现在速度快多了，但你是怎么消化这样一个事实的：第一，它更快了；第二，你一年前还在做的事情，现在已经不做了，因为模型已经擅长这些事情了？你是怎么调和这种感觉的？因为我敢肯定，有些和软件相关的事情你曾经做得非常好，而现在可以交给代理去做。你不会觉得有一点刺痛吗？我们之前聊过，自己的功能被开源实现会让人觉得刺痛。但同样地，曾经有些事情我做得非常好，比如重构，或者现在可能是架构设计，可也许模型会非常擅长这些事情。那我就会想，好吧，真见鬼——我很高兴，但同时，如果能由我来做，感觉也挺不错的。 是的，我觉得这里面有一种工艺层面的因素。偶尔我还是会打开编辑器写写代码，而那种感觉就是……很舒服。某种程度上，我对那些深夜坐在 Vim 里写代码的时光仍然有美好的回忆（笑），你知道，就是不停地把代码敲出来，喝着 Coke Zero，除了眼前的问题之外，什么都不用想。You would have time to see it coming. you would have time to see like you know the humans on board and you sort of like you know you can think about the documentation all of that stuff but now it's just sort of like that explosion of like you know suddenly you have like a 100 agents contributing to this thing is like you know that can happen like you know in a weekend and so you know you're just going through it at you know major major speed compared to before okay but how do you and and the folks at OpenAI like deal with this like does it not mess with your mind like you know what I mean in the sense of like you you you've been in this business for quite some time now like like decades or or well over and there was a pace that we kind of got used to and obviously is it's now a lot faster but how do you get your head around the fact that a it's faster b the stuff that you've been doing a year ago right now you're not doing because now the model is is good at it and you know like how do you kind of reconcile that because there I'm sure there's stuff that you've been really good at related to software that now you can hand off to the agent do you not get a little bit of sting you know we talked about it's stinging for your features to be implemented open source. But it can also sting that I've been really good at like I don't know refactoring or or or right now it might be architecture but maybe the model will be really good at that and now I'm like okay damn like I'm glad but also like it would have been nice for me to do that. Yeah, I think there's like a craft aspect to it. which occasionally I still you know pull up an editor and like write some code., and it's just like it it it it feels nice and and and it's sort of like I have fond memories of like late nights sitting [laughter] in in Vim and you know, just like cranking it out, you know, drinking Coke Zero and yeah, just not having to think about anything else other than like the problem in front of me.

但说真的，我觉得这全都在于进入状态并解决问题。而我发现，这里的人，还有我交谈过的每一个人，似乎都在非常迅速地适应，我觉得如果你如果你有一个But really, I think it's it's all about being in the flow and and solving problems. And what I find is like you know folks here and also like everyone I talk to is just like adapting very quickly and I think if you if you have a

ChatGPT 中的 Codex 与产品集成Codex in ChatGPT and Product Integration

一种将代码视为解决问题工具的思维方式，而你也因此能够解决更多的问题。就像以前你想对某些东西进行基准测试，却不太确定最终会得到什么结果。现在你可以直接去做。你知道，在后台启动某个任务、获得准确的数据，并做出更好的权衡，整个过程不会超过 30 秒。mindset where it's all about code is a tool to solve problems and you can solve so many more problems. It's like before you wanted to benchmark something and you weren't quite sure where you were going to net out. It's like you can just do it. it's it's going to take you like no more than 30 seconds, you know, to launch something in the background and, you know, get proper numbers and be able to do like a better trade-off.

如果你真正关心结果以及系统能否良好运行，这会让你——或者说，应该会让你成为更优秀的工程师。因此，这使我们能够在 OpenAI 更高效地运行推理，也让我们能够获得更高效的计算资源，并将其部署到全世界。It makes you it should make you a better engineer if you just really care about, you know, the outcome and the system working well. And so what it allows us to do at OpenAI, it allows us to run, you know, our inference much more efficiently. It allows us to, you know, get like much more like effective compute and, you know, deploy that to the world.

所以大家都非常专注于此，以前所未有的速度解决重要问题。而且，到目前为止，我还没遇到过有人说：“哦，那不好，那一点都没意思。”我理解得对吗？听起来，如果你面对的是很有野心的问题，或者问题远远超出了你今天、明天乃至下周所能解决的范围，那似乎并不是什么真正的问题，因为当你在某个方面变得更高效时，就会继续推进。很多初创公司不都是这样吗？初创公司的目标总是比它们实际能够做到的要有野心得多。And so like everyone's just like very focused on that and solving important problems at the speed that was not possible before. And like I haven't yet, you know, encountered someone who's like, "Oh, that's not that's not good. that's not fun." Do I understand correctly that it sounds like if you have ambitious problems, if you have way more problems than what you can solve today or tomorrow or the next week, sounds like this is not really a problem because when you know you get more efficient somewhere, you keep going. Which which is a lot of startups, right? like startups are always way more ambitious than than what they're able to do.

我不……我们肯定还没有摆脱所有问题，对吧？所以，而且我觉得在一段时间内我们都不会摆脱。就数学突破、科学突破、让世界变得更美好——比如真正为人类进行建设，解决每个人都在面对的最重要的问题，并且以一种非常非常人性化的方式去做——在这些方面，我们前面还有一条非常非常漫长的路要走。这就是我们来到这里的原因。还有，回到写代码以及你知道的这些熬夜上，我觉得这其中可能也有一种……也许可以说是比较光鲜的版本。I don't we're not we're not out of problems for sure, right? So, and and I don't think we will be for a while. we have a long long road ahead of us in terms of like mathematical breakthroughs, scientific breakthroughs, you know, making the world a better place like just really building for humans and solving the most important problems that everyone is is facing and just doing it in a a deeply human way. that's that's what we're here for. Also, just going back to coding and like you know these late nights, it's like I think there's like it's also like maybe like a glamorous version of it.

就像我也有过很多很多熬夜重构某些东西的时候。你知道，我可能已经埋头重构了三个小时，然后才意识到，其实这是一条死路，我必须从头再来，那真的非常令人沮丧。所以，这里面确实有一些非常非常有趣的时刻，但也有那种代码编译不过、你就会想“为什么到现在还编译不了？”的时刻。我敢肯定你也经历过这种时候：你后来发现已经特别晚了，你得上床睡觉，因为你需要好好睡一觉，可你就是睡不着，而且脑子里一直想着有个任务做到一半，这有时真的会让你很烦。我记得自己甚至还梦到过代码。Just like I also had very a lot of late nights where I was trying to refactor something. and you know just like I would be like three hours deep into the refactor and then realize like actually this is a dead end. and I must restart from scratch and it was like very frustrating., and so it's like there was like there are like these very very fun times, but there's also the time where it's like it doesn't compile and you're just like, why is this not compiling yet? Like I'm sure you had the time where you you go you go later, it's now super late, you need to go to bed cuz you need to you need to get some sleep and then you can't really sleep and you have this thing where like you you have some some task that is halfway and it upsets you sometimes. I remember dreaming about the code as well.

我想，如今在为自己的业务开发软件时，我确实不太会遇到那种做到一半的情况，因为我可以直接告诉它去做某件事，然后把它留在一种——你知道——基本算是完成的状态：要么已经完成、能够正常运行，要么我有证据证明它失败了。不过这挺有意思的，因为你知道，一切都加速了，对吧？对。And I guess one thing I don't really have these days when I'm working on my software for my business is I don't really have something that is halfway cuz I can just tell it do this and then I can leave it at a state where it's kind of like you know done either finished it's either working or it's I have proof that it's failed. But it's interesting because you know everything's sped up right. Yeah.

我可能，嗯，就像很多人会做的那样——我自己也会这样——有时候会问自己一些更大的问题。比如，我会想到白天进行过的一些对话，或者有些事情我还没来得及抽时间去了解。所以我会把 codecs 发出去，让它在夜里帮我看看，然后我就特别期待第二天早上醒来查看结果。因此，每天早晨总是令人兴奋。嗯，我觉得，处理长时间运行的任务是有技巧的。当然，你可以使用 /goal，它会去运行。I may maybe like I do have like what what a lot of people do and I do myself is like you know I have like sometimes like bigger questions that I'm asking myself like and I you know from conversations I've had during the day or like I haven't yet you know just like had the time to just look into it and so I you know I will send off codecs to just like look at it overnight and then I'm very excited to then wake up and look at the results and so you know it's always like an exciting morning. Well, I feel there's an art to doing longunning tasks. And of course, you can use the slashgoal which will go and and and run.

你知道，那也是最近才添加的功能，大概就在几个月前，对吧？向 codeex 发送的 /go goal 命令。对。You know, that's also something that was recently added like a few months ago, right? The /go goal command to codeex. Yeah.

回到刚才的话题，你知道，也许这个 harness 就像一根拐杖，对吧？它的目标就是让模型在很长一段时间内始终围绕一个单一目标运行，这是必要的。这样一来，如果问题真的非常非常难，它实际上可以连续运行数天甚至数周。And back to, you know, maybe like the harness is a crutch, right? Is slash goal was like necessary to allow like no to keep the model like on track on like a singular goal for a very long period of time. And it's like it allows the model to literally run for days or or weeks if it's like a really really hard problem.

不过，随着我们现在看到的这一代新模型出现，你知道，你已经不再需要 SL goal 了。你也不需要在它周围套一个 harness。你只要告诉模型，比如说：“去工作一周吧”，你知道，它实际上就会照做。But with the new generation of models like what we're seeing is like you know you don't [clears throat] need SL goal anymore. You don't need a harness around it. You can just tell the model like you know hey go and work for a week and you know it will actually do it.

说到棘手的问题，以及你还没有摆脱这些问题这一事实。有一件从外部来看你们发布的、我想说作为一名工程师觉得中等有趣的事情，就是你们所谓的合并——也就是 Codex 出现在 ChatGPT 里面。之所以说它对工程师而言只是中等有趣，是因为我们一直在使用 Codex；没错，现在你可以在 ChatGPT 应用中打开它了，很棒。但我刚才一进去就直接打开了 Codex，因为严格来说我并不怎么在应用里使用 ChatGPT。不过，我和 OpenAI 的一些人以及你们团队里的人聊过，他们告诉我，背后进行了大量准备工作，也面临了很多工程挑战。你能否介绍一下这个项目的规模有多大、需要完成哪些工作，以及为什么实现起来很困难？另外，Codex 和其他工具是如何帮助你们完成这件事的——在过去，这些事情为什么会更难做到？因为自从你们推出这次合并以来，你们一直分享的 Codex 使用人数数据增长得非常快，远远快于之前。Speaking of hard problems and the fact that you're not out of them. One of the interesting things that you shipped from the outside it I would say it it was you know as an engineer it was moderately interesting is the what you call the merge which is codeex appeared inside of chat GPC and the reason I say that as engineers it's kind of moderately interesting because we've been using codeex like yeah it's there you can now open it in the chat GPT app great like I just went there and I just immediately went to Codex cuz I don't I don't really use Chad GBT in the app per se but I talk with folks at Open AAI and people in your team and you know they were telling me like there was a lot of preparation going on a lot of engineering challenges. Can you give a sense of how big this project was, what you needed to do and why was it difficult to pull off and and how you know how did codeex and other tools help you get it done in in ways that would have been hard before cuz since you've launched the merge the numbers that you keep sharing of how many people use codeex it's like it's going up way faster than before.

所以我想，我想你们在这里解决了一个大规模问题。合并过程中有很多具有挑战性的事情，首先就是技术栈完全不同。Chbt 是一种完全托管的云端服务，也就是说，你们的一切都运行在我们自己的系统上。So I assume I assume there's a big scale problem you've solved here. A lot of things were the challenging with the merge is first of all completely different stacks. Chbt is like fully managed cloud-based like you know you run everything on our on our systems.

我们以传统的方式来存储和构建东西，按规模构建，按效率构建。Codex 完全在本地运行。所以，合并的关键其实就是：如何从这个本地编码代理中获得同样的收益和同样的能力，然后围绕它构建一个产品，并以一种能够惠及更广泛人群的方式来构建它。这也正是我们所有人加入 OpenAI 的原因——让全球非常广泛的人群都能从中受益。 所以，这是一段非常令人兴奋的旅程：弄清楚如何构建一个云端版本，本质上能够完成几乎完全相同的事情，但同时又以一种能够服务数千万乃至数亿用户的方式来构建，并且仍然保持高效，这样我们就能把它一直纳入 Plus 计划中。 它的工作方式本质上是在云端运行完整的 codeex harness，同时配备一台云端计算机。这实际上是一台非常强大的机器。人们也逐渐发现并展示了它的能力：如果你能创造性地设计提示词，就可以让 chatbt 在里面训练另一个模型。哇（笑）。还有一些相当疯狂的事情：你可以让它安装 Blender，然后进行 3D 建模。它的权限非常宽松，可以访问互联网，是一台强大的机器，而 Codex 在上面就能直接运行。这就是我们通过 cas work 发布的内容。还有很多系统层面的挑战。We we store things like traditional traditional way of like building things. built for scale, built for for efficiency. Codex fully local. And so the merge is just really like how do you get the same the same benefits and the same capabilities from this local coding agent and then build a product around it and build it in a way where it can benefit like a much much broader pool of people which is which is also why you know all of us joined OpenAI is like to benefit like this very very broad population across the world and so it was like a very exciting journey of like figuring out like how do we build a cloud version of this that in essence is capable of like very very much the same things but is also built in a way where you know we can serve it to like tens and hundred millions of hundreds of millions of users in a way that is still like you know efficient so that we can include it all the way into the plus plan work is essentially like running the full codeex harness in a cloud like together with like a a cloud computer it's It's a very powerful machine actually like people have sort of picked up on it and showed like you know what you can do like you know if if you are creative with the prompt is that you know you can get you can get chatbt to like you know train another model in there you know wow [laughter] there are some pretty wild things you know you can get it to install blender and you know do like 3D modeling it's like very permissive it has like internet access it's like a powerful machine and then codex just works on it and this is like what we ship through cas work. a lot of system challenges.

我们团队非常快地完成了这件事。显然，Codex 帮助我们——你知道——让它变得更高效，去查看并构建大量基础设施，然后你知道，也帮助解决了很多一直存在于 Codex 和 CHBT 之间的小差异，比如合并插件架构、合并库之类的，所以确实——真的真的很有效。We the team did it very quickly. Obviously like Codex helped you know to make it more efficient look at and and build a lot of the infrastructure and then you know help resolve a lot of the little differences as well that you know had been occurring between between Codex and CHBT like merging plugins architecture you know merging library and like so like really really working

领导力与软件开发的未来Leadership and the Future of Software Development

朝着一个统一系统发展，这才是真正的目标。你不应该觉得，自己在 Codex 里能做某件事，却在 TAB 里做不了，反之亦然。我们想构建的是一个统一的产品，让你能够使用同样的智能，只是采用你自己想要的方式。 所以这也非常有趣，因为在整个过程中，Codex 还充当了一名记者，记录了所有步骤，以及团队之间的争论和讨论。关于我们应该如何实现、应该如何命名这套东西、应该在什么时候以什么方式推出，以及应该把什么合并到什么里面，大家展开了非常热烈的讨论。我们考虑过许多不同的组合方案，因此其中还有一个非常有趣的新闻记录元素：我们有一份完整的记录，是 Codex 随着时间推移整理出来的。 这件事后来也逐渐被称为 OpenAI 的“切换开关篇章”。当时我们推出了“工作”切换开关，围绕它也有很多争论，比如这是否是正确的做法。后来我们逐渐真的喜欢上了它。不过，随着时间推移，我们还会进一步合并这些东西。towards like unified system which is really the goal is like you shouldn't feel like you know you can do something in Codex that you can't do in TAB or vice versa like what we're trying to build is like one unified product that gives you access to the same intelligence but in the way that you want to use it. And so it was very fun as well because Codex throughout the whole journey also acted as a journalist to sort of like document all the steps and the debates and the discussions that the teams were having. And it was very animated debate you know of how we should do it and how we should name the thing and you know when to introduce it in what way and like what to merge into what. there were like many different permutations considered and so there's like a very fun journalistic element to it where we like we have a full recounting that Codex did over time and yeah it's just it's kind of become known as well as like the toggle arc of OpenAI where you know we introduced like the work toggle which there was also a lot of debate around of like you know whether this was like the right thing and then you know just like we kind of grew to to just really like it but over time we're going to merge things further.

所以，我们确实是在朝着全面统一的方向发展。你知道，我们有点把目前看作一种临时状态：当你处于工作模式时，你会拥有更好、更强的能力；但随着时间推移，我们会把这一点逐步扩展到所有使用 CHP 的人身上。那你个人是怎么使用 codeex 的？比如说，从代理、任务这些方面来看，你的工作配置是什么样的？你会用它来管理哪些事情？So it's like we're really headed into this direction of like full unification and you know we kind of view this as like a temporary state where you know you have like you have better stronger capabilities when you're in work mode but over time we're bringing this you know all all the way to like you know everyone that uses CHP. And how do you personally use codeex? Like what's your what's what's your working setup in terms of agents, in terms of task, in terms of what you what what you manage with it.

此外，关于这个问题，我问了 Peter Stainberger 我应该问你些什么，他说，像你这样的情况，你需要问他：你是如何应对自己参与所有这些项目这一事实的？你的日历简直就像俄罗斯方块一样，但通常你出现时都相当愉快。我日历安排得还好。只是如今我能做更多事情，因为我拥有像 CEX 这样的技术，而且我实际上把很多工作转移到了移动设备上，使用平板电脑办公。每当我有需要记下来的事情时，我就直接把它发送出去。我经常使用听写功能。每当我有一个问题时，我不会把它写下来，想着以后再查，或者委派给别人，而是直接把它发出去，交给负责你工作的系统，然后我就会收到一份报告。And related to this, I asked Peter Stainberger what I should ask about you and he said like you I you need to ask him how do you deal with the fact that you're involved in all these projects? your calendar is like Tetris, but usually you show up pretty cheerful. My calendar is fine. and it's just I am capable of doing so many more things nowadays because I have the technology like CEX and I actually shifted a lot of like my my my work on on mobile using tab work where whenever I have something that I want to take note of I just like fire that off. I use dictation a lot., whenever I have a question, instead of like writing it down to look into later or delegating to someone, I just like fire it off in charge of your work and I get like a report.

它有一大堆自定义技能和自定义指令，现在已经非常非常贴合我的需求，可以按照我能够有效消化的风格来生成各种报告、幻灯片演示文稿和代码探索内容。所以每次我在会议间隙，或者你知道，你会看到我——我刚才还在对着手机口述。正如我之前所说的，我们确实有很多工作是在公开频道中完成的。It has like a whole bunch of like custom skills and custom instructions where it's now like very very tailored to like you know produce the kinds of reports and slide decks and code explorations you know in the style that I can consume effectively. And so every time I'm like between meetings or like you know you'll kind of like see me like you know I was just like dictating to my phone. As I said before it's just like we do a lot of work in public channels.

我们在 Slack 里有很多内容，在 Notion 和 Google Docs 里也有很多。所以基本上，我觉得几乎没有什么问题是我不敢问的，因为我知道 Codex 至少能够先进行一轮思考：比如分析大家对某个功能的公开反馈，查看生产日志以了解某项功能的使用量，列出一些应该弃用的东西，因为它们没有获得关注，或者了解某个团队正在做什么。We have like a lot in Slack. We have a lot in in in notion and Google Docs as well. And so there's pretty much like there's no question really that I feel I cannot ask that you know Codex will be able to sort of like do at least a first pass of thinking through whether it is like public sentiment on a feature looking at production logs for you know how much usage we have on a certain thing making a list of things that we should deprecate because they're not getting traction understanding what a certain team is up to.

这就像我提出的任何问题，都能在大约 30 分钟内得到答案。我的使用方式就是这样。我什么事情都用它。It's like any question I have I can get an answer to like you know within 30 minutes. And so that's how I use it. I use it for everything.

它就像是我在方方面面的私人代理。然后通常在周末，我也会做一些代码探索，或者构建一些原型，以某种方式享受畅想产品未来的乐趣。我会和团队中的其他人一起做这些事情。It's like my personal agent in in like all the ways. And then oftentimes on on weekends as well, I do some like code explorations or like I build some prototypes and I have fun like sort of like imagining the future of the product in some ways. And I do that with others on on on on the teams.

不一定总是同一个团队。而且情况就像是，有时候我一天之内就能构建出一些东西，感觉就像它原本已经在我的系统里一样，对吧？就好像某天我醒来，突然觉得我们应该探索一下构建这个东西意味着什么，然后我就能把这些想法表达出来，并在一天之内把类似的成果呈现在人们面前，让他们思考一番、提出批评，并希望能从中获得启发。It's not always the same team. And it's just like in one day I can build things that I sort of like I had it in my system, right? It's like it's like I woke up one day I was just like we should explore what it means to build this and then I can just sort of express all of that and get like something in front of people in a day so that they can think through it and criticize it and hopefully get inspired by it.

这并不是说我们无论如何都需要把它发布出去，而更像是：好吧，我把它从我的系统里清理出去，然后你知道，我继续去做其他事情。所以，这真的是一个如此神奇的时刻，也让人感到非常有力量。最后，作为结束语，对于一名软件工程师、AI 工程师，或者任何构建软件的人来说，如果他想获得相应的技能和经验，从而有机会在像 Codeex 团队、OpenAI 或 AI 初创公司这样的地方工作，你有什么建议？It's like by no means you know we need to ship it but it's more like okay I flush it out of my system and then you know I go on and like you know do other things. So it's just like so I know it's such a magical time and it's like so empowering. And as closing, what would your advice be for a software engineer/ AAI engineer, someone who builds software who would want to get the skill set and the experience to have the opportunity to work at a place like the Codeex team, like OpenAI or like an AI startup.

所以，你知道，利用这些工具真正成为一名出色的构建者，因为人们经常会问这样的问题：我应该从理论开始吗？基础知识有多重要？我是不是只要把工具用得特别熟练就行了？So like you know just become this really great builder with with these tools because the question that comes up is often like should I start with the theory? How important are the basics? Should I just get really good at using the tools?

是的。我觉得有两点很重要：一是对事物如何运作抱有非常非常强的好奇心，二是能够训练自己非常快地理解事物。所以，事情确实会不断变化，但那些在 OpenAI 做得非常出色的人，通常都是能够很快掌握一个系统，也能够深入了解一套新的代码库，并设法理清其运作方式的人。当然，如今有了智能体的帮助，所有这些都会容易一些，对吧？因为你需要吸收的信息实在太多了，而能够理解这些信息、对其进行推理，其中很大一部分就是提出好的问题，真正去弄清楚事情是如何运作的，并且不断追问“谁、什么、何时、何地、为什么、如何”这五个 W。我觉得你只要这样不断深入、不断追问，就能非常非常快地学会很多东西。Yeah. I think there are two things that are important is a deep deep curiosity for how things work and an ability to like you know train yourself to understand things very quickly and so it's it's it is the case that things will continue to change but people that do extremely well at OpenAI are like you know people that just sort of like are able to like gro a system quickly and like you know also dive into like a new code base and sort of like know make sense of it. but obviously like all of that is helped with agents nowadays, right? So just like there's so much information that you need to absorb and like you know being able to understand and reason through it and a lot of that is asking good questions really about you know how do things work and just like going into like the five W's which I think you know you can just kind of keep digging and digging and digging and you know you're learning very very fast through that.

另一件事是与社区保持同步，也就是了解你试图帮助解决问题的那些人。并不是所有事情都是在解决一个直接的问题。有时，你解决的问题可能会对另一群人有用——他们正在努力解决人类面临的问题。The other thing is being in tune with the community or you know the people that you're trying to solve a problem for. It's like not everything is like solving a direct problem. Sometimes you're solving a problem that will be useful, you know, to like another group of people in the pursuit of like solving a problem for humans.

但仅仅是清楚地表达品味、需求或要求，并且能够清晰地思考——比如说，你知道，通过这种清晰的思考来锻炼自己——对我来说真的非常重要。因为如果你无法解释自己想要实现什么，无法解释自己的意图，没有与某个社群的联系，也没有品味，那么要做出优秀的成果就会困难得多。太棒了，TB。But just being crisp about the taste or the needs or the requirements and being able to think clearly and like you know exercising through this clarity of thought feels really important to me. Like if you can't explain what you're trying to achieve, if you can't explain your intent, if you don't have a tie to a community, if you don't have the taste, it's it's it's going to be much harder to do great work. Awesome, TB.

嗯，非常感谢这次谈话。真的很棒。谢谢你邀请我来。Well, thanks a bunch for this conversation. This was awesome. Thanks for having me.

我一直想和 Tibo 聚一聚，很高兴我们最终实现了这一愿望。我很欣赏 Tibo 不仅谈到了开源的优势，也谈到了它的弊端。最值得注意的是，竞争对手可能会复制你此刻正在公开开发的功能，然后在发布前抢先推出，以及这会让人感到多么难受。此外，你还会收到大量低质量的贡献，仍然需要想办法处理它们。I've always wanted to get together with Tibo, and I'm glad that we finally made it happen. I appreciated how Tibo talked about not just the upsides of open source, but also the downsides. most notably how competitors can copy features you are just working on in the open right now and then ship it right before release and just how much this stings. Plus, you get a lot of low-quality contributions that you still need to somehow deal with.

另一个有趣的观点是，Tibo 提到，工具框架总是领先模型一步。从内部来看，Codex 团队认为，他们的工作是通过工具框架、工具和设置说明，为模型搭建辅助支架。然后，模型的下一个版本将经过训练，逐渐减少对这些辅助支架的需求。Another interesting one was Tibo was saying how the harness is always a step ahead of the model. From the inside, the Codex team see their job as building clutches for the model with the harness, the tools, and the setup instruction. And then the next version of the model will be trained to need fewer of these clutches.

老实说，作为一名开发者，一想到我在模型下一版本中构建的东西，它只要自己知道了，我们就可以把这些东西去掉，这听起来多少有点打击积极性。另外，我确实怀疑，这不仅仅是构建这些“拐杖”，还包括构建模型将要使用的工具。而且，模型的下一版本也不可能凭空重新发明一套 MCB 协议、扩展机制或插件。I'll be honest, as a dev, this sounds a little demotivating that the stuff I build in the next version of the model, it'll just know and we can get rid of it. Plus, I do suspect that it's not just about building these clutches, but also building tools that models will use. And it's not like the next version of the model will reinvent an MCB protocol or scales or plugins.

至少我希望不是这样。我也很喜欢听到 merge merging chat GPC 和 codeex 的合并从内部来看是什么样的。这个过程是将此前完全本地运行的编码代理 Codeex 合并到受管理的云端技术栈中，并且做到足够高效，从而可以纳入 OpenAX 每月 20 美元的套餐，而 20 美元就计算资源采购而言其实并不算多。At least I hope not. I also enjoyed hearing what the merge merging chat GPC and codeex look like from the inside. It was merging a previously fully local coding agent, Codeex, into a managed cloud-based stack and doing it efficient enough so that it can be included in OpenAX $20 per month plan when $20 is not all that much in terms of compute purchase.

听到 CODC 本身如何充当整个项目的记者还挺有意思的：它参与了所有 Slack 对话，也查看了所有文档，因此能够捕捉到所有重要的讨论和决策。我不想撒谎，这部分让我有点感到“大哥在监视”的意味，仿佛 AI 始终在注视着一切，但这很可能会成为未来初创公司的新常态。我还没决定自己对此作何感想。It was pretty amusing to hear how CODC itself acted as a journalist of the whole project as it was present in all the Slack conversations and all the documents and so it could capture all the important debates and decisions. I'm not going to lie, this part felt a little bit of a big brother feel to it where the AI is always watching, but it could well become the new normal in startups in the future. I've not yet decided how I feel about this.

最后，我很认同 Tibo 关于工程师如何取得成功的建议：保持好奇心，迅速理解问题表象，并与所服务的团队保持同步。听到 Tibo 也强调基础知识仍然如此重要，令人倍感安心。And finally, I appreciated Tibo's advice for engineers to succeed. Be curious, understand symptoms quickly, and be in tune with the group you are building for. It's reassuring to hear from Tibo as well how much the fundamentals still matter.

请务必查看下方的节目说明，深入了解编解码器、时钟代码和光标的构建过程，以及其他相关主题。如果你喜欢所听到的内容，请在你使用的播客播放器上给节目点个评分。这对我和节目来说意义重大。Do check out the show notes below for deep dives on how codecs, clock code, and cursor were built and other related topics. If you like what you heard, please hit a rating on a podcast player that you're using. It means a lot to me and to the show.

谢谢，我们下期再见。Thanks, and I'll see you in the next