人不写代码，写的是「编码环境」
工程师们完全信任 Codex（基于 GPT5 模型）的编码能力，没有手写任何一行代码。但这不意味着人变得无关紧要——恰恰相反，人力资源从编码本身转移到了更高层的工作：拆解目标、分解任务、构造一个有明确反馈机制的编码环境。
关键细节在于他们处理错误的方式。当 Agent 出错时，团队不会简单地点「再试一次」让它重新生成，而是停下来思考：这次失败是因为缺少哪些 Context？缺少什么工具？反馈机制哪里断了？然后通过调整环境，让 Agent 在下一轮拥有更充分的上下文。
这种思路和 Ralph Wiggum Loop 的工作理念一脉相承——让 AI 在循环中尝试任务，把这一轮的错误作为下一轮的输入，反复迭代直到收敛。开发者的角色从「人在环中」（Human-in-the-loop）变成了「人在环上」（Human-on-the-loop），只需设定目标和质量标准，剩下的交给 AI 自主完成。
这个设计很实用。比起不断调整 prompt 碰运气，建立一个有清晰错误日志和反馈回路的环境，才是真正可复制、可扩展的做法。
多 Agent 协作审查，不强制人类 Review
代码写完不是终点。在他们的流程中，多个 Agent 会负责代码 Review，只有当所有 Agent 都对代码质量满意后，PR 才会被允许合并。这一步并不强制要求人类参与审查。
这意味着从编码到审查，整条链路都可以由 Agent 闭环完成。
给 Agent 地图，而不是操作手册
Context 管理是 Agent 开发中最容易踩坑的地方。他们的经验是：一个庞大的操作手册效果并不好。更有效的做法是给 Agent 一张「地图」——一个简短的概述文件，告诉 AI：
- 项目整体架构是什么
- 去哪里查看各模块代码
- 每个模块的设计理念
- 哪些工作已完成，哪些待完成
简洁、结构化、可导航，远比一份几万字的文档有用。
暴露更多信息，释放更大杠杆
在开发过程中，团队追求把尽可能多的信息暴露给 Agent——会议记录、一致性规范、设计决策等。目标是让 Agent 接手代码时，能够在规范约束下开展工作。
这里有一个值得记住的结论：将更多系统以 Agent 能够直接检查、验证和修改的形式纳入，能够带来更大的杠杆效应。这不仅适用于 Codex，也适用于任何正在处理该代码库的其他 Agent。
Karpathy 此前也表达过类似的观点：未来的系统应该尽可能提供面向 Agent 的 API 和 CLI，让 Agent 能够轻松读取上下文信息，而不是依赖视觉方案或 HTML 解析这种低效的方式。
瓶颈不再是 Token，而是人类注意力
当一个开发工程的吞吐量瓶颈从 Token 产出速度变成了人类注意力时，开发者的定位必须跟着变。不再是写代码、跑测试这些执行层面的事，而是：
- 设计开发环境
- 调整反馈机制
- 制定编码规范
- 帮助 Agent 以更可靠的方式完成开发
对独立开发者而言，这套方法论的核心启示很明确：与其花时间写更好的 prompt，不如花时间搭建更好的 Agent 工作环境——清晰的项目地图、结构化的反馈回路、可机器读取的规范文档。这才是一个人撬动百万行代码的真正杠杆。