AI 让写代码变便宜，但让软件工程变得更重要

很多人对 AI Coding 有一个误解：

AI 会写代码了，所以软件工程没那么重要了。

我现在越来越觉得，恰好相反。

Agentic Coding 时代，软件工程不是变轻了，而是变成了整个 AI Coding 系统的控制面。

AI 降低的是“生成代码”的成本，不是“构建正确软件”的成本。

代码可以越来越快地被生成，但需求是否清楚、上下文是否准确、测试是否充分、review 是否有效、发布是否可回滚、出了问题谁负责，这些问题不会因为 Agent 会写代码就自动消失。

相反，它们会被放大。

DORA 2025 的 AI-assisted software development 报告把 AI 称为一种“放大器”：它会放大组织已有的优势，也会放大组织已有的问题。真正的收益不是来自工具本身，而是来自底层组织系统是否能承接 AI 带来的变化。(Dora^[1])

这句话很关键。

因为它意味着：

AI Coding 的竞争，不是单纯比谁用的模型更强，而是比谁的软件工程系统更强。

一、AI 没有消灭软件工程，它只是消灭了“写代码很贵”这个前提

过去，软件开发里有一个隐含前提：

写代码是贵的。

所以我们会小心设计，小心讨论，小心排期。因为一旦开始实现，成本很高。

但现在，Agent 可以很快生成代码、改代码、补测试、跑命令、修报错。初始代码的生成成本被极大压低。

这当然是好事。

但问题是，代码变便宜以后，错误代码也变便宜了。

错误需求可以更快地被实现。

错误上下文可以更快地被固化。

错误架构可以更快地扩散。

没有 review 的代码可以更快地进入主干。

没有验证的功能可以更快地上线。

这就是 Agentic Coding 的核心悖论：

代码越容易生成，软件工程越不能缺席。

DORA 的另一份关于 GenAI in Software Development 的研究提到，AI 采用率每提升 25%，与交付吞吐下降 1.5%、交付稳定性下降 7.2% 存在相关性。DORA 给出的解释是，AI 让开发者更快生成代码，但也可能导致更大的 batch size，进而让 review 更慢、系统更不稳定。(Dora^[2])

这不是说 AI 没用。

而是说：局部编码效率提升，不等于系统级软件交付能力提升。

这正是软件工程要解决的问题。

二、Agentic Coding 的底层问题，不是“不会写代码”

很多团队第一次用 AI Coding，会把问题理解成：

Agent 写得还不够好。

于是他们不断换模型、调 prompt、换工具、研究更强的 IDE。

这些当然重要，但不是最底层的问题。

Agentic Coding 的底层问题不是“不会写代码”，而是下面这些工程问题：

1. 意图不清   → Agent 很认真地解决了错误问题。2. 上下文不准   → Agent 基于错误材料做了错误判断。3. 步子太大   → 一次改太多，人类 review 跟不上。4. 没有反馈环   → 代码看起来对，但没有测试、构建、运行时证据。5. 自我相信太早   → Agent 很快宣布完成，但没有经过独立审查。6. 完成声明无证据   → “已经修好”只是自然语言，不是工程事实。7. 交付不可逆   → 没有 feature flag、rollback、监控，一上线就是豪赌。

所以，Agent 软件工程最后一定会收敛成一条主线：

Clarify → Context → Specify → Slice → Implement → Verify → Review → Ship → Learn

中文说就是：

澄清意图→ 治理上下文→ 写清规格→ 小步切片→ 实现功能→ 验证证据→ 独立审查→ 可控发布→ 复盘沉淀

这不是流程洁癖。

这是 AI Coding 时代的基本安全带。

三、未来工程师的核心责任，不是亲手写每一行代码

在过去，工程师的核心产出经常被理解成“代码”。

但在 Agentic Coding 时代，这个理解会变得不够准确。

未来工程师的责任会从：

我亲手写代码。

变成：

我设计一个系统，让 Agent 在正确意图、正确上下文、正确边界、正确反馈环里，小步、可验证、可回滚地写代码。

这是一种更高层的软件工程责任。

你不一定亲手写每一行代码，但你必须对这些事情负责：

- 目标是不是清楚？- 非目标有没有写明？- Agent 看的上下文是不是正确？- 任务有没有被切成可验证的小步？- 测试是不是先失败、再通过？- 运行时证据有没有留下？- review 是不是由 fresh context 完成？- 发布有没有 feature flag 和 rollback？- 这次踩坑有没有写回工程系统？

换句话说：

Agent 可以生成代码，但工程师不能外包责任。

Linux kernel 关于 AI coding assistants 的政策就非常明确：AI agent 不能添加 Signed-off-by，只有人类可以认证 Developer Certificate of Origin；人类提交者必须 review 所有 AI 生成代码、确保 license 合规，并对贡献承担全部责任。(Linux Kernel Documentation^[3])

这就是未来 AI Coding 的责任边界：

AI can assist.Human owns the contribution.

AI 可以辅助。

人类负责签字。

人类负责理解。

人类负责合并。

人类负责上线。

人类负责后果。

四、AI Coding 最大的新债务：Verification Debt

过去我们经常讲 technical debt，技术债。

AI Coding 时代会多一个更危险的债：

Verification Debt，验证债。

也就是：

AI 写得太快，人类验证跟不上，没有充分验证的代码进入系统。

Sonar 2026 State of Code 相关调查显示，使用过 AI coding 工具的开发者中，72% 每天都在使用；开发者报告当前 42% 的提交代码已经由 AI 生成或显著辅助，并预计到 2027 年这一比例会到 65%。但与此同时，96% 的开发者并不完全相信 AI 生成代码在功能上正确，只有 48% 表示总是在提交前检查 AI-assisted code。Sonar 将这个现象称为 verification gap。(SonarSource^[4])

这组数据很刺眼。

大家都不完全信 AI。

但很多人也没有总是验证 AI。

这就是最危险的地方。

不是 AI 一定写错。

而是 AI 写出来的东西经常“看起来像对的”。

它有函数名。

有注释。

有测试。

有错误处理。

有很自信的解释。

但它可能解决了错问题，漏了边界条件，绕过了权限判断，或者引入了安全漏洞。

Veracode 2025 GenAI Code Security Report 测试了 100 多个大模型生成的代码，发现 45% 的代码样本未通过安全测试并引入 OWASP Top 10 漏洞，其中 Java 任务的安全失败率达到 72%。(Veracode^[5])

所以，AI Coding 时代最重要的一句话不是：

让 Agent 写完。

而是：

让系统证明它真的对。

五、Agentic Coding 需要五层工程框架

如果把未来 AI Coding 的软件工程框架抽象一下，我认为可以分成五层。

1. Intent Layer       意图层2. Context Layer      上下文层3. Verification Layer 验证层4. Governance Layer   治理层5. Learning Layer     复利层

这五层，才是 Agentic Coding 真正的工程底座。

1. Intent Layer：意图层

意图层解决的问题是：

我们到底要做什么？不做什么？什么算成功？什么算失败？

Agent 最可怕的能力之一，是它能非常认真地实现一个错误需求。

所以在动手前，必须先澄清：

- 目标是什么？- 非目标是什么？- 用户是谁？- 成功标准是什么？- 失败标准是什么？- 哪些约束不能破？- 哪些事情现在不做，未来再做？

这一步看起来慢，但其实是在省后面十倍的返工。

模糊需求进入 Agent，出来的不是软件，是幻觉的固化版本。

2. Context Layer：上下文层

上下文层解决的问题是：

Agent 应该知道什么？不应该知道什么？哪些材料是当前任务真正相关的？

AI Coding 很容易出现两种上下文问题。

第一种是上下文不足。

Agent 没看到关键规则、核心源码、错误日志、业务术语，于是靠猜。

第二种是上下文污染。

Agent 看到太多无关材料，注意力被稀释，反而抓不住关键点。

所以需要给 Agent 准备一个 Context Pack：

- AGENTS.md / CLAUDE.md- 项目规则- 业务术语表- 当前 spec / issue / PRD- 相关源码入口- 相关测试- 错误日志- 复现步骤- 禁止修改区域- 本次任务的边界

OpenAI Codex 官方文档说明，Codex 会在开始工作前读取 AGENTS.md，用全局指导和项目级覆盖来建立一致的任务期望。(OpenAI Developers^[6]) Anthropic 的 Claude Code 文档也强调，CLAUDE.md 会在每次会话开始时加载进上下文窗口，并建议指令具体、简洁、结构化。(Claude API Docs^[7])

这说明一个趋势：

上下文管理正在变成新的软件工程基本功。

不是给 Agent 越多越好。

而是给它正确的、必要的、结构化的上下文。

3. Verification Layer：验证层

验证层解决的问题是：

我们如何知道它真的对？

这层是 Agentic Coding 的生命线。

未来的工程规则应该非常简单：

No evidence, no claim.

没有证据，不许声明完成。

验证不只是跑单元测试。它至少包括三类证据：

自动化证据：- unit tests- integration tests- type check- lint- build- security scan运行时证据：- curl 输出- CLI 输出- 浏览器截图- Playwright 测试- 日志- 数据库状态- metrics行为证据：- bug 复现前后对比- 边界条件覆盖- 错误路径验证- 权限验证- 性能验证

Simon Willison 在 Agentic Engineering Patterns 里强调 red/green TDD：先写测试，确认它失败，再实现到通过。这样做的重点不是形式上的 TDD，而是先定义成功，再让 Agent 实现。(Simon Willison’s Weblog^[8])

对 Agent 来说，这比传统开发更重要。

因为 Agent 很擅长写“看起来像测试”的测试。

但如果这个测试没有经历过失败阶段，它可能根本没有证明任何东西。

所以一个好的 Agent 开发流程应该要求：

1. 先写失败测试；2. 说明它为什么失败；3. 写最小实现；4. 展示测试通过；5. 再跑完整 check；6. 留下运行时证据。

这才叫工程事实。

4. Governance Layer：治理层

治理层解决的问题是：

谁负责？谁 review？什么条件下可以 merge？什么条件下可以 ship？

Agentic Coding 最容易制造一种幻觉：

既然代码是 AI 写的，那责任是不是也可以模糊一点？

答案是不行。

软件工程责任不能被 AI 吸收。

ACM/IEEE Software Engineering Code of Ethics 里有一条非常适合 AI 时代重读：软件工程师只有在有充分根据相信软件是安全的、符合规格、通过适当测试，并且不会损害生活质量、隐私或环境时，才应该批准软件。(ACM^[9])

注意这里的关键词：

safemeets specificationspasses appropriate tests

安全。

符合规格。

通过适当测试。

这三件事在 AI 时代没有变得不重要。

它们只是从“人类写代码后的责任”，扩展成了“人类接受 AI 代码后的责任”。

治理层需要明确：

- 哪些变更必须 human review？- 哪些变更需要 fresh-context review？- 哪些变更需要 security review？- 哪些变更必须有 architecture review？- PR gate 是什么？- ship gate 是什么？- 谁最终 sign off？

AI 可以帮你写 PR 描述。

AI 可以帮你 review diff。

AI 可以帮你找 bug。

但 AI 不应该成为责任主体。

最终承担工程责任的，必须是人和组织。

5. Learning Layer：复利层

复利层解决的问题是：

这次踩坑，怎么防止下次再踩？

很多团队用 AI Coding 的方式是一次性的：

让 Agent 修一个 bug。修完。结束。

这当然有效，但没有复利。

真正的工程化应该是：

让 Agent 修一个 bug。补一个测试。更新一条规则。沉淀一个 playbook。把经验写回 AGENTS.md / CI / PR checklist。

也就是说，每一次失败都应该让系统变强。

可以问几个固定问题：

- 这次 Agent 误解了什么？- 哪条规则能防止下次再犯？- 哪个测试应该提前捕获这个问题？- just check 是否要加新命令？- AGENTS.md 是否要更新？- PR 模板是否要新增检查项？- 是否需要新增一个 bug pattern？

这一步，是从“使用 Agent”进入“工程化 Agent”的分水岭。

大多数人只是不断调教一次性 Agent。

真正强的团队，会不断升级自己的工程系统。

六、最终流程：Clarify → Context → Specify → Slice → Implement → Verify → Review → Ship → Learn

把上面的内容压缩成一个流程，就是：

Clarify→ Context→ Specify→ Slice→ Implement→ Verify→ Review→ Ship→ Learn

每一步都有明确的工程责任。

Clarify：澄清

先问清楚：

做什么？不做什么？为什么做？成功标准是什么？失败标准是什么？

不要让 Agent 在模糊意图里自由发挥。

自由发挥适合头脑风暴，不适合直接改生产代码。

Context：上下文

只加载正确上下文：

规则、术语、spec、相关源码、测试、错误输出、运行环境、约束边界。

上下文不是越多越好。

上下文要准。

Specify：规格

把自然语言需求变成可验证规格：

输入是什么？输出是什么？状态如何变化？错误路径是什么？权限边界在哪里？兼容性要求是什么？

没有规格，测试也会变得虚。

Slice：切片

一次只做一个可验证行为。

不要让 Agent 一次性重构半个系统。

小 PR。

小 commit。

小 diff。

小步快跑。

Implement：实现

实现阶段应该尽量遵循：

Red → Green → Refactor

先让测试失败，再让测试通过，最后再整理代码。

不要让 Agent 先写一大坨代码，再倒推测试。

Verify：验证

验证不是一句“测试通过”。

验证要有证据：

- 测试输出- 构建输出- 浏览器截图- curl 结果- 日志- 数据库状态- 安全扫描

没有证据，不许声明完成。

Review：审查

至少需要三类 review：

fresh-context review：让一个没参与实现的上下文重新看。adversarial review：专门找反例、漏洞、边界条件。spec compliance review：逐条对照规格，确认没有偏离需求。

Agent 自己说“我检查过了”，不能算最终 review。

Ship：发布

发布必须可控。

feature flagstaged rolloutmonitoringalertingrollbackPR gateship gate

没有回滚，就不要发布。

Learn：沉淀

结束后把经验写回系统：

AGENTS.mdplaybooktestsCIPR templatebug archivedecision record

让下一次更稳。

这就是工程复利。

七、AI Coding 时代的三条铁律

如果只能保留三句话，我会保留这三句：

Evidence before claim.Review before merge.Rollback before ship.

中文就是：

没有证据，不许声明完成。没有审查，不许合并。没有回滚，不许发布。

这三句话，比任何复杂 prompt 都重要。

因为它们定义的不是“怎么让 AI 写代码”，而是“什么样的 AI 代码可以进入工程系统”。

八、结语：工程控制才是稀缺能力

未来，代码会越来越便宜。

样板代码会越来越便宜。

CRUD 会越来越便宜。

重构、补测试、写脚本、查文档，都会越来越便宜。

但这并不意味着软件工程变得不重要。

恰好相反。

当代码生成成本下降到接近零时，真正稀缺的能力会变成：

定义正确问题的能力；提供正确上下文的能力；设计验证反馈环的能力；控制变更风险的能力；承担工程责任的能力；把失败沉淀成系统能力的能力。

AI Coding 的终局，不是“人人都能随便写软件”。

而是：

有软件工程框架的人，能够安全地放大 AI；没有软件工程框架的人，只是在更快地制造混乱。

所以我越来越相信：

AI makes coding cheaper,not software engineering cheaper.

AI 让写代码变便宜。

但没有让构建正确软件变便宜。

Agentic Coding 时代，代码生成不是稀缺能力。

工程责任和工程框架，才是。