“未来某个时间点,我们或许会为智能体(Agent)构建软件。届时,智能体可能会扮演产品经理或产品工程师的角色。”
在近期举行的 Pragmatic Summit 上,OpenAI Codex 工程主管 Tibo Sottiaux 与 OpenAI 应用首席技术官 Vijaye Raji 分享了 OpenAI 内部工程师使用 AI 进行开发的真实体验与观察。
回顾过去一年,Tibo 用“震撼”来形容其变化程度。
仅看最近六个月,我们的认知已从‘将 Codex 视为工具’,演进到‘将其视为扩展’,再到‘将其视为智能体’,如今已发展到‘将其视为队友’。
甚至有工程师每周消耗上千亿 Token,来运行多个智能体。
随着 Codex 能力不断增强,软件开发的瓶颈正以“周”为单位发生转移:早期的瓶颈是代码生成,随后变为代码评审,而现在更多集中在如何更快理解用户需求、处理 Issue、追踪 Twitter 与 Reddit 等重要平台的反馈,并将这些信息综合为产品策略。
Tibo 透露,OpenAI 内部一些工程师每周消耗的 Token 数量已达数千亿级别,且这通常涉及多个智能体协同工作。
此外,团队内部已开始使用一款更为超前的开发工具:Codex Box。
我们上周内部发布了 Codex Box。它允许在服务器上预留开发环境,直接通过自然语言指令(prompt)驱动其执行任务。你可以在笔记本电脑上编排工作流程,而它在云端完成任务。不少人关上电脑去开会,回来时工作已经完成。
例如,Codex 团队在开会讨论产品时,会直接在会议室中发起一个 Codex 会话线程,用于实时诊断问题与复盘分析。
谈及未来软件开发行业的变化,Tibo 和 Raji 指出了几个方向:
- 开发速度再提升一个数量级:这将引发新一轮的工作流变革。
- 实现大规模多智能体协作网络:让智能体围绕更宏大的目标进行协同工作。
- 为系统构建“护栏”:开发者的关注点将从逐行审查代码,转向通过约束与验证来确保系统的正确性与安全性。代码本身将被抽象,焦点回归问题本质与系统应具备的特性。
- 出现“个人代表型助手”:Raji 预测,或许就在今年,开发者将拥有一个专属助手,用于汇总并监控一两百个为其工作的后台智能体的状态,无需再逐一查看。
主持人还提到,OpenAI 倾向于招募产品型工程师。Raji 解释说,产品直觉依然至关重要,因为本质上产品仍是为人而构建的。
对于希望在 AI 时代进入软件行业的新人,Tibo 和 Raji 强调:基础能力永远不会过时。OpenAI 并不会完全盲目依赖 Codex。扎实的工程基础、产品直觉、清晰的目标意识以及在技术栈中上下游解决问题的能力,才是关键所在。
“我们能坐在这里,正是因为我们有扎实的基础。但软件工程师的角色,确实已经发生了巨大的变化!”
以下是 Codex 团队视角下的“开发方式演进”概述。
OpenAI 内部开发方式的转变:Codex 已成为队友
部分工程师每周消耗的 Token 数量高达千亿级别。
主持人:有一个被频繁提及的问题:OpenAI 内部究竟发生了什么?更具体地说,从软件开发角度看,工程师的工作方式发生了怎样的变化?
Raji:变化确实巨大。我在 OpenAI 大约六个月,一个深刻的感受是公司内部的研究能力极强。只需稍稍展望那些可能性,就会感到震撼。
以软件开发方式为例。Codex 彻底改变了我们编写代码的模式,且变化非常剧烈。仅最近六个月,我们的认知就从“工具”到“扩展”,再到“智能体”,现已进入“队友”阶段。我甚至觉得工程师很快会给自己的智能体起名字,将其视为真正的搭档。这种演进速度极快。
我见过内部数据,有些工程师每周消耗的 Token 达数千亿,且这通常不是单个智能体完成的。我们上周内部发布的 Codex Box,允许在服务器预留环境,通过指令驱动任务。你在笔记本编排流程,它在云端执行。很多人合上电脑去开会,回来时工作已完成。
这就是 OpenAI 内部当前的软件开发方式,它已发生根本性改变。我相信几个月内,硅谷将率先普及,进而扩散。未来大家都会这样开发软件。
主持人:如果在六个月或一年前听到这些,我可能会觉得像童话。但现在不同了,很多人已在实践。我自己也在用,并与 OpenAI 的工程师交流过。我喜欢和工程师聊,因为他们通常直言不讳。
令我稍感安心的是,并非所有工程师都 100% 依赖 Codex 写代码。使用程度各有不同,但有一个团队走在前沿:那就是 Codex 团队本身。
Tibo,你领导 Codex 团队。能否谈谈你们现在每日如何工作?工程师的典型工作流是怎样的?
Codex 团队的工作方式每周都在快速演进
Tibo:变化确实非常快。Codex 团队有一个显著特点:我们几乎每周都在重塑自己的工作方式。
我们会持续识别瓶颈,而瓶颈本身也在不断转移。最初是代码生成,后来是代码评审,现在则更多是:如何更快理解用户需求?如何处理 Issue?如何跟踪 Twitter、Reddit 等平台的反馈并将其综合为产品策略?
团队正在尝试最大化利用智能体来处理这些任务。
前几天有个有趣的插曲,一位有意加入 Codex 团队的候选人问我:“在 OpenAI 做产品,我能分配到多少算力?”
这是个新问题。我们确实拥有可观的算力,但我从未思考过“每位员工的算力配额”。通常,算力更多分配给训练大模型的研究人员。
现在大家意识到,你可以利用算力将自己的能力放大数倍。如果你具备良好的品味、清晰的思路并懂得软件开发,那么这个时代令人无比兴奋。你能实现的事情确实惊人。
智能体或将扮演产品工程师角色
主持人:从更宏观的视角看,OpenAI 一直招聘“产品型工程师”。他们的工作发生了哪些变化?
Raji:本质上,我们仍在为人类构建产品。因此,产品直觉依然至关重要。我最近在使用新版 Codex 桌面应用,它让编码变得更简单。但产品开发依然始于“我们要构建什么”,并持续迭代优化。
只要软件仍是为人类而做,这一点就不会改变。
当然,未来某个时刻,我们或许会转向为智能体构建软件。那时,智能体可能会承担产品经理或产品工程师的职责。
不过,当前的节奏更快,也更有趣。构建软件变得更令人愉悦,因为反馈周期大幅缩短。
我有一次在飞机上编码,当时无法使用远程开发环境。空乘要求关闭电脑,我甚至舍不得,因为不想中断智能体的工作,只能将电脑半合着继续运行。(笑)现在许多人都会让电脑在合盖状态下执行任务。
坦白说,现在的软件开发比以往更有趣。你能快速看到成果,进行测试验证,然后回到 Codex 进行调整。
新兴工程实践:并行探索方案、设计师参与编码;代码评审成为新瓶颈
主持人:在工程实践方面,有哪些新的、看似奇特却合乎逻辑的变化?
Tibo:以前面对复杂的技术权衡时,我们会撰写设计文档,讨论各种方案,然后选择其一。
现在有趣之处在于,团队会并行探索多个实现方案,然后通过实验数据选择最优解。
另一个变化是角色边界变得模糊。设计师现在编写的代码,可能比六个月前工程师写的还要多。这是因为模型生成的代码质量已经足够好,可以直接合并。
主持人:还有其他观察吗?

Raji: 有的。比如命令行工具。像 ffmpeg 这种工具,几乎没人能记住完整命令。现在用 Codex,你只要描述“我要做这个”,它就能帮你生成正确的命令并执行。
我们的应用范围已经从单纯的“写代码”,扩展到了“代码评审”和“安全审查”。
当编码效率提升五倍之后会发生什么?代码量会暴增,代码评审会成为新的瓶颈。再往后,持续集成与部署(CI/CD)又会成为下一个瓶颈。
瓶颈在不断迁移。这场变革还远未结束。
Tibo: 所以我们必须不断去解决下一批问题。这其实非常令人兴奋。
主持人: Tibo,我们之前聊到一个我从没听说过的做法——“通宵运行”和“自我测试”。能讲讲吗?这听起来很新颖。
Codex的通宵运行与自我测试
Tibo: 人们很容易把 Codex 理解成“超级自动补全”,认为它只是帮你实现一个小功能,10分钟搞定。
但我们看到的是,只要给模型一个足够宏大的任务,它的能力远不止于此。它可以连续运行好几个小时。
我们为 Codex 搭建了完整的环境和能力,让它能够完全自主地测试自己。我们会在夜间运行它,让它循环执行质量保证(QA)流程,自动检测回归问题。
还有件事挺有意思。我常和团队里负责训练模型的研究员聊天。他说,每次他觉得自己比 Codex 更厉害时,最后都会发现是自己提示词没写好,或者环境没配置对。
这既令人兴奋,也有点打击人。(笑)
现在它甚至可以独立完成一次完整的模型训练,最后生成一份带有自己洞察的 PDF 报告。我们再从中挑出最有前景的方向继续迭代,然后再丢回给 Codex。
这种超长时间运行的任务,以及模型独立完成复杂工作的能力,看起来真的很震撼。
会议中“召唤”Codex的两个场景
复盘与故障处理
主持人: 还有一个很科幻的场景。你说 Codex 团队在开会讨论 Codex 时,会直接在会议室里发起 Codex 线程来诊断问题。这听起来像一种自我循环。能详细说说吗?
Tibo: 我们有两个典型场景。
第一是每周的分析复盘会议。我们会看功能采用率、留存率、转化漏斗。会议开始时,大家总会有一些仪表盘里看不到的疑问。
数据分析师会说:“好,我们在后台开一个 Codex 线程,20分钟后给出答案。”
会议最后10分钟,我们就能讨论这些新结果。一个会议里可能并行跑五六个问题。感觉像是有一群隐形的顾问在后台为我们工作。
第二个场景是线上故障处理。Codex 会帮助我们分析问题根因,找出最快的恢复路径。信息收集和问题解决的速度都被大幅提升了。
关于应届生与初级工程师
主持人: 行业内一个反复出现的问题是:应届生怎么办?初级工程师怎么办?我听 OpenAI 的工程负责人说,你们在大量招聘早期工程师。情况如何?
Raji: 我们确实在招聘很多应届生。今年还有一个规模不小的实习项目。
我相信新一代软件工程师将是“AI 原生”的。他们会天然熟悉这些工具,从第一天起就能使用 AI。为他们提供这样的环境至关重要。
今年夏天我们会迎来第一批大规模应届生,大约100人左右。我很期待看到他们的表现。实习项目也会持续扩张。
这是一个非常有意思的时代。
Codex团队如何带新人?
扁平管理,Codex是第一位导师
主持人: Tibo,你们团队本身比公司其他团队还领先几步。新人加入时,怎么快速上手?
Tibo: 我的团队结构非常扁平。我有33个直接汇报对象。我不想成为瓶颈。
如果一个人需要参与每个决策,这种结构在现在的速度下是行不通的。
新人入职后,第一个“导师”其实是 Codex 本身。你可以直接问它问题,用它浏览代码库、理解项目、接收每日报告。
而真正负责 onboarding 和文化建设的,往往是最近刚入职的人。
说到应届生,我六个月前招了一个非常优秀的新人。他表现极其出色。一开始我有点惊讶。但后来我意识到,他有无限的精力和极快的学习能力。
说实话,我的脑子可能已经在走下坡路了,而他的大脑正处在巅峰状态。(笑)他在团队里取得的成功让我非常开心。
给新人的建议:基础永不过时
主持人: 站在“唱反调”的角度看,过去我们看到很多应届生成长为优秀工程师,是因为打下了坚实的基础。
现在如果新人一开始就大量依赖 AI,跳过了我们过去10到20年的训练过程,会不会缺乏基础?
Tibo: 基础依然非常重要。
我们非常重视代码库的整体架构设计,也非常重视代码评审。我们不会闭着眼睛完全依赖 Codex。有顶级工程师在把关。
只要代码结构设计合理,设置好护栏,新人会变得极其高效。关键在于你搭建什么样的环境,以及提前思考代码库未来如何演进。
软件工程师角色的演变
主持人: 如果现在有个新人问:“Raji,我每天具体要做什么?”软件工程师的日常和六到八个月前相比有什么变化?
Raji: 基础永远不会过时。我们能坐在这里,是因为我们有扎实的基础。但软件工程师这个角色,确实已经发生了很大的变化。
我可能暴露年龄了,在这个行业25年,我见过太多范式转移。我当年在 Microsoft 做开发者工具,写过 Visual Studio 的编辑器和语言服务。第一次看到 IntelliSense 的时候,那种感觉真的很酷——你敲一个点,所有选项自动弹出来。
主持人: 我那时候刚入行,身边的开发者还在说:“用 IntelliSense 的不算真正的程序员。”
Raji: 对。(笑)再往前可能还有人觉得,不写汇编就不算好工程师。后来是 C++,再后来抽象层越来越高。还记得当年大家抱怨 JavaScript 吗?
这些争论其实都不重要。只要你有扎实的基础,有产品直觉,知道自己在构建什么,能够在技术栈上下游自由穿梭去解决问题,这些能力才是关键。而且这永远不会过时。
产品经理与设计师:都在写代码
直接将设计推进到验证后的原型
主持人: 我们刚才主要在聊工程师。那产品经理和设计师呢?当工程师和他们都能更快构建功能时,他们的角色会怎么变化?会不会越来越趋同?
Raji: 只要我们还在为人类构建产品,就一定需要人类设计师和产品经理。产品感和设计感没有简单的替代品。
当然,他们也在进化,效率越来越高。产品经理在写代码,设计师也在写代码。他们把设计直接推进到原型阶段,验证之后再交给工程师。
产品经理也在用 Codex 做 PowerPoint,写 Excel 插件。效率提升发生在整个组织层面,不只是工程师。
内部的知识共享与“Show & Tell”
主持人: 你们在内部做了很多知识共享,比如 show and tell。是怎么想到的?机制是什么?有没有一些有趣的案例?
Tibo: 我们其实是在一边发现技术,一边和它一起进化。
和外界一样,我们也在探索:AI 到底能为组织做什么?对项目意味着什么?只要有一个方向看起来有效,我们就尽快发布给世界。
所以,我们真正“多看见一点未来”的时间窗口其实非常短。
在这种环境下,好点子必须快速在组织内扩散。我们有很活跃的 Slack 频道,比如 Codex 频道、hot tips 频道。也定期举办黑客松和 show and tell。
这是一个高度创造性的阶段,没有所谓唯一正确的用法,一切都在探索中。
我们 Codex 团队有一位非常优秀的产品经理,Alexander Emberos。他是整个团队唯一的产品经理,却把自己“超级放大”了。
前几天他组织了一次 bug bash,一个小时内让大家体验即将发布的功能。他让 Codex 收集反馈,生成 Notion 文档,再让 Codex 创建 bug 和功能改进任务到 Linear,分配给相关负责人,并自动跟进进展。
他用 AI 把自己变成了 10 倍甚至 50 倍效率的项目经理。
但关键在于,你不能让产品经理成为新的瓶颈。组织结构也要随之调整。
项目深度与成熟度
Raji: 我补充一个观察。在最近的内部演示日和黑客松中,一个明显的趋势是项目深度显著增加。
早期的演示可能只停留在展示“模型能做什么”的层面。而现在,许多演示项目已经处理了大量复杂的边界情况,其完成度之高,几乎达到了可直接作为产品使用的水平。整个生态的实践深度在持续、快速地提升。
关于成本与价值
主持人: 一个必须面对的现实是:OpenAI 内部享有近乎无限的推理额度,但外部世界仍受成本约束。订阅额度用完后需要额外付费,许多团队的探索因此受到预算限制。
对于受成本约束的团队,你们有什么建议?
Raji: 降低成本是我们持续努力的方向,目标是让强大的模型能力更易于获取。
但与此同时,我们的思维方式也需要转变。你现在拥有的,是一个可以 24/7 工作的 AI 队友。你可以像分配 Linear 或 Jira 任务一样向它提出需求,并期待它完成工作。
核心问题不应再是“这次调用花费了多少 Token”,而应是“你愿意为这个能创造价值的‘队友’支付多少薪酬”。如果每位工程师都能配备四五个这样的高效“队友”,从整体生产力提升的角度来衡量,成本结构就显得更为合理。
当然,前提是我们必须让这些智能体足够强大,真正配得上“队友”这个称号。
Tibo: 还可以从公司整体成本结构来审视。例如,进行市场调研、分析产品功能积压、筛选高性价比任务——这些过去可能需要一个工程师团队数周完成的工作,现在几乎可以零成本、瞬间完成。
并非每家公司都能提供无限的推理额度。但在现阶段过早进行严格限制,可能意味着错失探索最佳实践的机会,这也是一种风险。我们仍处于非常早期的阶段,许多人尚未学会如何利用这些工具来放大自身能力。
我的建议是:将充足的推理额度优先分配给公司里最具探索精神和创造力的优秀人才,让他们能够充分试验,找到将价值最大化的方法。
前所未有的变革速度
主持人: 一切变化得太快。回顾过去 25 年,是否有类似的时刻可以比拟?
Raji: 我从未见过这样的变革速度。
我经历过互联网泡沫、千禧年危机、移动革命和社交网络浪潮,但这一次完全不同。这一波变革正以巨大的规模发生,且速度极快,快得让一些增长曲线看起来都近乎“不合理”。因此,我确信我们正处在一个非常特殊、独一无二的历史时期。能亲历这个时代,本身就非常酷。
两年后的软件工程
主持人: 作为最后一个问题:基于你们所知的一切,请坦诚预测一下,两年后的软件工程和工程管理会是什么样子?
Raji: 显然,两年时间尺度太长了,甚至预测六个月后都充满挑战。不过,有几件事我比较有信心。
第一,我们的开发速度很可能再提升一个数量级,这将引发新一轮的范式变革。第二,我们将真正实现大规模的多智能体协作网络,让它们围绕极其宏大的目标协同工作。
例如,在现有工具能力的基础上,完全可以想象这样一个场景:你只需提出“从零开始重建一个浏览器”的指令,24 小时后就能获得一个可用的成品。那可能是一个由数百万行代码构成的复杂系统,其内部细节的复杂程度可能已超出人类直接理解的范围。
因此,我认为下一步的关键是,为我们构建的系统设立可靠的“护栏”。开发者将不再需要逐行审查代码,而是通过定义约束、验证性质或测试输出来确保系统的正确性与安全性。关注点将从具体的代码实现,彻底转向问题定义与系统应具备的行为特性。
软件发展史就是一部抽象层级不断提升的历史。我们一直在用更少的代码做更多的事,而当前,我们正处在一个抽象层级加速跃迁的拐点。
我也有一个担忧:任何足够复杂精密的系统都更难调试,我们往往只能通过外在症状来定位深层问题。几年后,软件系统将变得空前复杂,层层叠叠。届时,通过“症状”高效诊断问题的能力将变得至关重要,我们的工具也会极大地辅助这一过程。这将成为未来软件开发者需要掌握的一项核心能力。
Tibo: Raji 说得很好,我想补充一点对未来工作形态的想象。
我认为很快,你只需要与一个专属的“个人代表型助手”对话,就能掌握所有工作进展。这个助手将汇总并代表背后成百上千个为你高效工作的 AI 智能体的状态。你不再需要亲自监控或管理每一个细小的智能体。
这种形态可能会很快到来,甚至就在今年之内。
主持人: 非常感谢 Raji 和 Tibo,为我们揭示了 OpenAI 内部正在发生的变革以及你们的工作方式。感觉你们总是领先外界几周、几个月甚至更远。但这一切确实正在发生。同时也感谢你们对这个激动人心时代的展望。非常感谢。
Raji / Tibo: 谢谢。
关注“鲸栖”小程序,掌握最新AI资讯
本文来自网络搜集,不代表鲸林向海立场,如有侵权,联系删除。转载请注明出处:https://www.itsolotime.com/archives/23346
