构建软件的成本是否刚刚下降了90%？

本文信息来源：martinalderson

我从事专业软件开发已近 20 年。我经历了许多变革——SaaS（软件即服务）的诞生，向移动应用的全面转移，围绕区块链的肆意炒作，以及那个永远在许诺低代码会让开发者失业的预言。

如今，随着代理式编程（agentic coding）的出现，经济逻辑已发生剧烈变化，它将彻底重塑软件开发行业（乃至更广泛的经济领域）。2026 年将会让许多人措手不及。

在我之前的文章中，我探讨了为什么我认为评估指标（evals）未能捕捉到某些重大飞跃，但自那以后的深思（以及最近的亲身经历）让我确信，我们正处于一个世代级转变的早期阶段。

交付成本

我的开发生涯始于开源技术真正开始爆发的时期——当时很明显，这是定制软件构建成本的第一次重大转变。我依然清晰记得 SQL Server 或 Oracle 那些令人瞠目的高昂费用——正因如此，我最初实际是使用 MySQL 起步的，它使你能够构建定制化的网络应用程序，而无需承担五六位数的年度数据库许可费用。

从那时起，我们经历了云计算时代（我其实对其能否节省成本持保留意见，但让我们宽容一点，假设它确实在初期节省了一些资本支出），以及最近我所认为的“复杂性时代”。现在的软件工程已经变得——在我看来，往往是不必要的——复杂，人们纷纷涌向劳动密集型的模式，如测试驱动开发（TDD）、微服务、超级复杂的 React 前端和 Kubernetes。我绝不认为过去几年我们在成本上有过什么显著的下降。

然而在我看来，AI 智能体（AI Agents）将极大地降低软件开发的劳动力成本。

那么，这 90% 的成本节约究竟源自何处？

在 2025 年初，我对许多 AI 编程工具都抱有极大的怀疑态度——实际上，对于其中的很多工具，我现在依然如此。许多平台感觉就像是换汤不换药的低代码工具（如 Lovable、Bolt 等），或者是添加了一些半吊子（往往还挺烦人）自动补全功能的 VS Code 魔改版。

以公司内部工具的一般开发项目为例。假设数据建模已经在一定程度上完成了，而你需要实现一个 Web 应用程序来管理这些小组件（widgets）。

在过去，你需要一小队人马着手搭建 CI/CD（持续集成/持续交付），构建数据访问模式，并开发核心服务。接下来通常要制作一大堆 CRUD（增删改查）风格的页面，或许还有一些供用户查看的仪表盘和图表。最后，你（按理说）还需要编写一些自动化的单元测试/集成测试/端到端测试，以确保系统相对稳固，然后在大约一个月后将其发布。

而且这还仅仅是直接的人力成本。项目中的每一个人都会增加协作的开销。每日站会、工单管理、代码审查、前后端交接，以及等待他人为你扫清障碍。实际写代码的时间往往只占花费时间的一小部分。

使用代理式编程 CLI 工具，只需几小时就能完成几乎所有这些工作。我曾经让 Claude Code 在几小时内为一个相当复杂的内部工具编写了一整套单元/集成测试套件（超过 300 个测试用例）。如果是手动编写，这大概要花掉我，或者是许多我熟知且尊敬的开发者们好几天的时间。

这些代理式编程工具在将业务逻辑规范转化为编写良好的 API 和服务方面，已经变得极其出色。

过去需要一个月才能完成的项目，现在只需一周。思考的时间大致没变——但是实施的时间大幅缩减了。而且随着团队规模变小，你还能获得与“布鲁克斯定律”（Brooks's Law）相反的效应：沟通成本不再随着人数增加而膨胀，反而彻底消失了。少数几个人突然之间就能实现以前十倍的产出。

潜在需求

乍看之下，这对软件开发行业来说似乎是个极其糟糕的消息——但经济学理论告诉我们并非如此。

杰文斯悖论（Jevons Paradox） 指出，当某种产品的生产成本降低时，我们并不会仅仅花更少的钱去做同样数量的事。以电灯照明为例：虽然蜡烛和煤气灯的销量下降了，但总体产生的人造光却远远更多了。

如果我们将这一理论应用于软件工程，可以从供给和需求的角度来思考。目前存在着极大的潜在软件需求。我相信每个组织都有成百上千个用于追踪重要业务流程的 Excel 表格，如果将它们转化为 SaaS 应用程序，效果会好得多。假设他们从代理公司那里获得的报价是将其中一个转化为应用程序需要 5 万美元——那么只有最必要的项目才能达到这个门槛。如果在 5 千美元这个价位（凭借一名不错的开发者 + AI 工具）——突然之间，需求量就会大增。

领域知识是唯一的护城河

那么我们该何去何从？目前，让人类“监护”智能体（agent）仍然具有巨大的价值——检查它们的工作、建议方法并避免糟糕的路径。完全放任自流的“YOLO 氛围式编程”（YOLO vibe coding）很快就会导致极其混乱的局面，但只要有人类介入其中，我认为你可以非常迅速地构建出质量极高的软件。

这便让真正掌握这项技术的开发者能够极其高效地解决业务问题。他们的领域和行业知识将成为巨大的杠杆——知道为一个项目做出怎样的最佳架构决策，清楚该使用哪个框架，以及了解哪些库的效果最好。

再加深对业务领域的理解，感觉传说中的“10倍效率工程师”真的出现了。同样，将业务领域专家与积极进取的开发人员以及这些工具相结合，也会产生极其强大的力量。我认为这种情况会变得相当普遍——我们将看到的不再是业务专家加一群开发人员组成的“小分队”，而是一两个人之间构成的更加紧密的搭档关系。

这种组合让你能够以极快的速度进行迭代，软件变得几乎像是一次性用品——如果方向错了，就把它扔掉，利用学到的经验教训重新开始。这需要思维方式上的重大转变，但真正的苦工在于概念性思考 ，而不是敲代码。

别措手不及

Agent 和模型仍在飞速进步，我认为目前的基准测试并未能真正捕捉到这一点。Opus 4.5 似乎能够应对长达 10 到 20 分钟的交互会话而不至于完全跑偏。我们才刚刚看到投入到 GB200 GPU 上的数千亿美元资本支出所产生的初步成果，而且我确信，更新的模型很快就会让这些成果显得完全过时。

然而，我和许多软件工程师交谈过，他们确实在抗拒这种变化。我听过太多次同样的反对意见——LLMs 犯错太多，它无法理解 [framework]，或者它实际上并不能节省任何时间。

这些断言正迅速变得完全站不住脚，这让我想起了 2007 年那些对 iPhone 嗤之以鼻的桌面工程师。我想我们都知道结局如何——网络变得更好了，手机运行速度大大提升了，移动操作系统也变得非常强大。

在我看来，工程师们需要真正拥抱这种变化。这不会在一夜之间发生——大公司总体上仍然非常落后，迷失在供应商审批和管理架构的官僚网络中，这使得它们在面对较小的竞争对手时极其脆弱。

但是，如果你在较小的公司或团队工作，并且有权使用这些工具，你就应该去使用。你的工作将会发生变化——但软件行业历来如此。只是这一次，变化的步伐或许会比任何人预期的都要快。2026 年即将来临。

我经常听到一种反对意见，认为 LLMs 仅适用于从零开始的新项目（greenfield projects）。我必须强烈反驳这一点。我曾花费大量时间试图理解那些已有三年以上历史、且原作者都已离职的代码库。Agent 让这项工作变得轻松多了——它能解释代码的功能、定位 Bug 并提出修复建议。相比于接手一个由水平堪忧的承包商在三年前留下、毫无测试且类与方法乱成一团的“意大利面式”代码库，我宁愿接手一个由优秀工程师配合 Agent 编写的代码库。