在过去五个月中，我们的团队一直在进行一项实验：构建和交付一款内部软件产品的内部测试版，且没有一行手动编写的代码。该产品拥有内部日常用户和外部α测试人员。它发布、部署、故障和修复。不同之处在于，每一行代码——应用逻辑、测试、CI配置、文档、可观测性和内部工具——都是由Codex编写的。我们估计，构建这个产品的时间大约是手动编写代码所需时间的十分之一。人类引导，代理执行。我们故意选择了这个限制，以便构建出必要的内容，从而将工程加速提高几个数量级。我们有几个星期的时间来交付最终达到一百万行代码的产品。为了做到这一点，我们需要理解当软件工程团队的主要工作不再是编写代码，而是设计环境、指定意图并建立反馈环路，以使Codex代理能够进行可靠工作时，会发生什么变化。本文讲述了我们通过一个代理团队构建全新产品所学到的知识——什么地方出现了故障，什么事情积累了影响，以及如何最大化我们唯一真正稀缺的资源：人类的时间和注意力。我们从一个空的git代码库开始。第一次提交到空代码库是在2025年8月底。最初的框架——代码库结构、CI配置、格式规则、包管理器设置和应用框架——是由Codex CLI使用GPT-5生成的，依赖于一小组现有模板的指导。甚至最初的AGENTS.md文件，该文件指导代理如何在代码库中工作，也是由Codex编写的。系统没有预先存在的人类编写的代码作为锚。从一开始，代码库就由代理塑造。五个月后，代码库内的代码量大约有一百万行，涵盖应用逻辑、基础设施、工具、文档和内部开发工具。在此期间，大约打开并合并了1500个拉取请求，只有三名工程师在推动Codex。对于每位工程师而言，平均每个工作日处理3.5个拉取请求，令人惊讶的是，随着团队人数增长到现在的七名工程师，产出率还在增加。重要的是，这并不是为了输出而输出：该产品已被数百名内部用户使用，包括每日的内部重度用户。在整个开发过程中，人类从未直接贡献过任何代码。这成为团队的核心理念：不再手动编写代码。重新定义工程师的角色 缺乏人类手动编码引入了一种不同类型的工程工作，专注于系统、框架和杠杆。早期的进展比我们预期的要慢，并不是因为Codex无能，而是因为环境规格不足。代理缺乏为实现高层次目标所需的工具、抽象和内部结构。我们工程团队的主要工作变成了使代理能够进行有用的工作。实际上，这意味着深度优先工作：将更大的目标分解为较小的构建块（设计、代码、审查、测试等），提示代理构建这些块，并利用它们解锁更复杂的任务。当某个任务失败时，解决方案几乎从来不是“努力再试”。因为唯一的进展方式就是让Codex完成这项工作，人类工程师始终介入任务并问：“缺少什么能力，我们如何让代理既可理解又可执行？”人类几乎完全通过提示与系统互动：一个工程师描述一项任务，运行代理，并允许其打开一个拉取请求。为了将拉取请求推进至完成，我们指示Codex进行本地变更审查，要求额外的具体代理在本地和云中进行审查，响应任何人类或代理提供的反馈，并循环迭代，直到所有代理评审者满意（有效地，这是一个拉尔夫·维根循环）。Codex直接使用我们的标准开发工具（gh、本地脚本和嵌入代码库的技能）以获取上下文，而无需人类进行复制和粘贴。人类可以审查拉取请求，但不是必需的。随着时间的推移，我们将几乎所有的审查工作转向让代理之间处理。提高应用可读性 随着代码的产出增加，我们的瓶颈变成了人类的QA能力。因为固定的限制是人类的时间和注意力，我们努力通过使应用UI、日志和应用指标直接可读来增加代理的更多能力。例如，我们使应用根据git工作树可启动，以便Codex能够为每次更改启动并操作一个实例。我们还将Chrome DevTools协议接入代理运行时，并创建了与DOM快照、屏幕截图和导航相关的技能。这使得Codex能够重现bug、验证修复并推理。