近日 OpenAI 在自家的博客里面分享了他们过去五个月的秘密实验：一个由三名工程师组成的小团队，完全依靠 Codex AI 代理，在未手写任何一行代码的情况下，开发出包含 100 万行代码的完整产品 。 这也标示了传统以软件工程师（或一整个团队）进行开发大型项目的概念有了根本性转变：从「人类编写代码」到「人类驾驭 AI 编写代码」。 OpenAI 将这种新模式称为Harness Engineering（驾驭工程），其核心哲学可以用一句话概括：「Humans steer， agents execute」（人类掌舵，代理执行）。
100 万行代码的诞生：一个完全由 AI 生成的产品
这个实验始于2025年8月底，OpenAI团队从一个空的Git储存库开始，使用Codex CLI配合GPT-5，仅凭一小组现有模板生成了初始架构：包括储存库结构、CI配置、格式化规则、套件管理器设置和应用框架。 甚至指导代理如何在储存库中工作的 AGENTS.md 文件，本身也是由编码撰写的。
五个月后，这个储存库包含了约100万行代码，涵盖应用逻辑、基础设施、工具、文件和内部开发者工具。 在这段期间，约有1,500个Pull Request被打开并合并，而驱动Codex的工程师团队仅从最初的3人扩展到7人。 这意味着平均每位工程师每天产出3.5个PR，且随着团队扩大，产能持续增加。
更重要的是，这不只是为了产出而产出。 该产品已有数百名内部用户，包括每日使用的内部重度用户。 整个开发过程中，人类从未直接贡献任何代码：这成为团队的核心哲学：没有人工编写的代码。
Harness Engineering：重新定义工程师的角色
「Harness」一词源自马具（手纲、鞍等），象征着人类对马匹力量的驾驭与控制。 在 Harness Engineering 的框架下，工程师不再是被称为「码农」的代码生产者，而是系统的设计师和环境的建构者。
OpenAI团队发现，早期的进展比预期慢，并非因为编码能力不足，而是因为环境定义不够充分。 代理缺乏完成高层次目标所需的工具、抽象概念和内部结构。 因此，工程团队的主要工作变成「让代理能够有效工作」，这意味着深度优先的工作方式：将大目标分解为更小的构建模块（设计、代码、审查、测试等），提示代理构建这些模块，并用它们来解锁更复杂的任务。
当出现问题时，解决方案几乎从不是「再试一次」。 因为唯一能取得进展的方式是让编码完成工作，人类工程师总是会深入任务并自问：「缺少什么能力，我们如何让它对代理来说既清晰又可执行？」
人类几乎完全通过提示与系统互动：工程师描述任务，运行代理，并允许它打开 Pull Request。 为了推动 PR 完成，他们指示 Codex 在本地审查自己的更改，请求额外的特定代理审查（本地和云端），回应任何人类或代理给出的反馈，并在循环中迭代直到所有代理审查者都满意。 随着时间推移，他们几乎将所有审查工作推向代理对代理的处理。
让应用程序对 AI 可读
随着代码产出增加，瓶颈变成了人类 QA 能力。 因为固定约束是人类时间和注意力，团队致力于通过让应用程序 UI、日志和应用指标本身直接对 Codex 可读来增加代理的能力。
例如，他们让应用程序可以按 Git worktree 启动，这样 Codex 可以为每次更改启动和驱动一个实例。 他们还将Chrome DevTools Protocol接入代理运行时，并创建用于处理DOM快照、截图和导航的技能。 这使Codex能够重现错误、验证修复，并直接推理UI行为。
他们对可观察性工具也做了同样处理。 日志、指标和追踪通过本地可观察性堆栈暴露给编码，该堆栈对于任何给定的工作树都是短暂的。 代理可以在完全隔离的应用版本上工作——包括其日志和指标，这些在任务完成后会被拆除。 代理可以用 LogQL 查询日志，用 PromQL 查询指标。 有了这些上下文，「确保服务启动在 800 毫秒内完成」或「这四个关键用户旅程中的任何跨度不超过两秒」这样的提示变得可行。
团队经常看到单个编码运行在单个任务上工作长达六小时以上：通常是在人类睡觉的时候。
架构强制与品味约束
仅靠文件无法保持完全由代理生成的代码库的一致性。 通过强制执行不变量而非微观管理实现，他们让代理快速交付而不破坏基础。 例如，他们要求编码在边界处解析数据形状，但不规定具体如何实现（模型似乎喜欢 Zod，但他们没有指定那个特定库）。
代理在具有严格边界和可预测结构的环境中最有效，因此他们围绕严格的架构模型构建应用程序。 每个业务领域被划分为一组固定的层，具有严格验证的依赖方向和有限的可允许边缘。 这些约束通过自定义 Linter（当然也是 Codex 生成的！ ）和结构测试机械地强制执行。
这种架构通常要等到有数百名工程师时才会采用。 但对于编码代理，这是早期的先决条件：约束是允许速度而不衰减或架构漂移的关键。 在人类优先的工作流程中，这些规则可能感觉苛刻或限制。 对于代理，它们成为倍增器：一旦编码，它们就同时应用于所有地方。
代码吞吐量改变合并哲学
随着Codex的吞吐量增加，许多传统的工程规范变得适得其反。 储存库以最小化的阻塞合并门槛运行。 Pull Request 生命周期短暂。 测试不稳定通常通过后续运行解决，而非无限期阻塞进度。 在代理吞吐量远超人类注意力的系统中，修正成本低，等待成本高。
这在低吞吐量环境中是不负责任的。 在这里，这通常是正确的权衡。
完全自主的临界点
随着更多开发循环被直接编码到系统中：测试、验证、审查、反馈处理和恢复，储存库最近跨过了一个有意义的阈值，Codex 可以端到端地驱动新功能。
给定单个提示，代理现在可以：验证储存库的当前状态; 重现报告的错误; 录制展示失败的视频; 实现修复; 通过驱动应用程序验证修复; 录制第二个展示解决方案的视频; 打开 Pull Request; 回应代理和人类反馈; 检测和修复构建失败; 仅在需要判断时升级给人类; 合并更改。
这种行为严重依赖于该储存库的特定结构和工具，不应假设在没有类似投资的情况下能够泛化：至少，目前还不行。
熵与垃圾回收：维护 AI 生成的代码库
完全代理自主也引入了新的问题。 Codex 会复制储存库中已经存在的模式：即使是不均匀或次优的模式。 随着时间推移，这不可避免地导致漂移。 最初，人类手动解决这个问题。 团队曾经每周五（一周的20%）清理「AI slop」。 毫不奇怪，这无法扩展。 相反，他们开始将所谓的「黄金原则」直接编码到储存库中，并建立了一个定期的清理流程。 这些原则是机械的、有主见的规则，保持代码库对未来代理运行清晰和一致。
这就像垃圾回收。 技术债务就像高利贷：几乎总是最好以小的增量持续偿还，而不是让它复合然后痛苦地一次性解决。 人类品味被捕捉一次，然后在每行代码上持续强制执行。 这也让他们能够在每天基础上捕捉和解决不良模式，而不是让它们在代码库中传播数天或数周。
观点：工程师的未来在哪里？
OpenAI 的 Harness Engineering 实验显示了一个令人不安但不可避免的未来：单纯的代码编写能力正在快速贬值。 当AI可以在睡觉时产出3.5个PR，当100万行代码可以在五个月内由三名工程师「监督」完成，传统软件工程师的价值主张必须重新定义。
但这不意味着工程师会被淘汰。 相反，这意味着工程师必须向价值链上游移动。 未来的工程师不再是「写代码的人」，而是「设计系统的人」：他们定义目标、建立约束、设计反馈循环，让 AI 代理能够在这些边界内自主运行。
这种转变类似于工业革命时期工匠向工程师的转变。 当机器可以制造零件时，人类的角色变成设计机器和优化流程。 同样，当 AI 可以编写代码时，人类的角色变成设计编程应该做什么、如何组织、以及如何验证它是否正确。
Harness Engineering 的真正启示不在于技术细节，而在于组织哲学：当 AI 执行时，人类必须学会更好地掌舵。 这需要一套全新的技能：系统思维、抽象设计、质量标准定义、以及对 AI 能力的深刻理解。
对于正在学习编程的学生，对于职业生涯中的工程师，对于整个科技产业，OpenAI的实验是一个明确的信号：适应或被淘汰。 Harness Engineering 不是未来的愿景，而是已经到来的现实。
