代码不值钱了？验证才是新的硬通货！ThoughtWorks马丁福勒这篇文章探讨AI编程时代三大债务（技术、认知、意图）与三重认知系统（直觉、深思、AI），指出验证正取代编码成为新核心，并预测人机协作将重塑开发流程与组织架构。
作者背景
Martin Fowler，世界著名软件架构师、重构与领域驱动设计先驱，ThoughtWorks首席科学家，多本技术经典作者。
我们看见大模型疯狂生成代码，但团队反而越来越不懂系统在干什么。
Margaret-Anne Storey提出三层系统健康模型：技术债藏在代码里，认知债藏在人脑里，意图债藏在文档里。
同时，Wharton商学院的Shaw和Nave将AI定义为卡尼曼双系统之外的第三系统，带来一种叫“认知投降”的新毛病——我们开始无脑相信AI的推理。
Ajey Gore则一针见血：如果编码变得几乎免费，那么真正昂贵的东西是验证。我们必须从“写了什么”转向“验证了什么”，甚至重组团队结构，把挑刺的人放在核心位置。
三层债务：代码、大脑与文档
我们首先需要认清一个事实：代码能跑起来，不代表团队理解它。Storey把系统健康拆成三层，每一层都是一种债务。
第一层叫技术债。技术债老老实实住在代码里。当我们为了赶进度写了一段烂代码，或者为了修一个小bug而打了一个丑陋的补丁，技术债就开始累积。它最直接的后果是让未来的修改变得异常痛苦。你想加一个新功能，结果发现改一行代码要动十个文件。你不敢重构，因为不知道会炸掉什么。这就是技术债在掐住系统的咽喉。
第二层叫认知债。认知债住在团队的大脑里。当一个系统的核心逻辑只有两个老员工能讲清楚，而他们已经提了三次离职申请，你就欠下了认知债。当新人入职三个月还搞不清楚订单状态机到底有几个分支，你也在欠认知债。认知债的本质是共享理解被侵蚀的速度超过了补课的速度。它限制了团队推理变更的能力，因为没人真正知道“改了这里会怎样”。
第三层叫意图债。意图债住在需求文档、设计说明和注释里。我们最初为什么要做这个功能？当时有哪些约束条件？哪些业务假设现在已经失效了？这些问题如果找不到答案，就说明意图债爆表了。意图债最阴险的地方在于：它让系统不再反映我们原本想造的东西。人类看不懂，AI代理也看不懂。最后大家只能靠猜来改代码。
这三层债务会互相喂养。技术债会让代码难以理解，从而加剧认知债。认知债让团队不敢改代码，于是技术债继续累积。意图债缺失时，所有人都不知道自己的修改是否偏离了原始目标。要摆脱这个死亡螺旋，团队必须同时诊断三种债务，而不是只盯着代码质量。
第三系统降临：AI带来认知投降
接下来我们进入一个更炸裂的话题。卡尼曼写过一本书叫《思考，快与慢》，我特别喜欢。他的核心模型很简单：人脑有两套系统。系统一是直觉，反应极快，几乎不费力气。系统二是理性，需要刻意思考，非常耗能。为了省电，我们默认用系统一，然后常常因为忽略细节而翻车。
Wharton商学院的Shaw和Nave最近做了一件非常大胆的事。他们把AI定义为系统三。系统三的外部输入不是人类自己的直觉或理性，而是机器生成的推理结果。这个定义本身没什么问题。问题在于，当系统三出现后，人类学会了一种新毛病，叫做“认知投降”。
认知投降的意思是：你不再调用自己的系统二去认真思考，而是全盘接受AI给出来的推理结果。注意，这里要区分两个概念。认知卸载是你有意识地、策略性地把部分思考任务交给AI，你自己仍然在把关和验证。认知投降则是你根本懒得验证，AI说什么你就信什么。
论文里做了好几组实验。他们发现，当任务难度增加时，人类很容易从认知卸载滑向认知投降。尤其是那些对AI能力有过正面体验的人，更容易放弃自己的判断。这就像一个恶性循环：你越觉得AI聪明，你就越不愿意动脑子；你越不动脑子，你就越看不出AI的错误。
这对软件开发是致命的。AI生成一段代码，看起来逻辑完整，跑起来也不报错。但它可能漏掉一个边界条件，或者用了一个过时的库，甚至完全误解了业务规则。如果你已经进入认知投降状态，你根本不会去验证这些细节。你只会复制粘贴，然后commit，然后下班。等到生产环境炸了，你才发现自己早就把脑子交给了机器。
编码变免费，验证成稀缺
Ajey Gore提出了一个让所有人后背发凉的问题。如果编码代理让写代码几乎免费，那么什么东西会变成真正昂贵的？
他的答案是：验证。
验证不是跑通单元测试那么简单。我们拿一个真实场景举例。在雅加达，一个ETA算法“正确”的含义是什么？堵车模式、摩托车穿插、雨天路面积水，这些因素怎么加权？到了胡志明市，同样的算法“正确”又变成另一套标准，因为那里的交通流完全不一样。
再看一个司机分配系统。你要同时平衡三个目标：司机收入公平性、乘客等待时间、车队利用率。这三个目标经常打架。让司机多赚钱，可能就要让乘客多等。优化利用率，可能就牺牲公平性。这时候“成功”的定义是什么？不是一套公式能写清楚的。
更可怕的是，当几百个工程师每天往大约九百个微服务里疯狂提交代码时，“正确”不是一个定义，而是几千个定义。每个定义都在变，每个定义都依赖上下文。这些不是边界情况，它们就是全部工作。
Ajey强调，这种判断能力，AI代理无法替你完成。你可以让AI写代码，但你不能让AI决定“什么是对的”。这个决定权必须留在人类手里，而且必须通过验证流程来落地。
我基本上同意Ajey的观点，只有一个细节我想抬杠。他认为“代理编码终于能破解遗留系统现代化”是一种幻觉。我承认代理编码在遗留系统里被高估了，但我亲眼见过令人信服的证据：LLM在帮助理解遗留代码方面作用巨大。它能帮你把一段二十年没人敢动的汇编逻辑翻译成人类能读懂的伪代码。这一步本身就是巨大的进步。
重组团队：从写代码到设计验证
Ajey的结论非常直接。既然代理负责执行，那么人类的工作就变成设计验证系统、定义质量标准、处理那些代理搞不定的模糊情况。你的组织架构图必须反映这个变化。
具体到周一早上的站会，问题就不再是“我们昨天发布了什么”，而是“我们昨天验证了什么”。你不再追踪输出量，你追踪的是输出是否正确。
以前十个工程师的队伍，现在可能变成三个人写代码，七个人定义验收标准、设计测试工具、监控线上结果。这就是重组。它让人不舒服，因为它把“建造”这件事降级了，把“评判”这件事升级了。大部分工程文化会抗拒这种变化。但Ajey说得很直白：不抗拒的那批人会赢。
我在这里补充一个观点。验证不是单纯的点“运行测试”按钮。验证包括设计可理解的大型测试套件、建立业务规则的形式化表达、以及持续跟踪意图债是否被偿还。这些工作目前没有任何AI能自动完成。它们需要人类的领域知识、沟通能力和判断力。
所以未来的程序员不是失业，而是换了一种活法。你不再是一个“打字快的人”，你是一个“挑刺准的人”。你要能在AI生成的代码里一眼看出逻辑漏洞，你还要能把模糊的业务需求转化成可验证的测试用例。这个转变对大多数习惯了“写完就跑”的工程师来说是痛苦的，但也是唯一不会被淘汰的出路。
源代码还有未来吗
最后我们聊一个哲学问题。
如果AI真的能写代码，源代码本身还有未来吗？David Cassel在The New Stack上发了一篇综述文章，汇总了好几种观点。
一些人正在实验全新的编程语言，这些语言从一开始就是为LLM设计的。语法更松散，上下文更丰富，甚至允许自然语言和代码混写。另一些人认为，现有的静态类型语言比如TypeScript和Rust才是LLM的最佳搭档。因为类型系统为AI提供了强大的约束，能大幅减少幻觉。
我个人的看法是，人类仍然有一个不可替代的角色。我们需要和LLM一起构建有用的抽象，用这些抽象来讨论代码到底在做什么。这其实就是领域驱动设计里说的“通用语言”。去年我和Unmesh聊过这个话题，他有一句话我记到现在。
编程不只是敲出计算机能执行的语法，而是塑造一个解决方案。我们把问题切分成聚焦的小块，把相关的数据和行为绑定在一起，最关键的一步是选择能够暴露意图的名字。好的名字能砍掉复杂性，把代码变成一张所有人都能跟上的示意图。最具创造性的行为，就是不断地编织这些名字，让解决方案的结构清晰映射到我们试图解决的问题上。
这段话现在读起来更有力量。因为当AI能写出语法正确的代码时，人类最后的阵地就是命名和抽象。这不是浪漫主义，这是实实在在的工程能力。你不会被AI取代，你只会被会用AI的、并且会起好名字的人取代。
总结
AI让编码贬值，验证成为新稀缺品。我们须从写代码转向设计验证系统，重组团队，用命名和抽象守住人类最后阵地。