Every 新报道：代码生成快起来之后，谁来接住基础设施风险

Every 在 7 月 27 日发布的报道《Inside OpenAI’s Race to Reinvent Software Development for the Agent Era》，从一条发生在深夜的数据导出故障写起。研究员已经睡了，负责值班的基础设施工程师 James Katz 也没有醒着；运行在研究员电脑上的 coding agent 却能访问需要的工具和内部系统，自行诊断问题、尝试修复，第二天早上把数据交回来。1 2

这个案例很适合用来理解文章的语气。它没有把「agent 能自己处理故障」直接写成工程师即将消失，而是马上补了一句：现实比旧金山街头的宣传牌复杂得多。报道真正关心的，是当代码生成速度突然提高之后，原来负责接住代码的系统会发生什么。

报道写道，OpenAI 的工程师现在能以 AI 之前的 10 倍、甚至 100 倍速度交付代码。Codex 也不再只是工程师的工具，产品经理、数据科学家、研究员和市场团队都在用它写、改、调试并提交会运行在内部系统上的代码。这个数字是报道对 OpenAI 内部状态的描述，不是 Every 做的独立基准测试。1

后果很快落到了应用基础设施团队身上。Emma Tang 负责的数据平台团队，pull request 数量在一年里增长了 5 到 10 倍；一部分提交来自不熟悉底层系统的非技术员工，有人甚至在生成 Apache Flink 任务时并不了解 Flink。代码变多以后，延迟的数据处理和打不开的仪表盘也跟着出现。出了问题，最了解这套基础设施的人往往只能自己接手。

Tang 对这种处境的概括很直白：「We become the catch-all. Nobody owns it anymore except us。」AI 让更多人可以做出原型，却没有自动给这些原型安排维护者。一个每几秒刷新一次、但数据源每天才更新一次的内部应用，看上去是小毛病，真正的问题却是它应该跑在哪里、怎样读取数据、谁对它长期负责。

OpenAI 的第一个反应不是限制 Codex，而是把 Codex 放进更多检查环节。报道提到，GPT-5.5 发布后的几周内，Codex 桌面应用在 OpenAI 内部的采用率接近 100%。工程师用它生成代码、测试和修复建议，也会更新共享的 Codex 指令，让同一类故障下次更早被拦住。1

James Katz 的团队还做了一个查询内部数据导出系统的 Codex skill。几周后，这个 skill 已经占到该系统总使用量的一半以上。另一支团队维护的内部数据分析代理被 5,000 多名员工使用。提交代码的流程也变成多层：先由作者和 coding agent 测试、记录和修改，再由独立的 Codex bot 审查，最后仍由人检查所有变更。大而有风险的改动，会让额外的 Codex 代理分别调查兼容性、系统影响和项目规范，最大的改动可能要经过十多个子代理。

文章把这套方案比作给洪水加过滤器。第一层是在代码写出来时就把团队标准写进 skill 和 guardrail；第二层是由了解某个系统的专门代理做独立复核；代码上线后，还有代理持续观察运行状态。把 CI 和 CD 单纯扩容，只会让更多代码更快通过，不会自动让代码更安全。至于让基础设施自己拒绝危险操作，文章把它列为最具推测性的最后一道防线，不能当成已经落地的产品能力。

这篇报道最重要的变化，不是「谁来写代码」，而是「谁来把经验写成系统可以执行的规则」。Molly O’Connor 过去处理故障、修复代码，现在还要把对数据管道、迁移、测试和发布的经验整理成 Codex 能遵循的指令。她的岗位目标没有改变，工作内容却更多地变成教会工具怎样避免重复犯错。1

OpenAI 应用基础设施副总裁 Venkat Venkataramani 预计，工程师以后会从审查代码，转向审查 prompt，再转向审查计划，最后审查业务问题本身。这个判断仍然是受访者对未来的预测，但它与文中的组织变化已经接上了：当代码由代理大量产出，人的稀缺能力就不再是把每一行写出来，而是判断一项改动是否值得、风险由谁承担、怎样证明它在工作。

这也解释了为什么报道反复提到 ownership。Tang 说，OpenAI 一直在招聘有主见、能自我驱动、愿意承担责任的人，但这些品质已经从加分项变成硬要求。模型可以接手很多执行动作，不能替团队决定什么问题该做，也不能凭空创造一个愿意在故障发生后负责到底的人。

Every 最近几期内容反复追踪 AI 工作流的实际摩擦：工具能不能留下，取决于它是否解决真实问题；模型变强，也不代表原有的 skills、插件和收尾习惯仍然适用。这篇新报道把同一问题推到了公司基础设施层面：当每个人都能快速造出软件，组织首先要重做的不是写作界面，而是代码进入系统之前、运行期间和出问题之后的责任链。1

从这个角度看，Every 关注的「AI 原生公司」并不是让所有人都变成半吊子工程师。更接近的描述是：让更多人可以提出和实现想法，同时把专业团队的判断编码进工具、审查和运行环境。文章里的 skills、review agents 和监控代理，都是在回答同一个问题：怎样让能力扩散，而不让责任也随之蒸发。

Every 官方播客页目前仍把 AI & I 第 106 集放在最前，标题是《How Every’s Team Used AI to Ship Its Biggest Launch Ever》。页面没有显示它在 7 月 27 日至 28 日新发布的绝对日期，因此本轮不把它算作新的播客露出，也不重复改写上期已经覆盖的 All Access 复盘。3

官网首页仍列出 Spiral、Cora、Sparkle、Monologue、Proof 和 Plus One 等产品，但没有出现带有 7 月 27 日或 28 日日期的新产品公告。当前可核验的新信号集中在这篇报道本身，不能把首页的静态产品卡片当成今日发布。4

对 Every 来说，下一步应该看一件很具体的事：它是否会继续公开 AI 原生团队的审查指标和责任分配，而不只是展示代理完成了多少任务。OpenAI 的这篇报道给出了「过滤器」的设计方向，却没有给出这些过滤器在真实事故中的通过率、误报率或维护成本。答案仍在后续实践里。