每次我们让编写软件变得更容易，最终我们编写的软件量都会呈指数级增长。

当高级语言取代汇编语言时，程序员并没有减少代码量——他们编写了数量级更多的代码，解决了以前在经济上不可能解决的问题。当框架抽象掉底层管道时，我们并没有减少产出——我们构建了更雄心勃勃的应用程序。当云平台消除了基础设施管理时，我们并没有缩减规模——我们为那些从未有理由建立服务器机房的使用场景启动了服务。

@levie 最近用杰文斯悖论作为框架，阐述了为什么这种模式即将以我们前所未见的规模重演。这个论点之所以引起共鸣，是因为它正在我们的开发者工具中实时上演。每个人最初都会问“这会取代开发者吗？”，但只需观察实际发生的情况。采用这些工具的团队并不总是缩减工程人员规模——他们扩大了产品覆盖范围。那个只能维护一个产品的三人初创公司现在能维护四个。那个只能尝试两种方法的企业团队现在尝试七种。

被消除的约束不是能力，而是启动新事物所需的激活能。想想你一直推迟的那个内部工具，因为“需要某人两周时间，而我们抽不出人手”？现在只需要三小时。那个你一直推迟的重构，因为风险/回报计算不划算？现在计算方式刚刚改变了。

这很重要，因为软件工程师处于独特的位置，能够理解即将发生的事情。我们以前看过这部电影，只是在更小的领域里。每一个抽象层——从汇编到C语言，再到Python，再到框架，再到低代码——都遵循相同的模式。每一个都曾被认为意味着我们需要更少的开发者。每一个反而使我们能够构建更多的软件。

我认为值得更多关注的部分是：被降低的门槛不仅仅是关于更快地编写代码。它关乎那些用软件解决变得经济可行的各类问题。想想你公司里所有不存在的内部工具。不是因为没有人想到它们，而是因为投资回报率计算从未达到门槛。那个能让一个团队效率提高10%但需要一周时间构建的自定义仪表板。那个需要专业知识才能解锁洞察的数据流水线。那个能平滑工作流程但涉及三个不同系统的集成。

这些项目未能通过成本效益分析，不是因为效益低——而是因为成本高。将成本降低“10倍”，突然间你就有了大量可行的项目。这正是AI辅助开发正在发生的事情，而且它将比之前的转型更加戏剧性，因为我们正在使以前“不可能”的工作成为可能。

当你考虑到每个新工具都会创造对更多工具的需求时，二阶效应变得非常有趣。当我们让构建Web应用变得更容易时，我们不仅得到了更多的Web应用——我们还得到了整个监控工具、部署平台、调试工具和测试框架的生态系统。每一个都催生了它们自己的生态系统。复合效应是非线性的。

现在将这种逻辑应用到我们正在降低准入门槛的每个领域。每一个被解锁的新能力都会创造对支持能力的需求。每一个变得可行的工作流程都会创造对相邻工作流程的需求。经济可行的覆盖范围向各个方向扩展。

特别是对于工程师来说，这改变了我们选择从事工作的计算方式。目前，我们被训练得对我们构建的内容极其挑剔，因为我们的时间是稀缺资源。但是，当构建成本急剧下降时，限制因素变成了想象力、“品味”和判断力，而不是实现能力。技能从“在给定约束下我能构建什么？”转变为“在某种程度上约束已经消失的情况下，我们应该构建什么？”

这里的元观点是，我们一直在犯同样的预测错误。每次我们让某件事变得更高效时，我们都预测这意味着那件事会减少。但效率提升并不会减少需求——它们揭示了以前因经济原因无法满足的潜在需求。煤炭。计算。云基础设施。现在，知识工作。

这种模式如此一致，以至于举证责任应该转移。与其问“AI智能体会减少对人类知识工作者的需求吗？”，我们应该问“我们即将看到知识工作产出量级增加多少？”

对于软件工程师来说，这是我们已经成功应对过几次的相同转型。那些蓬勃发展的开发者不是那些抵制更高级抽象的人；他们是那些利用这些抽象来构建更雄心勃勃系统的人。同样的逻辑现在也适用，只是规模更大。

真正的问题是，我们是否准备好迎接一个瓶颈从“我们能构建这个吗？”转变为“我们应该构建这个吗？”的世界。这是一个根本不同的问题空间，它需要根本不同的技能。

我们即将发现当知识工作的成本下降一个数量级时会发生什么。历史表明，我们（或许）不会做更少的工作——我们会发现我们一直在知识工作上投资严重不足，因为做所有真正值得做的事情成本太高。

悖论不在于效率创造了丰裕。悖论在于我们不断对此感到惊讶。