程序员不再写代码：OpenAI的新范式
# 程序员不再写代码：OpenAI的新范式
想象这样一个场景：一个三人工程师团队接到任务，要交付一款完整的软件产品——前端、后端、基础设施、文档、工具链，样样不能少。按常规节奏，这需要数月甚至更长时间。但这一次，他们没有写哪怕一行代码。
这不是科幻小说。这是OpenAI在2025年夏天向世界展示的真实案例。
OpenAI发布了一篇题为《Harness Engineering》的官方博客，正式提出了一个足以颠覆软件行业的概念——Harness Engineering（缰绳工程学）。”Harness”这个词选得非常精准：人不再亲自”驾马”，而是设计缰绳、掌握方向、控制节奏。真正跑起来的，是Agent。
“We built and shipped a product with 0 lines of manually-written code.”
这句话出现在博客的开篇位置，没有铺垫，没有修饰。它像一个宣言，宣告着一个时代的结束和另一个时代的开始。
解构奇迹：一组令人屏息的数据
OpenAI究竟做到了什么？让我们把数字拆开来看。
这个项目最终生成了约100万行代码，覆盖应用逻辑、基础设施、工具链和文档。交付时间缩短到传统模式的十分之一。团队从3人扩展到7人，但令人惊讶的是，人均效率不降反升——每人每天合并3.5个PR，吞吐量随着团队扩张而增长。
这打破了一个根深蒂固的工程管理假设：Brooks法则告诉我们”向一个已经延期的软件项目加人，只会让它更延期”。但在Harness Engineering模式下，这个铁律失效了。因为新加入的工程师不是在”同步认知”和”协调接口”，而是在设计新的缰绳——每一条缰绳都是一个独立的Agent执行轨道。
“Throughput increased as the team grew.”
更值得关注的是时间维度的变化。Codex Agent可以连续工作超过6小时处理一个任务，而且很大一部分工作是在工程师睡觉时完成的。这意味着开发不再是”人醒着的时候才发生”的事情。一个24小时不间断的工程流水线，被正式接入了生产环境。
范式转换：从”写代码”到”设计环境”
Harness Engineering的核心哲学只有一句话：
“Humans steer. Agents execute.”
人掌舵，Agent执行。 六个英文单词，划出了一条清晰的分界线。
传统软件工程中，工程师的工作是”写代码”——把需求翻译成精确的机器指令，一行一行地敲出来。Harness Engineering模式下，工程师的工作变成了三件事：定义意图、设计环境、构建反馈回路。
“定义意图”意味着你不再告诉机器”怎么做”，而是告诉机器”要什么”。这需要一种新的表达能力——不是编程语言的精确性，而是对产品目标的清晰描述。
“设计环境”是整个范式的关键。OpenAI的实践堪称范本：AGENTS.md作为知识入口，配合渐进式披露（progressive disclosure）让Agent按需深入上下文。Chrome DevTools Protocol解决UI可观测性，临时本地全栈环境充当用完即弃的验证沙箱。
“构建反馈回路”则意味着工程师的角色从”生产者”变成了”审查者”和”校准者”。PR Review从强制逐步走向可选，Agent与Agent之间开始直接对话。人在这个循环里的位置，从”齿轮”变成了”方向盘”。
谁在狂欢，谁该焦虑？
这套范式会最先惠及哪些人？
第一波受益者显然是产品驱动的小型团队。3到7个人的团队配上Codex级Agent，完全有能力挑战传统需要20人以上才能承接的项目范围。创业公司的组织形态将发生根本性变化——”全栈工程师”的定义不再是一个人懂前后端，而是一个人能驾驭多条Agent执行轨道。
第二波是企业级遗留系统改造。大量的企业内部系统因文档缺失、原始开发者离职而变成”无人敢碰”的黑箱。传统做法是花大价钱找人逆向理解代码。在Harness Engineering范式下，Agent可以承担大部分的探索、理解和重新实现工作，人只需要定义”改造后的系统应该长什么样”。
但硬币的另一面同样真实。
初级开发者的生存空间正在被急剧压缩。 过去，切页面、写CRUD、调API是程序员入行的必经之路。如果Agent能以十分之一的时间、持平的质量完成这些工作，”写代码”就不再是职业护城河。能定义意图、设计Agent协作框架、判断产出质量的工程师，才是新范式下的稀缺资源。
软件外包行业可能面临结构性冲击。按人头计费的商业模式，在”0行人类代码”面前失去了解释力。
连锁反应：工程管理的重构
Harness Engineering不仅改变了”怎么写代码”，更将彻底改写”怎么管理写代码的人”。
首先，Code Review的定位发生根本变化。OpenAI在博客中明确表示，他们正在逐步将人工Review从必选项推向可选项，让Agent之间互相Review。这意味着传统的”知识传递→人工审查→批准合并”流程，正在被”意图描述→Agent执行→Agent互审→自动合并”替代。工程经理的工作重心从”看代码”转向”看产出”和”看Agent行为”。
其次，招聘标准将被迫重构。当”3年React经验”这种标准不再有效时，企业需要寻找的是”善于分解复杂问题””能精准表达需求””熟悉Agent能力边界”的人。这种能力画像，和过去二十年软件行业建立起来的人才评估体系几乎无法对接。
第三，文档文化迎来复兴。AGENTS.md的出现不是偶然。当Agent成为主要执行者，清晰、结构化、可被机器理解的项目知识就变得至关重要。一个写好了AGENTS.md的仓库，Agent可以自主导航和贡献；一个没有的仓库，Agent就像盲人摸象。文档从”最好有”变成了”必须有”，而且它服务的首要读者不再是人类。
远眺：缰绳之后是什么？
如果将Harness Engineering视为软件工程进化的一个中间站，那么前方已经隐约可见下一个站台。
当Agent能自主定义子目标、设计验证策略、相互协商接口时，”缰绳”的粒度将不断加粗。人类工程师可能从”每条轨道一个方向盘”退化为”只设总方向，其余交给Agent联邦”。
按目前的演进速度，未来两年内”亲手写生产代码”很可能从常态变成例外。这种转变的速度，甚至可能超过从瀑布到敏捷的过渡——因为它不是管理方法论的变化，而是生产力工具发生了数量级的跃迁。
但有一个问题始终悬而未决：当整个系统由数十个Agent合作构建，没有一个人完整理解每一行代码时，出了问题谁来负责？可解释性、可审计性、责任归属——这些问题不会因为效率提升而自动消失。
最后的缰绳在自己手里
OpenAI用一篇博客和一款产品，向世界展示了一场硬核实验的结果。这不再是PPT上的愿景，不是Demo视频里的魔法，而是已经发生的工程现实。
但Harness Engineering这个词本身就暗含了答案：”缰绳”的另一端是人。Agent跑得再快、写得再多、工作时间再长，方向依然由人定义。区别只在于——你是那个握着缰绳的人，还是那个被缰绳牵着走的人。
软件开发正在经历的不是一次工具升级，而是一次”从马车到汽车”级别的范式转换。唯一确定的是，司机需要的技能组合，和车夫完全不同。
— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn
