亲爱的读者们：

现在所有人都在谈论AI Agent生成海量代码的能力已经变得多么强大，有人对此兴奋不已，而另一些没那么乐观的人，甚至已经开始讨论自己是不是该考虑换个职业方向了。

其实，写代码从来都不算特别困难，至少，那种勉强能跑起来，但在实际使用中几乎什么该做的事都没做好的代码，并不难写。我也写过不少，但用正确的方法解决真正的问题，总还是要稍微难一点。

不过，Agent确实可以帮上忙，他们可以帮你做调研，可以钻进第三方集成那仿佛永远看不完的文档里，把真正相关的信息整理出来，可以帮你做原型开发，甚至可以逆向工程竞争对手的产品（大嘘）。

多年来，在项目管理上，我一直遵循一条很简单的原则：先消除最大的风险。

比如说，如果你要做一个实时交互平台，而你此前从来没有做过类似的东西，你不会一开始就去做登录、注册和花哨的动画，你应该先从实时交互部分入手，你要先做原型，做MVP，进行快速迭代，而这正是agents可以发挥作用的地方。

现在还有谁会傻到完全不用AI呢？但最终还是得靠你来构建，负责理解架构，重构代码，跟ai争论，这可是要付出血汗和泪水的。

我当然不是在说，我们应该回到用古法编程写程序的日子，我要说的是，AI降低了生成代码的成本，但它并没有以同样的比例降低理解代码、审查代码、维护代码，以及为代码后果负责的成本。

过去，大型代码库里有技术债几乎是不可避免的，而且，代码曾经是昂贵的。一个功能从需求、设计、开发、测试，到最终发布，往往需要几天，甚至几周。也正因为代码生产缓慢而昂贵，团队自然会更加谨慎地思考某种实现到底值不值得写出来。

但今天，情况已经不一定如此。

我们通常会把技术债理解成一些很具体的东西：重复代码、缺失测试、混乱的命名、临时性的解决方案、过时的依赖、糟糕的架构……但这些其实都只是技术债的症状。

技术债真正的问题是：为了今天更快地交付，我们做出了某个局部决策，而这个决策提高了未来修改整个系统的成本。

AI coding agents可以非常高效地做过去很耗人力的事情，比如：

• 重构重复代码
• 更新或迁移依赖
• 给遗留代码补测试
• 清理历史遗留问题
• 批量修改大量文件
• 处理那些因为优先级永远不够高，而在backlog里躺了好几年的维护工作

从这个角度看，AI 确实可能让技术债变得更容易偿还。

但另一种说法则是现在整个代码库本身正在变成一种技术债，因为ai同样让代码生成变得极其便宜。

一个工程师面对一次较大的改动时，可能会犹豫一下，仅仅因为实现成本很高，但现在你可以告诉agent：

“重构这个模块，但不要改变程序逻辑，也不要修改变量名。”

几分钟之后，几十个文件就已经被改掉了。

你可能会想，既然代码这么容易生成，多一点代码又有什么关系呢？

但发展到某个阶段之后，没有人再真正知道完整的业务逻辑到底分布在哪里，没有人知道，一次修改到底需要检查哪些不同的调用链，没有人真正清楚，测试究竟应该覆盖哪些组合情况，新加入的成员开始害怕碰这一部分系统，而每一次修改都可能制造新的问题。

AI 一方面清理技术债，另一方面也制造技术债。

But，技术债并不仅仅意味着代码写得差。很多技术债其实来自当时完全合理的工程决策，有些技术债本质上是当初做出的决定和后来学到的事实之间的差距。

代码库不断增长，需求不断变化，客户开始依赖存在缺陷的功能（恭喜你，现在这个bug正式变成feature了），系统跨团队扩展，团队成员来来去去，依赖项也日渐老化。三年前还完美契合的架构，如今却成了我们前进的绊脚石。

所以，如果技术债本身会随着学习而产生，那么AI虽然可以提高我们实现代码的速度，却不一定能同比提高我们理解现实世界的速度。

以前软件开发比较慢的时候，虽然慢本身不是好事，但它确实带来了一个副作用：它给团队留下了思考和学习的时间。

过去，把一个想法变成复杂系统需要很长时间，而就在这个过程中，我们往往会不断发现：

• 最初的设计其实并不合理
• 某些需求其实根本没有必要
• 用户真正想要的是另一种东西
• 某个技术方案复杂得过头了
• 产品方向可能应该调整

换句话说，实现和学习是同时发生的。

但AI带来了一种新的局面，一个过去可能需要五周开发的系统，现在也许一周，甚至几天之内就能做出来，于是突然之间，我们可能会build得比learn还快。

你可能非常高效地实现了一个后来才发现根本不该这样实现的东西。

你无法创造生产经验，很多工程问题只有到了真实生产环境才能暴露。

例如：

• 多线程问题
• 并发 bug
• race condition
• 特定客户数据触发的问题
• 高流量下才出现的问题
• 月亮的相位（？）

这类知识不是单靠生成更多代码获得的，设计方案乍看之下可能完全合理，但实际应用到实际流量中就会发现问题。实际流量会带来时序问题、竞态条件以及你意想不到的交互。

ai可能会帮你构建一个完全符合预期运行的系统，甚至比人类预判更多潜在风险，但ai与人一样，都没有水晶球。

于是问题变成了：AI为我们节省出来的时间，我们究竟应该拿来做什么？

“AI 让我快了五倍，所以我就生产五倍的东西。”

听起来很棒。

但这样一来，工作流程可能会变成：

build → build → build → build → build → ship → observe → learn → change

我们先构建一大堆东西，一次性把它们全部发布出去，然后直到最后才开始观察用户、理解问题，并调整方向。

比起这个，更好的方式应该是：

build → ship → observe → learn → change → repeat

即：

1. 构建一个小东西
2. 发布出去
3. 观察现实中到底发生了什么
4. 学到一些东西
5. 做出调整
6. 重复这个过程

因此，AI 带来的速度红利，不应该全部用来生产更多代码。实施成本已经大大降低，但是，审查、测试、验证设计决策、安全保障、运维以及从生产环境中吸取经验教训的成本并没有以同样的速度降低。

这里让我想到Brandolini定律：The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.（制造胡说八道很容易，但证明它是胡说八道，往往要花多得多的精力）

即便AI生成的代码本身完全没有问题，认真检查这些代码的时间，也可能远远超过生成它们的时间。

过去，软件开发中最昂贵的环节之一是实现，但现在，agent可以在几分钟内创建一个巨大的PR，要弄清楚它是否应该存在、是否正确安全、是否适合系统以及是否易于维护，仍然可能需要几个小时。

And all of this is happening in an environment that’s now go, go, go.

问题在于，当我们还没有充分了解某件事是否值得投入时间，就把所有的速度都花在了更多的实施工作上。

所以代码生成能力提高，不等于整个软件工程流程的吞吐量同比提高。

生成 → review → QA → security → deployment → operations → customer feedback

如果前面的生成突然变快，而后面所有流程没有变快，整个工程系统就会失衡。

未来，也许我们确实不用再忍受那些存在了很多年的传统技术债， 甚至agent可能持续自动重构、升级依赖、补测试、清理dead code，技术债偿还可能逐渐自动化。

但与此同时，另一种更隐蔽的债务也可能不断膨胀：

我们实现的东西太多，而真正理解的东西太少。

把速度用在学习上#

AI 给我们的速度，应该重新分配。 如果以前一个功能需要五周开发，现在一周就能完成，那不一定意味着接下来四周继续做另外四个功能，也可以意味着第一周做出来，第二周就进入真实环境，然后用剩下的时间找出问题所在，进行修改，然后重新来过。

也就是把ai带来的生产力从更多implementation转向更快feedback。

所以目前，或许我们可以采用更快的实现方式来缩短整个学习周期。

‍