OpenAI工程师不写代码了：AI写得太快，人类检查跟不上，Agent直接包办开发
OpenAI 最近在一篇 Blog 中说了件挺炸裂的事：他们自己的工程师，已经不怎么写代码了。
在一个内部项目里，短短五个月，就产出了 100 万行代码，而且没一行手写，全都是 Codex 写的。
这些代码并不是什么零散脚本，而是从零开始搭出来的一整套软件产品内部 Beta 版：从应用逻辑、基础设施，到工具、文档和内部开发者工具，几乎一应俱全。
01
这种变化，或许能从 OpenAI 内部一直以来的工程师文化中找到一些线索。
一位曾参与 Codex 项目的 OpenAI 工程师 Calvin French-Owen，在离职后写过一篇博客，虽然他在其中吐槽说，过去一年里 OpenAI 员工规模迅速扩张，带来了不少混乱。
不过他同时也提到，公司内部依然保留着很强的创业公司氛围：团队小、决策快，工程师拥有很高的自主权。
另外，很多科技巨头是高层定路线、然后团队执行，但在 OpenAI，通常没有明确的长期 roadmap，研究员往往自己发现问题、提出想法，小团队围绕好点子自然形成并推进项目。
他表示，真正推动进展的好想法可能随时从任何地方随时，而不是来自某个宏大计划。
“OpenAI 非常注重自下而上的方式，尤其是在研究方面。”
比如 Codex，最初其实诞生在 OpenAI 的一个只有十几人的小团队里。这个团队在 7 周内几乎不眠不休，把 Codex 从想法一路推到了上线。
而现在这个“OpenAI 工程师不写代码”一事，其实也要从公司一个团队，在开发流程中发现的新瓶颈说起。
现在 AI Coding 这件事已经屡见不鲜。但当 Codex 开始大规模生成代码后，OpenAI 的这研发团队很快发现一个 新问题：
代码生成已经不慢了，慢的是让人类来检查这些代码。
人的时间和注意力是有限的。在整个开发流程里，最容易卡住的环节反而变成了 QA（质量测试）。
为了解决这个问题，OpenAI 的工程师换了个思路：干脆让 Codex 模仿工程师，自己去“看”和“用”应用。
那 OpenAI 的工程师现在不写代码了，他们到底在做什么？
——设计环境、搭反馈循环、定义架构约束，然后让 agent 写。
文章中强调一句话：“人类掌舵，智能体执行” 。
他们管这叫 Harness Engineering，直译过来的话就是“AI 驾驭工程”。
工程师变成“能力架构师”
这个项目始于 2025 年 8 月下旬，从向一个完全空白的代码仓库提交第一行内容开始。
初始架构，包括代码仓库结构、CI 配置、格式化规则、包管理器设置和应用框架——都不是工程师手写的，而是在一小套模板的指导下，由 Codex CLI 调用 GPT-5 自动生成。
甚至连那份告诉 agent “该如何在这个仓库里工作”的 AGENTS.md，也是 Codex 自己写出来的。
换句话说，这个系统从诞生那刻起，就几乎没有人工代码。整个代码仓库，都是被 agent 一步一步搭起来的。
不过，一开始事情并没有想象中那么顺利：起初项目推进速度缓慢，但问题并不在 Codex 的能力，而在环境——规则不清晰、工具不完整、系统约束还没建立起来。
有网友“一针见血”道：
“最扎心的一句：agent 反复犯错，不是能力问题，是你脑子里的判断力没写下来。你不写，它第一百次还犯同样的蠢。”
于是再遇到开发卡住时，团队不再想着“再改一段代码试试”，而是先问一个问题：agent 到底缺什么能力？
再把这种能力变成它能读懂、能执行、还能被强制遵守的规则。
也就是说，面对当下 agent 自己就能测试、改 bug 的情形，工程师的工作重点从“写代码” 变成了另一件事：让 Codex 更容易把事情做对，给 agent“补能力”。
从这个角度看，工程师的工作其实转向了更高一层：用一句话来说，就是 拆解任务、设计能力、搭建系统，让 agent 可以稳定地产生正确的代码。
02
具体来说，大致有这几件事情：
第一件事，就是 让应用对 AI “可读”。
正如上文提到的，需要人为把 agent 接入 Chrome DevTools 协议，让它能“触控”UI。
工程师要做的第二件事情，就是把“隐性知识”全部写进代码仓库， 变成机器可读的知识。
对 agent 而言，无法在运行时访问的内容就等于不存在。比如存储在 Google Docs、聊天记录或人们头脑中的知识吗，这些都无法被系统访问。
不过，不可以把所有规则和说明一次性塞给 Codex，而是要先给它一个导航，再让它自己去查细节。
研究研究团队曾尝试过直接给 agent 一个巨大的 AGENTS.md 文件，结果很快发现行不通。
主要原因是，上下文是稀缺资源，说明书越厚，真正重要的信息反而越容易被淹没；而且这种大文档很快就会过时，也很难验证和维护。
他们把这段经验总结成了一句：
“要给 Codex 的是一张地图，而不是一本 1000 页的说明书。”
该示意图由 AI 生成
工程师要做的 第三件事，是设计“AI 友好”的架构。
AI 在结构清晰、边界明确的系统里效率最高。对人来说，这些规则可能显得死板，但对 agent 来说，这是效率倍增器。
所以 OpenAI 的这个团队设计了一套严格架构, 每个业务域必须按固定层级：Types→ Config→ Repo→ Service→ Runtime→ UI。
依赖方向是强制的。任何违反都会被自动阻止。
第四件事，是把“品味”变成规则。
“在 AI 时代，人类最重要的能力是 Taste。”随着大模型越来越强，这样的声音不绝于耳。
这篇 Blog 中，有一个很有意思的概念：taste invariants（品味不变量）。
意思是，工程师的审美，比如：文件大小限制、命名规则、日志结构、API 规范等，都被写成 lint 规则。
这样 AI 每次写代码都会自动遵守：“人类的品味一旦被捕捉，就可以应用到每一行代码。”
在实际开发中，人类主要通过提示与系统交互：描述任务、启动 agent，然后让 Codex 自动生成 Pull Request。
接下来的一整套流程，包括代码自检、agent 评审、根据反馈修改、再次提交，基本都由 agent 自己完成，并不断循环，直到所有评审通过。
第五件事，就是清理 AI 产生的“垃圾”。
文章指出，完全自主的智能体也引入了新的问题。
当代码几乎全部由 Codex 生成后，一个新问题也出现了：AI 会不断复制代码库里已有的模式，包括那些不太好的写法，时间一长代码风格就会慢慢“漂移”。
一开始，团队计划每周抽一天时间手动清理这些“AI 残渣”，但很快发现这种方式根本不具备可扩展性。
后来他们把工程师的经验和偏好写成一套“黄金原则”，比如优先使用共享工具库、严格校验数据结构而不是“猜着写”。
然后将这套原则直接编码进代码仓库，让 Codex 自动扫描问题并发起重构 PR。
这样就像给代码库加了一套“垃圾回收机制”：小问题可以随时清理，技术债不会越滚越大。
这篇 Blog 在技术圈引起了的广泛关注和讨论，有人认为，这个 Harness Engineering 本质上是一种现代版的控制论：工程师不再直接写代码，而是设计系统、规则和反馈回路，让 agent 自动完成工作。
他表示，这种模式，其实在历史上已经出现过三次了。
从瓦特蒸汽机的调速器，到 Kubernetes 的控制器，再到今天的 AI agent；真正的变化不是“机器替代人”，而是 人的角色，从执行者变成系统的设计者和校准者：
“你不再亲自去拧阀门，而是开始掌舵。
每当这种模式出现，背后通常都是因为有人构建出了足够强大的传感器和执行器，能够在那个层级上把反馈回路真正闭合起来。”
Agent 都开始包办开发流程了
03
为什么 OpenAI 的工程师可以不再写代码了？不妨来看看他们的 agent 现在已经能干到什么程度。
前文提到，OpenAI 的工程师换了个思路：干脆让 Codex 模仿工程师，自己去“看”和“用”应用。
第一，是让 agent 能“看见”应用界面（UI）。
他们把 Chrome DevTools 协议接入到 agent 的运行环境里。这样一来，Codex 就可以像开发者在浏览器里调试一样操作页面、读取日志、抓取 DOM、截屏观察界面......
这一步其实非常关键，因为 LLM 本身是看不见 UI 的。
接入 DevTools 之后，Codex 就相当于有了“眼睛”和“手”：
可以通过截图和 DOM 观察页面，通过 console 和 network 监听运行状态，还能自己点击、输入、导航。
该示意图由 AI 生成
有了这些能力，agent 就可以自己复现 bug、自动跑 UI 测试、验证修复是否生效。
这样一来，Codex 就不只是写代码，还开始像一个自动化 QA 工程师一样工作：自己测试自己写的代码，并反复修复，直到系统通过测试。
换句话说，原本需要人工完成的大量测试和调试工作，被自动化了。
就像下面这张图里展示的那样：最核心的一步是 “Loop Until Clean”——不断测试、修复、再测试，直到系统没有错误。
第二点，只能操作 UI 还不够，还得让 agent 看见系统内部发生了什么。
为此，OpenAI 给 Codex 接入了一整套 可观测系统（Observability）。
应用在运行时会产生三类关键数据，也是工程师排查问题时最常用的信号：
- Logs（日志）
- Metrics（性能指标）
- Traces（调用链）
这些数据会先被一个叫 Vector 的组件统一收集，再送到本地的可观测系统里。
这样一来，Codex 就能像工程师一样查系统状态：哪个服务报错了？哪个接口变慢了？请求卡在哪一层？
当发现问题后，Codex 会自己修改代码、提交 Pull Request、重启应用、重新运行任务，再观察系统指标有没有改善。
整个过程会形成一个 自动反馈循环：发现问题 → 修改代码 → 再运行 → 再观察。
一直重复，直到问题消失。
换句话说，Codex 不只是看代码，还能像运维一样查日志、看性能数据，判断系统哪里出了问题，再修改代码验证修复效果。
这篇博文中提到，给定一个提示，Codex 驱动的 agent 就可以：
agent 不再只是一个写代码的工具，而是开始承担完整的软件开发流程。
整个开发流程大致为：Codex 写代码 → 启动应用 → 像用户一样操作页面 → 检查结果 → 如果不对就改代码再跑。
不过需要说明的是，这套流程之所以能跑通，很大程度上依赖他们为这个代码仓库专门设计的结构和工具链。
如果没有类似的工程投入，这种“全自动开发流程”目前还很难直接照搬。
目前来看，这套“agent 写代码、人类设计系统”的模式，在 OpenAI 内部运行得还不错；但很多问题仍在探索阶段：比如 AI 生成的代码库长期会不会失控，人类判断力该如何嵌入系统。
不过可以预见的是，软件工程的重点可能会逐渐从“写代码”，转向设计环境、规则和反馈机制； 让像 Codex 这样的 agent，可以更稳定地参与构建和维护复杂的软件系统。
参考链接：
https://openai.com/zh-Hans-CN/index/harness-engineering/
https://x.com/odysseus0z/status/2030416758138634583
https://calv.info/openai-reflections
本文来自微信公众号 “AI前线”（ID：ai-front），作者：木子，36氪经授权发布。
