OpenAI 的工程现场：代码写快以后，瓶颈去了哪里

原始视频：OpenAI: How AI is reshaping the craft of building software

The Pragmatic Engineer · 视频发布于 2026-02-23 · 全长 30 分 34 秒

活动与人物：The Pragmatic Summit，2026-02-11，旧金山。主持人为 Gergely Orosz；嘉宾为时任 Codex 工程负责人 Tibo Sottiaux，以及 OpenAI 应用业务首席技术官 Vijaye Raji。

资料核验：大会官网 · OpenAI 对 Vijaye Raji 职务的公告

字幕与时间说明：依据完整英文自动字幕整理，人名与职务对照官方资料核验。文中内部实践、招聘计划和未来预测均保留这次访谈的时间语境。

Codex 团队开每周数据分析会时，会先列出仪表盘没有回答的问题：某个功能的采用率为何变化，用户在哪一步离开，留存变化可能与什么有关。

按 Tibo Sottiaux 的描述，数据分析师会在会议进行时启动 Codex 任务，让智能体去查。一次可以同时处理 5 到 6 个问题，约 20 分钟后拿回结果，留到会议最后 10 分钟讨论。视频中的这个案例，呈现了 AI 对团队节奏的一种影响：问题提出与拿到分析结果，可以发生在同一场会议里。

这场对话围绕软件开发展开，却反复谈到写代码之外的工作。代码生成变快以后，团队仍然需要理解用户、比较方案、验证结果，并决定下一步做什么。等待会转移到这些环节。

瓶颈从代码生成，移向整条交付链

Tibo 说，Codex 团队几乎每周都在调整工作方式。他们持续找出最慢的一步：起初是代码生成，接着是代码审查，后来越来越多地转向理解用户需求、处理反馈，以及把不同渠道的信息整理成产品策略。这段讨论把提效问题放回了完整流程。

Raji 顺着这个逻辑往后推。代码产出增加，审查量也会增加；审查提速之后，集成、测试和部署又可能成为新的等待点。只盯着生成了多少代码，很容易漏掉产品真正交到用户手里之前的耗时。

工作环境也在跟着改变。Raji 提到，当时内部刚推出名为 Codex Box 的机制，工程师可以预留服务器上的开发环境，把任务发过去。笔记本合上、人员离开去开会，远端任务仍然继续。工程师需要分配任务、提供上下文，再回来检查结果。

这种做法有适用边界。主持人根据自己与 OpenAI 工程师的交流指出，公司内部的使用程度并不一致，仍有工程师没有让 Codex 生成全部代码。Codex 团队的经验，不能直接当作整个公司的统一工作状态。

并行试方案，夜里跑验证

过去遇到技术取舍，团队通常先写设计文档，讨论几条路线，再选择其中一条投入实现。Tibo 观察到的变化是，工程师开始让多个实现同时推进，通过实际结果比较优劣。并行探索让原先只能在讨论中推演的备选方案，也有机会被运行和检验。

更长的任务则需要配套环境。Codex 团队准备了执行环境和技能，使智能体能够自主测试自身。夜间任务会反复进行质量检查，标记新改动引起的功能退化。

能持续运行的智能体，需要一套让它看见结果、检查结果的条件。 这也是夜间测试案例与普通代码补全之间最直接的工作差别：任务结束时，团队需要知道软件是否正常运行。

Tibo 还转述了一位模型研究员的经历：Codex 可以执行训练任务，最后生成一份包含发现与分析的 PDF 报告。研究人员再挑选有希望的方向，交给它继续迭代。这里描述的是研究流程中的长任务协作，仍然包含人对实验方向和结果的判断。

Raji 提到的另一个例子更日常：用 Codex 生成并执行 FFmpeg 命令，处理视频文件。连同数据查询和故障调查，这些案例都说明，团队开始把可执行的工作过程交给智能体，而任务的价值取决于结果能否被检查和使用。

产品经理和设计师，也进入执行环节

Raji 认为，只要产品仍然服务于人，产品判断和设计判断就仍然重要。改变的是验证想法的路径：设计师和产品经理可以先做出可运行的原型，试过之后再与工程师讨论。

Tibo 分享了团队当时唯一一位产品经理的工作方式。一次持续约 1 小时的集中找问题活动结束后，这位产品经理让 Codex 收集反馈，汇总进 Notion，再把缺陷和功能改进整理成 Linear 任务，分配给对应人员，并跟进进度。

这里减少的工作包括收集信息、整理条目、转交任务和追问状态。产品经理仍然需要判断问题是否重要、修复是否符合目标。代码生成已经加速，协调流程也需要跟上，否则等待会集中到负责协调的人身上。

新方法如何在团队里扩散，同样需要安排。OpenAI 内部通过活跃的 Slack 交流频道、技巧分享、黑客松和成果演示，把有效的用法传给其他人。Raji 观察到，内部演示逐渐包含更多边界情况处理，成品也越来越完整。

Tibo 同时承认，团队也在边用边探索，并没有一套已经定型的最佳做法。组织需要让经验流动，也需要为下一次调整留下空间。

新人仍然需要基础，只是学习环境变了

谈到初级工程师时，Raji 给出的回答很具体：OpenAI 当时仍在招聘应届毕业生，并计划在 2026 年夏季迎来约 100 名新人，同时继续扩大实习项目。这是访谈时的招聘计划，不能据此确认后续实际入职人数。

他看重新一代工程师从学习之初就接触 AI 工具的机会。Tibo 则把重点放在团队提供的环境上：新人可以向 Codex 询问代码库结构、了解其他人的工作、阅读日常报告；最近刚入职的同事，也会参与传授团队的协作习惯。

但两人都没有把基础能力从要求中删去。Tibo 明确提到整体架构、代码库设计、代码审查和必要的约束。资深工程师仍然需要参与这些工作，新人则在结构清晰的环境中吸收经验。

AI 可以帮助新人更快完成任务，工程基础决定了他们能否理解结果、发现问题，并对改动负责。 Raji 强调的能力包括产品直觉，以及沿着技术栈向上或向下定位问题。

管理结构也要适应执行速度。Tibo 当时有 33 位直接汇报者，他希望避免所有决定都排队等自己处理。这个数字反映的是特定团队的组织选择；更普遍的问题是，负责人能否让决策跟上成员完成工作的速度。

算力预算，要连着完成的工作一起看

成本讨论开始时，主持人点出了一个关键条件：OpenAI 内部员工的 token 使用没有普通客户那样的额度约束。外部团队不能忽略这种资源差异。

Raji 在访谈前半段提到，个别工程师每周会使用数千亿 token。这是他的内部使用情况陈述，视频没有提供统计口径和用量记录，无法据此计算成本，也不能把它当作普通工程师的用量标准。

他建议换一个核算角度：如果智能体足够可靠，能够全天候承接任务，成本就可以与完成的工作相比较。每位工程师协调 4 到 5 个这样的助手时，预算讨论也会超出单次调用消耗多少 token 的范围。他同时承认，供应商必须把能力做到足以承担这种期待。

Tibo 补充，市场调研、清理积压需求、判断哪些功能容易实现，也会消耗人的时间。智能体接手其中一部分工作，会改变这些任务的成本结构。他因此主张，过早压低推理额度可能限制探索，应给能有效使用工具的人更充足的空间。

从这段讨论可以推导出一个更可检验的管理问题：增加预算之后，究竟多完成了什么，省下了谁的时间，又增加了多少检查和返工？ 视频没有给出普遍适用的投入产出比例，具体团队仍需用自己的交付结果回答。

抽象层更高以后，验证和调试会更难

对话最后的预测需要放回 2026 年二月的访谈语境。Tibo 当时预计，未来 6 个月速度可能再提升一个数量级，多智能体网络也会开始承担更大的目标。这些是当时的判断，本文没有把它们视为后来已经兑现的结果。

他借 Cursor 的浏览器探索，描绘了一种可能的规模：发出从头构建浏览器的目标，24 小时后得到约两百万行代码。视频没有为这个例子提供可复核的交付和质量证据，它服务于后续讨论：当代码大到难以逐行理解，团队将如何确认系统正确？

Tibo 设想，工程师会更多地约束系统行为、检查输入输出，并寻找证明正确性或限制风险的方法。他还预计，2026 年内可能出现一个统一的个人助手，代表后台多个智能体汇报进展，减少人逐个查看任务的负担。

Raji 则指出，复杂系统的层次越多，调试越困难。开发者可能越来越依赖症状和外部行为来定位原因，工具也需要帮助人建立这种诊断能力。

这些预测是否兑现，需要后续证据。但访谈已经呈现出一个具体变化：当写出代码所需的时间缩短，团队会更频繁地碰到需求不清、验证不足和决策等待。软件工程的价值，也会更多地体现在把这些问题处理好，让生成的东西成为可以负责、可以维护、可以交付的产品。