📌 本文是「AI 时代的编码新范式」系列的第 8 篇。全系列共 9 篇，基于 43 篇行业文献、学术论文与一线实践报告，探讨 Spec-Driven Development 如何在 AI Agent 时代从边缘实践变为工程的基础设施。每篇可独立阅读。前七篇讲了 spec 为什么重要、怎么写、怎么用、边界在哪里、流程怎么适配。本篇终于来到了那个所有人都在问但没人敢轻易回答的问题：当 Agent 能写代码，工程师还是「写代码的人」吗？
一个新入职开发者的困惑
你刚加入一家公司。第一天，导师带你熟悉流程：早上开站会，领任务，打开终端——然后所有人都在干一件你没想到的事：没人写代码。
你的导师花一上午写了一份 spec，拆成五个子任务，每个子任务有明确的验收标准。然后她启动了三个 Agent 会话，分别处理其中三个子任务。她自己拿第四个，手动跑了一遍测试环境，确认某个 Agent 上次提交的 PR 没有引入回归。第五个任务她标记为「需要设计决策」，留给自己下午想。
午饭时你忍不住问：「我们……不写代码吗？」
她愣了一下，然后笑了：「我已经三个月没写过代码了。但我的产出比以前多了三倍。」
这不是一个假设。2026 年 2 月，Spotify 联合 CEO Gustav Söderström 在财报电话会上说了一句话，整个行业都听见了：「我们最好的开发者从去年 12 月起就没写过一行代码。」 他们用 Claude Code 和内部工具 Honk 编排 Agent——工程师在通勤路上用 Slack 给 Agent 下指令，到办公室之前 Agent 已经把 PR 推过来了。
你的第一反应可能是恐慌：那还要工程师干什么？你的第二反应可能是好奇：如果不写代码，工程师到底在干什么？
这篇文章回答的就是这个问题。
旧角色的消解：当「写代码」不再是核心产出
OpenAI 的内部实验把这件事推到了极端。2025 年 8 月，一个三人工程团队启动了一个新项目——一个内部软件产品的 beta 版。他们给自己定了一条铁律：零行手动代码。所有代码，从应用逻辑到测试到 CI 配置到文档到内部工具，全部由 Codex 生成。
五个月后，仓库里躺着大约一百万行代码，一千五百个 PR。团队从三人扩到七人，平均每个工程师每天 3.5 个 PR。产品有日常内部用户和外部 alpha 测试者。OpenAI 估计，如果手写，需要十倍的时间。
但如果你以为这个团队只是对着终端说「帮我做一个产品」然后去喝咖啡，那就错过了整件事的核心。他们管自己的工作方式叫「harness engineering」——线束工程。他们做的第一件事不是写代码，是让 Codex 自己生成一份 AGENTS.md，告诉 Agent 这个仓库怎么用、规则是什么、文档在哪。他们建了一整套文档体系：结构化的 docs 目录、带验证状态的设计文档、分层的架构文档、按功能域打分的质量文档。任务计划是第一等工件——小的用轻量计划，复杂的用带进度日志和决策日志的 execution plan，全部签入仓库。还有专门的「文档园艺」Agent 定期扫描过时文档，自动提修 PR。
他们用一句话总结自己的角色转变：「Humans steer. Agents execute.」 人类掌舵，Agent 执行。
这句话的分量在于：它不是一句口号，而是五个月、一百万行代码、零行手写的实践总结。如果「写代码」不再是工程师的核心产出，那什么才是？
OpenAI 自己的数据也印证了这个转变。到 2025 年 12 月，公司内部平均工程师的 AI 产出中，99% 的 output token 来自 Codex 而非 ChatGPT——工程师已经从「跟 AI 对话」转向「编排 Agent 执行任务」。到 2026 年 5 月，80.6% 的 Codex 请求对应的是人类需要 30 分钟以上才能完成的工作，70.2% 对应的是一小时以上的工作。工程师不再是写代码的人——他们变成了给 Agent 分配长时程任务、监控进度、审阅产出的人。
新角色的四个维度
如果工程师不再写代码，工程师在做什么？综合 OpenAI 的 harness engineering 实践、Anthropic 的 2026 Agentic Coding Trends Report、以及 BCG 的就业影响分析，答案可以归纳为四个维度。
第一维：设计约束。 Agent 能写任何代码，但不知道哪些代码不该写。OpenAI 团队为此建了一套「机械化的架构强制」——代码库被分成严格的分层依赖流（Types → Config → Repo → Service → Runtime → UI），自定义 linter 在违反时直接阻断构建。这些 linter 本身也是 Codex 写的，但约束的设计是人类的责任。工程师的工作从「写每一行代码」变成了「设计 Agent 必须遵守的边界」。一份好的约束体系让 Agent 的产出天然落在正确方向上——不是每次靠 review 来纠偏，而是从源头就限制了偏的可能性。
第二维：编写 spec。 这是本系列前七篇一直在讲的事。spec 是 Agent 的执行协议——它定义了「做什么」「什么算做对了」「什么不能做」。在 Agent 时代，spec 的地位从「参考文档」升级为「管线输入」。没有 spec 的 Agent 是盲飞的——它可以用默认假设填补你省略的每一个细节，但那些假设几乎不可能是你想要的。写 spec 不是写文档，是给 Agent 建立对齐锚点。
第三维：构建 harness。 这是最新的维度，也是 OpenAI 实验中最核心的发现。harness 不是 spec——spec 告诉 Agent 做什么，harness 给 Agent 工作的环境。OpenAI 团队把 harness 叫「progressive disclosure」——Agent 启动时看到的是一份一百行的目录，而不是一千页的手册，被教会在需要时自己去翻更深层的文档。他们接了 Chrome DevTools Protocol 让 Agent 能截图、读日志、查指标。他们建了「文档园艺」Agent 做自动化维护。整个 harness 的设计决定了 Agent 能跑多快、能跑多远。OpenAI 的原话是：「早期进展比我们预期的慢——不是因为 Codex 不行，而是环境没有被充分指定。」当 harness 建好后，Codex 才飞起来了。
第四维：审阅产出。 这是第七篇讲过的瓶颈所在——当 Agent 产出速度暴增，review 成了新的约束。但 review 的性质也变了。LogRocket 的实验发现，review AI 生成的代码不再是检查「对不对」，而是判断「有没有必要」——AI 系统性地过度防御，写了你不需要的抽象层和边缘处理。Qodo 的调查显示，68% 的高级工程师认为 AI 提升了代码质量，但只有 26% 愿意在没有 review 的情况下直接合并 AI 代码。审阅不再是对抗 bug 的最后防线，而是对 Agent 判断力的校准——你在判断的不是代码有没有错误，而是 Agent 的设计决策是否合理。
四个维度合在一起，工程师的新能力栈是：约束设计 + spec 编写 + harness 构建 + 产出审阅。 没有一个维度是「写代码」。但每一个维度都需要比「写代码」更高的系统级视野。
团队结构的重组：从前后端到 spec/review/harness
当工程师的角色变了，团队结构也得跟着变。
传统的团队按技术栈分工——前端组、后端组、基础设施组。这种分工的隐含假设是：工程师的核心工作是写代码，而代码有不同的技术领域。但当 Agent 能写前端、后端、基础设施的所有代码，这种分工的基础就动摇了。
Anthropic 的 2026 Agentic Coding Trends Report 观察到了一个趋势：工程师正在变得更「全栈」。不是因为每个人突然学会了所有技术栈，而是因为 AI 填补了知识缺口。一个前端工程师可以用 Agent 做后端工作——只要她能写清楚 spec、构建好 harness、审阅得了产出。技术领域的边界在消融。
那新的分工方式是什么？不是按技术栈分，而是按 Agent 工作流中的角色分：
Spec owner 负责把产品需求翻译成 Agent 可执行的 spec。这个人需要对业务有最深的理解——不是技术最深的，是最懂「做什么才有价值」的。在 Anthropic 的报告里，这个角色正在向非技术人员开放：律师、产品经理、运营专家开始用 Agent 直接构建工具，因为「写 spec」不再需要编程能力，需要的是把意图表达清楚的能力。Anthropic 内部的一个案例：一位没有编程经验的律师用 Claude Code 构建了一套自动分流法律问题的工具，把营销审查周期从两到三天缩短到 24 小时。
Review owner 负责审阅 Agent 产出的代码。第七篇讲过，这是新的瓶颈所在。review owner 需要对系统架构有最深的理解——不是写代码最快的，是最能判断「这段代码该不该存在」「这个设计决策合不合理」的。Faros 2026 的数据显示高级工程师的 review 时间暴涨——他们是受冲击最大的人群，但也是价值最高的人群。
Harness owner 负责构建和维护 Agent 的工作环境——文档体系、工具集成、架构约束、自动化测试。OpenAI 的实验证明，harness 的质量直接决定了 Agent 的产出质量。harness owner 是最「元」的角色：他不产出产品代码，他产出的是让 Agent 产出产品代码的基础设施。
这种分工不是理论推演。BCG 2026 年的分析报告指出，AI 正在将工程师的工作从重复性编码转向系统级思维、编排和产品/设计任务——不是消灭工程师这个角色，而是重塑它的内容。Gartner 的数据显示，从 2024 年 Q1 到 2025 年 Q2，多 Agent 系统的咨询量增长了 1,445%——组织已经在围绕 Agent 编排而不是人工编码来重新设计团队结构。
Netguru 的行业分析也观察到同一个趋势：一些工程团队正在从大型 Scrum 团队向更小的 AI 增强交付团队转型。原因很简单——当 Agent 能写代码，协调成本成了最大的开销，而小团队的协调成本远低于大团队。
角色边界在消融
角色重构不只是工程师内部的事——它正在改变「谁有资格写代码」这件事。
Anthropic 的报告里有一个判断：「代码」和「不代码」之间的壁垒正在变得可渗透。 安全团队用 Agent 分析不熟悉的代码。研究团队用 Agent 构建前端可视化。非技术员工用 Agent 做数据分析和流程自动化。在 Legora（一个 AI 法律平台），律师用 Agent 构建自动化工作流，不需要任何工程专业知识。在 Augment Code（一个为基础设施系统构建 AI 开发工具的创业公司），一个企业客户用 Claude 把 CTO 估计需要 4 到 8 个月的项目在两周内完成了。
OpenAI 的数据更直接：非开发者的 Codex 采用率从 2025 年 8 月起增长了 137 倍（个人用户）和 189 倍（组织用户）。法务、财务、招聘部门在 2026 年 4 月前后跨过了 Codex 成为主要工具的临界点。这些不是开发者——他们是领域专家，用 Agent 把自己的领域知识直接变成可运行的代码。
这对工程师意味着什么？不是被替代——而是工程师的独占价值在转移。当非技术人员能写 spec 并让 Agent 实现，「把需求翻译成代码」不再是工程师的护城河。工程师的新护城河是那四个维度：约束设计、harness 构建、产出审阅、系统级判断。这些是领域专家做不了的事——它们需要的是对软件系统的深层理解，不是对某门编程语言的熟练度。
Spotify 的案例把这件事讲得很清楚。他们的「最好的开发者」不写代码了——但他们在做什么？在 Slack 上给 Claude Code 下指令，审阅 Agent 推过来的 PR，决定哪些合并哪些打回。他们的价值不在「写」上，在「判」上。一个能在通勤路上用手机给 Agent 下对指令、到办公室审完 PR 就合并的人，同时编排着多个 Agent 并行推进——产出远超传统工程师单兵作战的模式。
大厂已经在用组织结构投票
这不是一个小团队的实验——整个行业都在用组织结构调整来投票。
2025 年 1 月，Microsoft CEO Satya Nadella 宣布组建 CoreAI——一个新的工程部门，整合了 Dev Div、AI Platform 和 CTO Office 的关键团队。使命是什么？「构建端到端的 Copilot 和 AI stack，让一方的和三方的客户都能构建和运行 AI 应用和 Agent。」Nadella 说了一句话概括这个重组的本质：「三十年的变化正在被压缩到三年里。」
这不是跟随潮流——这是承认「谁做什么工作」的本质变了。当 Microsoft 把开发者工具部门和 AI 平台部门合并，它说的不是「AI 是新工具」，而是「开发本身变成了 AI 编排」。
OpenAI 的内部数据更激进。到 2026 年 6 月，研究部门（Research）的 Codex 使用量中位数是 2025 年 11 月的约 50 余倍。整个公司 85% 的 output token 来自 Codex。工程师不再用 AI 辅助写代码——他们在用 AI 替代写代码，自己专注于掌舵。
Rakuten 的案例展示了另一个维度：Claude Code 在 vLLM（一个大型多语言开源推理引擎库，据 Rakuten 官方材料称含约 1250 万行代码，但该数字存在争议——独立核查认为被夸大了约 20 倍）中，七小时自主完成了一个复杂的技术任务——激活向量提取方法的实现，与参考方法相比数值精度达 99.9%。这不是「辅助编码」——这是 Agent 独立完成了一个需要深度领域知识的工程任务，人类工程师的角色是定义任务和验证结果。
这些信号合在一起指向一个判断：工程师的角色重构不是未来式，是进行时。 它已经发生在 OpenAI、Spotify、Microsoft、Rakuten——以及无数还没有公开分享的团队里。
从演员到导演
把所有线索收在一起，一个画面浮现出来。
传统工程师是演员——在舞台上表演，每个动作自己来。你的价值在于你的演技：代码写得好不好、算法实不实现得了、bug 修得快不快。你的产出是你写的代码。