An exclusive look at how OpenAI’s infrastructure team is adapting to a flood of AI-generated code
每天在您的收件箱中收到帮助您构建未来的新想法。
请勿出售或共享我的个人信息：#
我们默认使用分析和广告工具。您可以随时更新此设置。
这是旧金山几乎每块广告牌的承诺：智能化未来已经到来，自动化取代了对人类工程师的需求。
现实情况，通常比广告牌所宣称的要复杂得多。
在深夜的某个时候，一名研究人员笔记本上运行的编码代理在Slack上发布了一条关于数据导出失败的消息。
研究人员当时正在睡觉。值班的基础设施工程师詹姆斯·卡茨也是如此。
就代理而言，深夜时间对它毫无影响。它可以访问调试问题所需的工具和内部系统。
因此，在等待回应的过程中，它开始工作，勤勉地叙述自己诊断事件、调查潜在修复方案，并在遇到障碍时重新制定策略的过程。
到早晨，它已经将所需的数据交给研究人员，而卡茨或他团队的其他人无需介入。
在OpenAI竞赛中，为一个由智能代理编写所有代码的世界重新设计软件开发的内部情况
作者：Laura Entis · 摄影：Sarah Deragon 和 Sarah Jay Halliday
一位中年女性在旧金山使命湾区一栋光滑而不起眼的办公楼外对着对讲机讲话。
“午餐想吃什么，女士？”喇叭里传出刺耳的声音。一名高个子、留着胡子的保安在门口介入，制止了进一步的对话。“这里不是餐厅。”
确实不是。在3180 18th Street，也就是众所周知的OpenAI总部，你需要邀请才能进入大楼。一旦进入，你会在大堂受到欢迎，大堂的装潢像是略带企业风格的五星级酒店，配有精装书籍和配有柠檬的饮水机。
OpenAI 可能不是餐馆，但在几层楼上，午餐时间到了。员工们都在为公司所声明的实现通用人工智能（AGI）的使命而努力，他们排队领取丰盛的饭碗、玉米卷、炒菜和新出炉的热披萨，据说这是旧金山最大的明火披萨炉烤制的。
随着 OpenAI 与竞争对手 Anthropic 比拼，以越来越快的速度发布前沿模型，其工程师的代码交付速度可比 AI 出现前快 10 到 100 倍。Codex，这家公司的编码助手和桌面应用，将这一能力扩展到工程之外；产品经理、数据科学家、研究人员以及市场推广员工使用它来编写、修改、调试并提交在 OpenAI 内部系统上运行的代码。食堂里许多人盯着手机，也许是在发信息、浏览社交媒体，更可能是在通过 OpenAI 的移动应用协调智能代理。
对于任何正在构建新产品或工具的人来说，这是一个令人振奋的时刻。然而，对于负责维护使所有这些构建成为可能的内部系统的工程师来说，这种感觉更像是在艰难维持现状。
“我们经常用‘洪流’来形容，”应用基础设施数据平台团队负责人 Emma Tang 说。Tang 的团队维护着支撑每个 OpenAI 产品的管道中数据移动、分析和安全的基础设施，包括 ChatGPT 和 Codex。过去一年中，该团队的拉取请求（PR，即对共享代码库提出的变更建议）数量增长了五到十倍。
其中相当大一部分代码来自于组织内非技术部门的人。“我们有用户生成 Flink 作业”，Tang 说，Flink 是一个分析产品数据连续流的系统，“而他们甚至不懂 Flink”。随着变更速度的加快，内部可靠性问题也在增加，从数据处理延迟到仪表盘无法加载。而当出现故障时，代码作者往往无能为力，因为他们并不完全理解自己提交的内容。
直到最近，如果运营部门或市场推广团队的人想要一个定制的内部应用程序，他们需要找到工程师来为他们开发。唐（Tang）说，现在公司里的任何人都可以“周一带着他们周末制作的工作原型出现”。她的工程师越来越多地充当教育者和调解者的角色，帮助同事将他们的 AI 生成工具转化为可靠的软件。例如，一个按情绪编码的应用程序可能不必要地每隔几秒刷新一次，而它所提取的分析系统每天只更新一次。要让数据真正实时，就需要将其连接到不同的生产系统，这会引出大多数没有技术背景的人难以察觉的问题——比如：“它会运行在哪里？”、“它应该如何获取信息以不降低其他人依赖的服务速度？”或者“谁来维护它？”
尤其是最后一个问题，通常落在唐的团队身上。AI 允许公司里的任何人构建依赖于公司共享数据基础设施的应用程序和系统，但如果代码失败，她的团队就会继承这个问题。
“我们成了全能承接者，”唐说，“除此之外，再没有人负责它了。”
应用基础设施团队对这场信息洪流的第一回应也是生成它的工具：Codex。
在 GPT-5.5 发布后的几周内：https://every.to/vibe-check/gpt-5-5，Codex 桌面应用的采用率：https://openai.com/index/how-agents-are-transforming-work/ 在 OpenAI 内部几乎达到了百分之百。工程师现在主要通过该应用进行工作，审查 AI 生成的代码、AI 生成的测试（确认代码按预期运行的自动检查）以及 AI 提出的修复方案。由于 OpenAI 员工没有代币限制，工程师可以在 Codex 中排队一批 UI 漏洞，让多个代理独立编写修复、在产品的测试版本中运行、在浏览器中点击受影响流程，并标记由此产生的问题——所有这些都使用最强大的模型（许多员工在模型向公众开放前就被授予访问权限），而无需考虑成本或效率。
当莫莉·奥康纳在2024年10月加入OpenAI的应用数据平台团队时，她的典型工作日包括接到事件通知、调试问题，然后继续处理下一件事。现在，除了修复问题本身，她可能还会更新公司的共享Codex指令，以便将来能够纠正类似的问题。当奥康纳在拉取请求中发现重复性问题时，尤其是可能降低系统可靠性的问题时，她也会采取同样的做法。
她的角色——确保OpenAI的数据基础设施保持可靠和安全——并没有改变。但现在更多的工作涉及将她在构建和排除数据管道故障、执行大规模迁移以及测试和推出数据处理系统更新方面的经验，转化为Codex可以遵循的指令。
在Codex调试通宵导出失败时，当班的OpenAI基础设施工程师詹姆斯·卡茨是这种演变的一个极端例子。GPT-5.5发布后，卡茨的团队创建了一个实验性的技能，让Codex可以代表获批用户查询OpenAI的内部数据导出系统，而无需用户知道如何将请求转换为格式精确的SQL数据库指令。（“天哪，这大多数情况下第一次尝试就真正有效”，卡茨记得自己当时的想法。）几周内，这个新的Codex技能就占据了数据导出系统总使用量的一半以上。卡茨的团队被这一情况震惊了；工具的立刻受欢迎是一个肯定，但也意味着他必须处理所有边缘情况，并为系统中没人记录的部分编写指导。
可以说，这一直是一种平衡行为。卡茨礼貌地形容他的团队为“资源受限”；任何花在导出技能上的时间都是没有用于现有基础设施工作的时间。他说：“待办事项总是比我们有的人力来支持的工作多。”
类似的情况在整个OpenAI中都有发生。技术员工徐蓓蓓和实时数据基础设施负责人阿拉温德·苏雷什在一个小团队中工作，该团队构建并维护OpenAI的内部数据分析代理，该代理被公司超过5000名员工用来查询数据仓库。
八个月前，如果有人想修改代理，他们会通过 Slack 请求更改。六个月前，这变成了“嘿，我可以提交一个 PR 吗？”两个月前，它变成了“我有一个 Codex 为我创建的 PR。你能审查它吗？”
现在，来自公司各地的拉取请求如洪水般涌入。像 O’Connor 和 Katz 一样，Xu 和 Suresh 的团队通过创建共享的 Codex 技能来管理这些涌入的请求。当一个 PR 到达他们的团队时，Codex 应该已经帮助其作者进行了测试、文档编写和优化——这大大有助于过滤掉真正无法挽救的代码更改。
Xu 表示，一旦 PR 准备好，一个单独的自动 Codex 机器人会对其进行审查，经常会发现第一个代理或作者错过的问题。人工审查者仍然会查看每一个 PR，特别关注那些大规模、有风险或对系统可靠性至关重要的更改。对于这些更改，团队会要求额外的 Codex 代理调查具体问题——例如，重写部分代码是否可能影响其他系统，或者更改是否符合项目指南。最大的更改可能会通过整个流程再次处理，由十几个子代理参与。
Codex 并不能解决所有问题。Tang 的团队还构建了一个由 ChatGPT Workspace 代理提供支持的 Slack 机器人，以分流公司同事不断涌来的问题——例如“我需要什么权限才能更新这个表？”或“这个数据管道失败了，有人能看看吗？”
但即使是这些零散的工具也不足以应对。Tang 说：“如果有人说他们有解决方案，他们可能只是不了解全局。”
然而有一件事是明确的：相比即将到来的情况，如今的洪流看起来只是小雨。
“我们还什么都没见过呢，”OpenAI 应用基础设施工程副总裁 Venkat Venkataramani 说。
穿着绿色和灰色格子法兰绒衬衫、运动鞋和蓝色牛仔裤，Venkataramani 的休闲装扮和温和语调掩盖了他独特的视角。作为负责在 AI 生成代码洪流下保持 OpenAI 基础设施运行的人，他比几乎任何人都清楚公司正面临什么——以及整个软件行业即将面临的情况。
今天由人工智能生成的代码数量空前；温卡塔拉马尼回顾道，将来这会显得颇为古怪。在不久的将来，一年的事件可能会被压缩到一周内。“洪水即将来临，”他说。
与淹没城市的洪水不同，危险不仅在于水量本身。更多高质量的代码只是意味着更多有用的，或者至少无害的软件。危险在于洪水带来的东西：错误、安全问题，以及在涌入的修改提案中隐藏的其他问题。随着代码量达到10倍、100倍，甚至可能1000倍，即便是很小比例的污染代码也会成为严重威胁。
第一道防线是持续集成（CI），它是在新代码合并到共享代码库之前进行测试的自动检查点。再往前是持续部署（CD），它将已批准的代码发布到生产环境中。在一个前代理世界中构建，这两者都是为以人类速度编写的代码设计的。但是，随着生成代码的成本趋近于零且代码量激增，等待测试和合并的修改数量将压垮系统。CI未能发现的问题会通过CD进入生产环境，从而导致失效事件的发生。
在温卡塔拉马尼看来，解决方案不仅仅是扩大现有系统的容量。“如果你只是扩展CI基础设施和CD基础设施，你每天只会有100倍更多的代码流入，”他说。“然后呢？”扩展CI和CD只是让更多的代码通过系统，而并未提高这些代码的安全性。
他的解决方案类似于现代雨水管理。不依赖单一的下游检查点，而是在多个点过滤不同的问题。“你添加10个这样的过滤器，”他说，“最终你会得到干净的水。”
第一个过滤器是最直观的，也是像奥康纳这样的人已经在做的：在编写代码时进行塑造，这样团队的标准就会内置到Codex等工具的编写和审查中。
技能提供了一层保护，但唐想要更可执行的措施：更强有力的检查，这些检查存在于Codex中、代码审查系统中，或者由负责受影响系统的团队提供的代理执行。在后一种情况下，一个代理编写代码，而另一个代理利用所属团队的专业知识来评估提议的更改是否适合该系统。
这些审查代理可以按领域进行专业化——也许一个用于检查处理大量信息的代码，另一个用于审计实时数据管道，等等——这些代理与编写代码的代理不同。这样，一个代理可以构建用户要求的任何功能，而审查代理则可以完全专注于确保代码不会破坏任何内容。
一旦代码运行，不同类型的代理可以全天候监控系统的实时可靠性问题。这些代理不是审查代码，而是观察代码的实际表现，并且唐希望能够在问题影响其他系统之前捕捉和隔离它们。
她对最终防线的构想最为推测性，进一步迈出了一步。虽然始终在线的代理会监控系统并在检测到问题时作出响应，唐设想了一个近未来，其中判断能力被内置于基础设施本身。在这种情况下，技术系统即使之前所有的安全保护都批准了操作，也可以自主拒绝执行不安全的操作。唐说，基础设施会有自己的“智能水平，就像一个人类操作员坐在那个服务中一样”。
在较大的软件项目中，新代码在进入生产环境之前会经过一系列检查
持续集成（CI）在新代码加入共享代码库前进行测试
持续部署（CD）将经过批准的代码发布到生产环境。它会监控代码的行为，并在出现问题时可以停止或撤销发布。
AI工具可以生成远超根据人类速度设置的检查点所能处理的代码量
扩展管道有助于处理更多代码，但仅有容量并不能让代码更安全
额外的过滤器可以在多个环节捕捉问题
技能和守护机制在 Codex 编写代码时对其进行塑形，防止问题并应用所属团队的专业知识
专门的审查代理独立地根据每个系统的规则检查更改，抓住编码代理漏掉的问题
更具推测性的是，基础设施本身也可能成为最后一道防线，自动拒绝逃过早期检查的不安全更改
这些层级结合起来，可能让更多代码通过系统流动，支持日益复杂的软件，而问题不会相应增加
如果这一切得以实现，OpenAI 仍然需要工程师。但他们的工作日将不再涉及编写代码或识别和修补漏洞——AI 将为他们完成这些工作。
唐的团队已经在体验这种早期现实。“过去那些每天手写每一行代码的人，现在是‘砖工’，现在他们的工作变成了施工管理。”她说。“他们有大约 10 个 Codex [线程]，只是监控它是否在做正确的事情。”
New ideas to help you build the future—in your inbox, every day.
Do Not Sell or Share My Personal Information：#
We use analytics and advertising tools by default. You can update this anytime.
This is the promise of virtually every billboard in San Francisco: The agentic future has arrived, automating away the need for human engineers.
The reality, as is typically the case, is more complicated than the billboards would have you believe.
Sometime in the middle of the night, a coding agent running on a researcher’s laptop posted a Slack message about a failed data export.
The researcher was asleep. So was James Katz, the infrastructure engineer on call that evening.
For its part, the agent was unfazed by the late hour. It had access to the tools and internal systems it needed to debug the problem.
And so while it waited for a response, it got to work, diligently narrating its efforts to diagnose the incident, investigate potential fixes, and restrategize whenever it hit a roadblock.
By morning, it had handed the researcher the data they needed, without Katz or anyone else on his team having to step in.
Inside OpenAI’s race to redesign software development for a world where agents write all of the code
By Laura Entis · Photographs by Sarah Deragon and Sarah Jay Halliday
A middle-aged woman speaks into an intercom outside a sleek, nondescript office building in San Francisco’s Mission Bay district.
“For lunch, ma’am?” A tinny voice crackles through the speaker. A tall, bearded security guard intercedes at the door before the conversation can go any further. “This is not a restaurant.”
Indeed, it is not. At 3180 18th Street, better known as OpenAI’s headquarters, you need an invitation just to enter the building. Once inside, you’re greeted in a lobby appointed like a slightly corporate five-star hotel, complete with accent books and lemon-wheeled water coolers.
OpenAI may not be a restaurant, but a few floors up, it is lunchtime. Employees all working toward the company’s stated mission of achieving Artificial General Intelligence (AGI) line up for harvest bowls, tacos, stir fry, and hot slices fresh out of what I’m told is San Francisco’s largest live-flame pizza oven.
As OpenAI competes with rival Anthropic to release new frontier models at an increasingly rapid clip, its engineers can ship code 10, even 100 times faster than before AI. Codex, the company’s coding agent and desktop app, extends that capacity beyond engineering; product managers, data scientists, researchers, and go-to-market employees use it to write, modify, debug, and submit code that runs on OpenAI’s internal systems. Many in the cafeteria are glued to their phones, perhaps texting, scrolling social media or, more likely, orchestrating agents through OpenAI’s mobile app.
It’s an exhilarating time for anyone building new products or tools. For the engineers responsible for maintaining the internal systems that make all this building possible, however, the feeling is closer to staying afloat.
W e use ‘deluge’ a lot,” says Emma Tang , who heads the applied infrastructure data platform team. Tang’s group maintains the infrastructure that moves, analyzes, and secures the data flowing through the plumbing of every OpenAI product, including ChatGPT and Codex. The team’s volume of pull requests (PRs), or proposed changes to a shared codebase, has jumped five- to tenfold in the past year.
A meaningful share of that code arrives from people in non-technical parts of the organization. “We have users generating Flink jobs”—programs built with Apache Flink, a system that analyzes continuous streams of product data—“who don’t even know Flink,” Tang says. As the pace of change has increased, so have internal reliability problems, from delayed data processing to dashboards that fail to load. And when something breaks, the author often can’t help because they don’t fully understand what they’ve shipped.
Until recently, if someone in operations or on the go-to-market team wanted a custom internal app, they’d need to find an engineer to make it for them. Now, anyone at the company can “show up on Monday with a working prototype they built over the weekend,” Tang says. Her engineers act increasingly as educators and mediators, helping colleagues turn their AI-generated tools into reliable software. A vibe-coded app, for example, might unnecessarily refresh every few seconds, while the analytics system it pulls from updates only once a day. Making the data truly live means connecting it to a different production system, which raises questions largely invisible to people without a technical background—questions like, “Where will it run?,” “How should it retrieve information without slowing down the service everyone else relies on?,” or “Who will maintain it?”
The last question, in particular, often falls on Tang’s team. AI allows anyone at the company to build apps and systems that depend on the company’s shared data infrastructure, but should that code fail, her team inherits the problem.
“We become the catch-all,” Tang says. “Nobody owns it anymore except us.”
T he applied infrastructure team’s first response to the deluge is also the tool that created it: Codex.
Within weeks of the release of GPT-5.5：https://every.to/vibe-check/gpt-5-5, adoption of the Codex desktop app：https://openai.com/index/how-agents-are-transforming-work/ within OpenAI reached nearly 100 percent. Engineers now run the bulk of their work from inside the app, reviewing AI-generated code, AI-generated tests (automated checks that confirm the code works as it should), and AI-proposed fixes. Because OpenAI employees have no token limits, an engineer can queue up a batch of UI bugs in Codex and have multiple agents independently write fixes, run them in test versions of the product, click through the affected flows in a browser, and flag resulting issues—all using the most powerful models (many employees are granted access to models before they’re available to the public), without thinking twice about cost or efficiency.
When Molly O’Connor joined OpenAI’s applied data platform team in October 2024, a typical day included getting paged for an incident, debugging it, and then moving on. Now, along with making the fix itself, she might also update the company’s shared Codex instructions so that it can correct similar problems in the future. O’Connor does the same when she spots recurring problems in pull requests—especially ones that could make the system less reliable.
Her role—to make sure OpenAI’s data infrastructure remains reliable and secure—hasn’t changed. But more of the work now involves turning what she knows about building and troubleshooting data pipelines, executing large-scale migrations, and testing and rolling out updates to data-processing systems into instructions Codex can follow.
James Katz , the OpenAI infrastructure engineer on call while Codex debugged the overnight export failure, is an extreme example of this evolution. Following the release of GPT-5.5, Katz’s team created, as an experiment, a skill that lets Codex query OpenAI’s internal data export system on behalf of approved users, without requiring them to know how to translate their requests into precisely formatted database instructions written in SQL. (“Holy crap, this is really working on the first shot most of the time,” Katz remembers thinking.) Within a couple of weeks, the new Codex skill accounted for more than half of the data export system’s total usage. Katz’s team was caught off guard; the tool’s immediate popularity was validating, but it also left him to deal with all of the edge cases and write guidance for the parts of the system no one had documented.
It’s been a balancing act, to say the least. Katz politely describes his team as “resource constrained”; any time devoted to the export skill is time not spent on existing infrastructure work. “There’s always more work on the backlog than we have people to support,” he says.
A similar dynamic is playing out throughout OpenAI. Technical staff member Bonnie Xu and head of realtime data infrastructure Aravind Suresh are on a small team that built and maintains OpenAI’s internal data analytics agent, which is used by more than 5,000 of the company’s employees to query its data warehouse.
Eight months ago, if someone wanted to modify the agent, they’d request the change via Slack. Six months ago, that morphed into “Hey, can I cut a PR?” Two months ago, it became, “I have a PR that Codex created for me. Can you review it?”
Pull requests now pour in from across the company. Like O’Connor and Katz, Xu and Suresh’s team manage the influx by creating shared Codex skills. By the time a PR reaches their team, Codex should have helped its author test, document, and refine it—which has gone a long way to filtering out the truly unsalvageable code changes.
Once a PR is ready, a separate, automated Codex bot reviews it, often catching things the first agent or author missed, Xu says. Human reviewers still look at every PR, with particular attention to changes that are large, risky, or crucial to the system’s reliability. For those, the team asks additional Codex agents to investigate specific concerns—for example, whether rewriting part of the code could disrupt another system or whether the change follows a project’s guidelines. The largest changes may go through the entire process again with more than a dozen subagents.
Codex isn’t a fix for everything. Tang’s team also built a Slack bot powered by a ChatGPT Workspace agent to divert the constant stream of questions from colleagues across the company—questions like “What permission do I need to update this table?” or “This data pipeline failed, can someone look?”
But even this patchwork of tools isn’t enough. “If anybody says they have a solution, they probably just don’t know the whole picture,” Tang says.
One thing is clear, however: Compared to what’s coming, today’s deluge will look like a drizzle.
W e ain’t seen nothing yet,” says Venkat Venkataramani , OpenAI’s vice president of applied infrastructure engineering.
Dressed in a green-and-gray plaid flannel button-down, sneakers, and blue jeans, Venkataramani’s casual clothes and soft-spoken cadence belie his unique vantage point. As the person responsible for keeping OpenAI’s infrastructure running under the inundation of AI-generated code, he has a clearer view than almost anyone of what the company is facing—and what the rest of the software industry is about to face.
Today’s volume of AI generated code is unprecedented; in retrospect, says Venkataramani, it will look quaint. In the near future, a year’s worth of incidents could be compressed into a single week. “A flash flood is coming,” he says.
Unlike a flood that hits a city, the danger isn’t in the volume of the water alone. More high-quality code just means more useful—or at the very least, harmless—software. What’s dangerous is what the flood carries with it: bugs, security issues, and other problems hidden within the rush of proposed changes. At 10, 100, possibly 1,000 times the volume, even a small proportion of contaminated code becomes a serious threat.
The first line of defense is continuous integration (CI), the automated checkpoint that tests new code before it merges into a shared codebase. Farther along is continuous deployment (CD), which ships approved code into production. Built in a pre-agentic world, both were designed for code written at a human pace. But as the cost of generating code falls toward zero and volume explodes, the number of changes waiting to be tested and merged will overwhelm the system. Problems CI fails to catch pass through CD into production, where failures become incidents.
The solution, in Venkataramani’s view, isn’t simply to expand the existing system’s capacity. “If you just scale the CI infra and the CD infra, you’re just going to have 100x more code going in every day,” he says. “And then what?” Scaling CI and CD moves more code through the system without making that code safer.
His solution resembles modern stormwater management. Instead of relying on a single downstream checkpoint, it filters for different problems at multiple points. “You add 10 such filters,” he says, “you’re going to eventually have clean water.”
The first filter is the most intuitive, and what people like O’Connor are already doing: Shape the code as it’s written, so a team’s standards are built into how a tool like Codex writes and reviews it.
Skills provide one layer of protection, but Tang wants something more enforceable: stronger checks that live in Codex, in the code-review system, or in agents supplied by the teams responsible for the affected systems. In the latter scenario, one agent writes the code while another applies the owning team’s expertise to assess whether the proposed change is appropriate for that system.
These review agents could be specialized by domain—perhaps one for inspecting code that processes large volumes of information, another for auditing real-time data pipelines, and so forth—that are distinct from the agent writing the code. That way, one agent can build whatever a user asked for while review agents can fully focus on making sure that code doesn’t break anything.
Once the code is running, a different class of agents could monitor the systems around the clock for live reliability problems. Rather than reviewing code, these agents would watch how it behaves and, Tang hopes, catch and isolate problems before they affect other systems.
Her idea for a final line of defense is the most speculative, and goes one step further. Whereas always-on agents would monitor systems and respond when they detect trouble, Tang envisions a near-future in which judgment is baked into the underlying infrastructure itself. In this scenario, technical systems could autonomously refuse to execute an unsafe action, even if every previous guardrail approved it. The infrastructure would have its own “level of intelligence, almost like a human operator sitting in that service,” Tang says.
On larger software projects, new code passes through a series of checks before it reaches production
Continuous integration (CI) tests new code before it joins a shared codebase
Continuous deployment (CD) releases approved code into production. It monitors how the code behaves and can halt or reverse the rollout if problems appear.
AI tools can generate far more code than checkpoints built for a human pace can handle
Expanding the pipeline helps it handle more code, but capacity alone doesn’t make that code safer
Additional filters can catch problems at several points along the way
Skills and guardrails shape code as Codex writes it, stemming issues and applying the owning team’s expertise
Specialized review agents independently check changes against each system’s rules, catching problems the coding agent missed
More speculatively, the infrastructure itself could become a final line of defense, automatically rejecting unsafe changes that escape earlier checks
Together, these layers could let far more code flow through the system, supporting increasingly complex software without a matching rise in issues
I f all this comes to pass, OpenAI will still need engineers. But their days will no longer involve writing code or identifying and patching bugs—AI will do that for them.
Tang’s team is already living an early version of this reality. “People who used to be the bricklayers, where every piece of code is handwritten,” she says, now spend their days as construction managers. “They have like 10 Codex [threads] and they’re just monitoring whether it’s doing the right thing.”
扫码直达文章详情