AI时代程序员不写代码了，但比以前更忙了！

3 个人干了 30 个人的活

2026 年 2 月，OpenAI 工程师 Ryan Lopopolo 公开了一个内部实验的数据。

3 名工程师，5 个月，从零开始，不写一行代码。所有代码全部由 AI Agent 生成。最终产出大约 100 万行生产级代码，合并了 1500 个 PR。

https://openai.com/zh-Hans-CN/index/harness-engineering/

image-20260414162701597

Lopopolo 描述自己在实验中的心态："就像我是一个 500 人组织的团队技术负责人。"

3 个人，管着一群 AI，干出了传统团队 20 到 30 个人的活。每人每天平均提交 3.5 个 PR，高峰期 5 到 10 个。每天烧掉大约 10 亿个 token，花费两三千美元。

看到这组数字，我的第一反应这样下去程序员咋办呢，出路在哪里。

但仔细看完整个实验，你会发现事情没那么简单。

代码不是他们写的，但活全是他们干的

这 3 个人到底在忙什么？他们一行代码都没写，怎么就忙到飞起？

我把他们的工作拆开来看，发现大概分成五件事。

**第一件事，设计知识库。**他们花了大量时间写文档。不是给人看的文档，是给 AI 看的。

项目根目录下有个 AGENTS.md 文件，大概 100 行，相当于一本说明书的目录。然后 docs/ 目录里放着详细的设计文档、架构参考、数据库 Schema。

AI Agent 接到任务后，先读 AGENTS.md 找到方向，再去 docs/ 里找具体信息。这套体系让 AI 能自己搞清楚该怎么干活，不用人反复解释。

**第二件事，构建工具。**他们写了 CLI 工具、MCP 服务器、各种集成接口。

注意，这些工具不是给人用的，是给 AI 用的。AI Agent 需要查数据库、调用 API、执行部署，都得靠这些工具。工程师的角色变成了给 AI 搭工作台。

**第三件事，执行约束。**他们把所有架构规则都写成了 Linter。比如代码的层级依赖关系：Types、Config、Repo、Service、Runtime、UI，下层不能反向依赖上层。

AI 写的代码如果违反规则，CI 直接阻止合并，不需要人去审查。而且 Linter 的报错信息写得特别讲究，不只说"你违反了规则 X"，还会解释为什么有这条规则、正确的做法是什么。这样 AI 读到报错后能自己改，不用人介入。

**第四件事，设计反馈循环。**CI 管道、可观测性系统、自动化测试，这些都是标配。

他们甚至搞了一个"文档园丁 Agent"，在后台自动扫描文档跟代码之间的不一致。发现过时内容就自动提 PR 修复。Agent 给 Agent 维护文档，这个想法挺疯的。

**第五件事，编排多个 Agent。**他们同时跑很多 AI Agent，每个处理不同的任务。工程师要协调这些 Agent 之间的依赖关系，管理冲突，确保它们不会互相踩脚。

看完这五件事，你会发现一个有意思的事情：这些工程师的工作强度一点都不低。他们只是不写代码了。他们的精力全部花在了设计环境、制定规则、维护系统上。

image-20260414163323043

严谨性没有消失，只是搬家了

Chad Fowler 描述了这个变化：Relocating Rigor，翻译过来就是"严谨性的搬迁"。

以前，一个好工程师的标志是代码写得干净、测试覆盖充分、文档及时更新。这些都是对写代码这件事的严谨要求。

现在，严谨性换了一种方式。

约束系统设计得是否完善？反馈循环是否够紧密？架构规则是否被机械化执行？AI 犯了一个错之后，你有没有工程化一个方案让它永远不会再犯同样的错？

Hashimoto 在他的开源项目 Ghostty 里就是这么干的。AGENTS.md 文件里的每一行，都对应一个历史上 Agent 犯过的错误。这份文档它是活的，是一个持续运转的反馈循环。

Thoughtworks 的 Birgitta Böckeler 在 Martin Fowler 的网站上写了一句话，我觉得是目前对这件事最精准的总结：

"为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。"

Martin Fowler 网站上 Böckeler 分析文章截图

想让 AI 干更多的事，你就得给它画更清楚的线。自由和约束在这里是反过来的。

布鲁克斯法则被打破了

搞软件的人都知道布鲁克斯法则。1975 年 Fred Brooks 在《人月神话》里提出来的："给一个已经延期的项目加人，只会让它更延期。"

原因很简单。新人需要上手时间，老人需要花精力带新人，沟通成本随人数指数级增长。传统团队加人，效率不升反降。

但 Lopopolo 的实验里出现了一个反常现象。团队从 3 个人扩展到 7 个人之后，吞吐量不减反增。

为什么？因为 Harness Engineering 的工作方式跟传统团队完全不同。

工程师之间的协作不是通过开会对齐、代码评审、知识同步来完成的。他们协作的媒介是共享的约束系统。新人加入后，只要读懂 AGENTS.md 和 docs/，就能开始给 AI 派任务。Linter 和 CI 会自动保证质量。人和人之间的沟通成本被系统吸收了。

这可能是 50 年来第一次，有人用实验数据证明了在某种工作模式下，加人真的能线性提升产出。

现实没有那么美好

讲完令人兴奋的部分，得说说现实。

Harness 平台做的 2026 年调查显示，69% 的高频 AI 编码工具用户报告部署时经常遇到问题。AI 写代码越来越快，但后面的测试、安全扫描、部署流程没跟上。代码是生成了，能不能顺利上线是另一回事。

73% 的工程团队领导说，他们的团队几乎没有标准化的黄金路径模板。大部分团队还在摸索怎么把 AI 生成的代码可靠地推到生产环境。

还有一个更尖锐的问题。OpenAI 的实验是从空仓库开始的。全新项目，没有历史包袱，想怎么设计架构就怎么设计。

但现实中大部分团队面对的是几十万行遗留代码、混合技术栈、各种历史债务。在这种项目上搭建 Harness，难度完全不是一个量级。

Harness 最需要的地方，恰恰是最难构建的地方。

到底谁会被淘汰

中文技术社区这段时间讨论很多，焦虑情绪很明显。3 个人干 30 个人的活，往后不需要那么多人了。

我看到的事实是这样的。

LangChain 团队做了一个实验：同一个模型，只改变外部环境的设计，基准测试得分从 52.8% 跳到 66.5%。模型一个参数都没改。Can Boluk 的实验更夸张：只改变代码编辑格式，一个模型的得分从 6.7% 跳到 68.3%。

这说明在当前阶段，会设计约束系统、会搭建反馈循环、会编排 Agent 的工程师，能让一个普通模型发挥出顶级模型的水平。

Stripe 内部的 AI 工具每周产出 1300 多个纯 AI PR。Anthropic 的 Claude Code 每天在 GitHub 上产生大约 13.5 万次提交，占公开提交的 4%。这些数字每个月都在涨。

同时，Karpathy 也完成了一次有意思的转变。一年前他发明了 vibe coding 这个词，说"忘记代码的存在，全部接受，不看 diff"。一年后，他改口推崇 agentic engineering，强调"这里面有艺术、科学和专业技能"。

从不看代码到工程是一门手艺，连 vibe coding 的发明者自己都用一年时间走完了这段认知升级。

以上就是我看到的全部信息。至于你自己是"写代码的人"还是"设计笼子的人"，以及是否转变如何转变，值得思考。