本文为视频内容简介，由 AI 整理生成。
AI 能在几分钟内写完过去需要几天的代码，我们还需要 Clean Code、测试、架构和 Agile 吗？
Matt Pocock 和 Uncle Bob 的这次对谈给出了一个很有意思的答案：这些基本功不但没有过时，反而比过去更重要。因为 Agent 写代码的速度越快，制造混乱的速度也越快；而且复杂代码不只会拖慢人，同样会让 Agent 反复修改、彼此打架，最后陷入无法收拾的循环。
这期视频真正讨论的不是 AI 能不能写代码，而是当代码不再主要由人来写，我们应该如何保证软件仍然可靠。
AI 也会被烂代码拖垮
Uncle Bob 最初使用 Agent 时，发现它虽然写得快，却总会留下一些需要人清理的混乱。如果不及时处理，而是继续让它添加功能，代码会越来越糟，Agent 也会越来越慢。
更麻烦的是，它会开始原地打转：修好一个问题，又无意中破坏另一个；再去修第二个问题，又把第一个改坏。代码复杂到一定程度后，Agent 和人一样会失去对系统的掌控，甚至直接放弃任务。
这戳破了一个常见幻想：AI 并不会让技术债自动消失。它或许比人能够承受更高的复杂度，但这个阈值依然存在。生成速度越快，如果缺少约束，抵达这个阈值的速度也越快。
Clean Code 不是为了审美
为什么要在意代码是否干净？并不是因为短函数、好命名和整洁结构看起来更优雅，而是因为 Clean Code 的本质是控制复杂度。
复杂度决定了修改一段代码时需要同时理解多少事情，也决定了一个局部变化会牵动多少其他部分。人受工作记忆限制，Agent 受上下文和注意力限制。两者的承受阈值可能不同，但面对失控的复杂度，结果并没有本质区别。
因此，Clean Code 在 AI 时代并不是一种审美偏好，而是在保护 Agent 的工作环境。清晰的命名、有限的函数复杂度、明确的职责，让 Agent 更容易理解和修改代码；混乱的结构则会让它不断生成局部合理、整体错误的补丁。
视频中也提到了一个值得注意的调整：给人设定的复杂度阈值未必需要原样套给 Agent。Agent 的短期记忆更强，可以处理稍大的函数。但变化的是阈值，不是控制复杂度这个目标。
Prompt 是建议，工具才是约束
面对 Agent 写出的坏代码，很多人的第一反应是继续扩充 Prompt：告诉它如何做 TDD、如何写 Clean Code、函数应该多长、哪些规则不能违反。最后往往会得到一份五页甚至十页的说明。
Uncle Bob 一开始也这样做，但他发现模型会把这些规则当成“指导意见”。随着上下文增长，早期指令被挤到中间，重要性逐渐降低，Agent 最终还是会忽略它们。
他的解决办法，是尽可能把主观要求变成确定性检查。不要只对 Agent 说“降低复杂度”，而是运行工具测量圈复杂度；不要只说“写好测试”，而是用覆盖率和 Mutation Testing 验证；不要只说“遵守模块边界”，而是让依赖检查直接拒绝越界的实现。
Prompt 负责说明方向，工具负责判定结果。只要检查不通过，Agent 就必须继续修改。规则不再依赖模型“记得遵守”，而是成为它无法绕过的关卡。
AI 让昂贵的工程实践变得可行
视频中最具体的两个例子是 CRAP 指标和 Mutation Testing。
CRAP 将测试覆盖率与圈复杂度结合起来，用一个指标找出高风险函数。Mutation Testing 则故意改变程序中的条件和运算符，再运行测试：如果代码被改坏后测试仍然通过，就说明测试并没有真正保护这段行为。
Uncle Bob 在 2000 年前后就尝试过这些方法，但当时运行一次 Mutation Testing 可能需要整夜，修复结果也要耗费大量人工，因此很难放进日常开发流程。Agent 改变的并不是这些方法的原理，而是它们的经济性。Agent 足够快，也不介意重复而乏味的工作，可以分析未被杀死的变异、补齐测试，再持续降低复杂度。
这可能是 AI Coding 一个被低估的价值：它不只是更便宜地生成代码，也让过去“理论上很好、实践中太贵”的质量手段重新变得可用。
多 Agent 的价值是隔离上下文
Uncle Bob 将工作拆给多个短生命周期的 Agent：一个把人的需求转成验收场景和 QA 步骤，一个负责编码和单元测试，一个清理实现并检查复杂度，最后一个运行 Mutation Testing，毫不留情地补上测试漏洞。
这里的重点并不是 Agent 越多越好，而是让每个 Agent 只有单一职责和一致的上下文。Agent 完成任务后退出，下一个 Agent 从干净的上下文开始，能够减少上下文持续积累造成的方向偏移。
当然，这也有代价：每个新 Agent 都要重新理解项目，启动成本更高。因此任务需要足够聚焦，交接结果也必须可验证。多 Agent 本质上仍然是一个经典的软件工程问题：如何用边界隔离复杂度。
架构决定 Agent 需要理解多少代码
测试可以证明行为没有被破坏，却不能自动保证模块划分合理、API 设计清晰。Uncle Bob 仍然会检查模块之间如何通信，并把允许的依赖关系写成可执行的架构规则。一旦 Agent 违反规则，就必须反转依赖、引入接口或拆分模块。
好的模块拥有较小的接口，把大量细节隐藏在内部。Agent 只需要理解接口和测试，就可能正确使用模块，而不必把所有实现都塞进上下文。相反，如果模块边界模糊，一次小改动也需要理解整个系统，再大的上下文窗口都会被迅速消耗。
所以，架构在 AI 时代不是前期画出来的一张漂亮图，而是持续限制信息传播范围的机制。模块边界越清楚，人和 Agent 完成一次修改所需要理解的内容就越少。
不要把人的仪式强加给 Agent
Uncle Bob 是 TDD 的坚定支持者，但他并不要求 Agent 严格模仿人类的 red、green、refactor 节奏，一次只写一行测试，再写一行实现。TDD 是为了适应人的认知方式而形成的纪律，Agent 拥有不同的短期记忆和工作方式，机械复制这套动作未必有意义。
视频里有一句很值得记住的判断：不要把为人设计的纪律强加给 Agent，但应该把人的价值观施加给它。
也就是说，Agent 可以先完成一个函数再补测试，可以承受比人更高一点的复杂度，但最终仍然必须做到行为可验证、结构可理解、依赖受控制。TDD 和 Clean Code 需要调整的是执行方式与阈值，而不是它们保护的软件质量。
修改越便宜，越应该快速迭代
AI 也带回了一个古老的争论：既然 Agent 执行得很快，我们是不是应该先写一份极其完整的规格，再让它一次实现，也就是重新走向 Waterfall？
Uncle Bob 的实验并不顺利。Agent 很喜欢写计划，也能把计划写得漂亮而详尽；但执行到一半，人就会发现前期不可能想清所有问题，只能停下来、修改计划，再让 Agent 重新开始。计划软件的困难，从来不只是写计划所需的时间，而是我们无法提前消除所有不确定性。
他用盖房子做了一个比喻：如果移动楼梯、交换厨房和客厅的位置，每次只需要一美元，你还会花大价钱要求建筑师一开始就给出完美方案吗？当修改成本趋近于零，更合理的方式是做一点、获得反馈、重新组织，再继续做一点。
这正是 Agile 的核心。AI 降低了实现和返工的成本，因此更适合短周期迭代，而不是用更长的规格文档复活 Waterfall。设计仍然重要，只是它需要伴随反馈持续发生，而不是试图在第一行代码出现之前全部完成。
新人要学习战略，而不只是战术
当 Agent 接手越来越多具体编码工作，新人可能会失去通过亲手写代码积累经验的机会。但视频的判断并不是“以后不必学代码”，而是要分清战术编程和战略编程。
调用 API、补齐语法、实现一个函数，更接近战术；决定系统如何拆分、哪里应该设置边界、怎样验证行为、什么时候复杂度已经失控，更接近战略。后者通常只能在真实开发、犯错和反馈中逐渐形成。
因此，新人使用 AI 时不能只观察结果是否能跑。要去理解测试为什么有效，为什么这个依赖方向更合理，为什么 Agent 会在某种结构里反复失败。AI 可以让反馈来得更快，但建立判断力这件事仍然无法外包。
小结
每一次编程抽象层级上升，都会有人认为旧的基本功已经不再需要。从机器码到汇编，从汇编到高级语言，现在又从代码走向模型。但复杂度、反馈、边界和质量从未消失。
AI Coding 改变的是工程师与代码的距离。我们可能不再逐行编写、逐行 review，而是更多地设计 Agent 的工作流程，在代码外围建立测试、复杂度指标、Mutation Testing 和架构检查。代码生成变便宜后，真正重要的是能否让快速生成的代码长期保持可修改。
这篇文章只提取了对谈中最值得继续思考的几条线索。完整视频还讨论了 Agent 工作流的具体实践、规格的作用，以及程序员如何逐步远离语法层，推荐观看原视频。