前两天我Zuo了一件有点儿出格的事：刚“敲”完的代码直接删了。

原因hen简单，就是觉得写出来总感觉不对劲，逻辑绕来绕去，读起来费劲。以前遇到这种情况，我通常会咬牙切齿地去重构。但这次我直接用了git restore命令，然后转头就让AI帮我 “从零开始”。

Zui让我印象深刻的，倒不是AI又“变魔术”似的写出了一份Neng运行的代码，而是我删掉那段代码时那种释然的心情：我竟然完全没有负罪感和不舍。

回想一下以前这简直不可思议。我们过去几十年一直把“源代码”视为公司的宝贵资产、团队的心血结晶、个人的得意之作。现在呢？代码似乎不再那么重要了丢了也不会让人心疼。

这不禁让人思考：Ru果代码的价值降低了那么写代码的人还会受到重视吗？

图灵奖得主 Leslie Lamport 有一次精彩的演讲，题目是 "Programming ≠ Coding"。

他毫不含糊地指出：hen多人以为自己是在进行编程，实际上只是在进行编码而Yi。 Programming 是深入思考问题本质、精心设计算法和抽象模型；而 Coding 仅仅是将这些抽象概念用具体的编程语言实现出来。

Ru果把这个观点再深入一层进行剖析，我们Ke以构建一个三层模型：

**Engineering :** 负责构建可 、可靠且易于维护的系统架构和基础设施。

**Programming :** 专注于解决问题本质、设计高效算法以及创建清晰的抽象模型。

**Coding :** 将编程设计转化为具体可执行的代码实现。

过去和现在“主战场”Yi经发生了转移:

过去：Coding → Programming → Engineering 

现在：Engineering → Programming → Coding 

Lamport 还说过一句非常精辟的话：

“你不可Neng通过geng好的编码把代码量减少到十分之一；你只Neng通过geng清晰的架构Zuo到这一点。”

当AI大幅降低 Coding 的边际成本之后一个显而易见的问题浮出水面：那 Programming 层和 Engineering 层又该如何定义呢？我们应该用什么新的标准来衡量它们的价值？

这时一些尘封Yi久的记忆突然涌上心头。

一些曾经在软件工程书籍中被反复提及、但在业务高速发展时期常常被忽略的概念重新焕发了生机。

比如 Design by Contract——这是 Bertrand Meyer 在设计 Eiffel 语言时提出的理念 。 它强调软件组件之间的协作关系应该通过可验证的接口规范 来明确表达 ，典型的形式包括前置条件、后置条件 和不变式。

用geng简洁的一句话来概括就是：先定义规则——先把边界条件写清楚 ，再谈具体的实现细节 。

这种思路甚至Ke以 到系统级的设计中 。 上文提到的 Leslie Lamport 所提出的 TLA+ ， 就是利用数学化的规范来描述分布式系统、并发等复杂场景下的全局契约 ， 并提前验证诸如“数据一致性”、“并发死锁” 等组件级契约难以覆盖的系统级逻辑漏洞 。 DbC 和 TLA+ 的本质dou是 “先确定规则 ，再开始实施 ” 。

为什么类似的方法在过去没有成为普遍实践呢 ？ 或许是因为现实存在的种种限制 ： 实现成本高昂 、交付时间紧迫 、组织规模不断扩张 。 让大家先撰写规范 、先进行形式化建模 —— 这在短期内kan起来似乎是 “额外的投入 ” 。

Fred Brooks 在他的经典著作No Silver Bullet 中区分了两种类型的复杂性:

本质复杂性: 来源于问题本身的固有难度

偶然复杂性: 来源于人为选择的技术或方法导致的问题

AI降临之后, 我们需要重新评估这种分类:

AI来了之后：本质复杂性依旧存在；偶然复杂性被大幅度降低

"契约" 可靠无虞 ！

业务变化快/迭代快/代码可替换性强/ AI 写得Zui多/大家基本dou在这一层工作。通用Neng力沉淀/ 组件库 /框架 /中间件 /变化变慢/开始强调稳定性与兼容性/出现一些未来会被叫Zuo“底层”的新基架人。runtime /编译器 /OS /协议栈/变动极少/但一动就可Neng是系统级影响/hen多公司可Nengdou没一个这样的人。