软件开发成本是否骤降90%?

在小型团队中,布鲁克斯定律的反向效应显现:沟通开销非但不会随人数增长而增加,反而消失殆尽。少数人突然能实现数量级的产出提升。

我从事专业软件开发近二十年,见证了诸多变革——SaaS的诞生、移动应用的全面兴起、区块链的疯狂炒作,以及低代码将取代开发者的永恒预言。

如今,智能编程技术正以惊人的速度重塑行业经济格局,它将彻底颠覆软件开发产业(乃至更广阔的经济领域)。2026年将令许多人措手不及。

在之前的文章中,我深入探讨了为何认为 评估报告遗漏了若干重大飞跃,但此后反复思量(加之近期实践)使我确信:我们正处于一代人仅遇一次的变革初期。

元素周期表

交付成本的演变

我入行时恰逢开源技术爆发式增长——这无疑是定制软件开发成本结构的首轮重大变革。至今仍记得SQL Server或Oracle令人咋舌的费用,因此我最初选择MySQL,它确实能让开发者构建定制化网络应用,而无需承担五六位数的年度数据库许可成本。

此后云计算兴起(我认为其成本节约效果存疑,但姑且承认其能节省部分初期资本支出),而近来我更感受到复杂性时代的来临。软件工程变得——在我看来往往是无谓地——日益复杂,人们争相采用测试驱动开发、微服务、超复杂的React前端和Kubernetes等劳动密集型模式。我确信过去几年间成本并未显著降低。

图0:软件开发成本是否骤降90%?

然而在我看来,AI智能体能大幅降低软件开发的劳动力成本。

那么90%的成本节约究竟从何而来?

2025年初我对多数AI编程工具持强烈怀疑态度——至今仍对其中许多保持质疑。许多平台不过是包装华丽的低代码工具(如Loveable、Bolt等),或是添加了半实用(却常惹人烦)的自动补全功能的VS Code分支。

以企业内部工具的普通项目为例。假设数据建模已基本完成,你需要开发一个管理组件的Web应用。

以往流程是:先由小团队搭建CI/CD环境,构建数据访问模式和核心服务。接着通常要开发大量CRUD风格的页面,可能还需制作用户端仪表盘和图表。最后(理想情况下)添加自动化单元/集成/端到端测试确保系统稳定,约一个月后发布。

这仅是直接人力成本。项目中每位成员都带来协调开销:每日站会、工单管理、代码审查、前后端交接、等待他人解除阻塞。实际编码往往只占时间的一小部分。

几乎所有这些工作,借助智能编码命令行工具都能在数小时内完成。我曾让Claude Code在短短几小时内为复杂的内部工具编写了完整的单元/集成测试套件(300+个测试用例)。若由我或许多我敬重的开发者手动编写,则需耗费数天。

基于智能体的编程工具在将业务逻辑规范转化为优质API与服务方面已达到极致水平。

原本耗时一个月的项目如今仅需一周。思考时间基本不变——实现时间却大幅压缩。在小型团队中,布鲁克斯定律的反向效应显现:沟通开销非但不会随人数增长而增加,反而消失殆尽。少数人突然能实现数量级的产出提升。

潜在需求

表面看来,这对软件开发行业似乎是极坏的消息——但经济学告诉我们事实并非如此。

杰文斯悖论指出:当生产成本降低时,我们不会仅满足于以更低成本维持原有产量。以电灯为例,尽管蜡烛和煤气灯销量下滑,但整体人造光源却大幅增加。

若将此原理应用于软件工程,需关注供需关系。软件领域存在着海量潜在需求。我相信每个组织都有数百甚至数千张Excel表格在追踪重要业务流程,若能转化为SaaS应用将高效得多。假设某机构报价5万美元将其中一项流程开发成应用——只有核心需求才会通过审核。但若成本降至5千美元(聘请合格开发者+AI工具),需求量将瞬间激增。

图1:软件开发成本是否骤降90%?

领域知识是唯一的护城河

那么我们该如何应对?目前仍需人类“看护”智能体——检查其工作成果、指导方法选择并规避错误路径。纯粹的YOLO式编程很快就会陷入混乱,但若有人类介入,我认为能以极快的速度构建出卓越品质的软件。

这使得真正掌握该技术的开发者能高效解决业务难题。他们的领域知识与行业洞察成为巨大杠杆——既能做出最优架构决策,又清楚该选用何种框架与库。

若再叠加业务领域的理解,便真切感受到传说中的十倍工程师已然降临。同样地,业务领域专家与积极进取的开发者结对协作,辅以这些工具,将形成极其强大的组合——我认为这种模式将日益普及:取代由业务专家和开发团队组成的“小队”,我们将看到更紧密的双人协作模式。

这种组合能实现极快的迭代速度,软件几乎成为可抛弃品——若方向错误,便弃之重来,将经验教训融入新方案。这需要相当大的思维转变,但真正的艰辛在于概念性思考而非敲代码。

警惕意外突发

智能体和模型仍在快速进化,而基准测试似乎未能充分反映这一趋势。Opus 4.5似乎能跟随长达10-20分钟的会话而不偏离主题。数百亿美元投入GB200 GPU的成果才刚显现,相信新模型很快会让现有技术彻底过时。

然而我接触过太多抵制变革的软件工程师。那些陈词滥调的反对意见我已听腻——大型语言模型错误率过高、无法理解[特定框架]、根本节省不了时间。

这些论断正迅速沦为彻头彻尾的谬误,令我联想到2007年那些轻视iPhone的桌面端工程师。结局众所周知——网络性能飞跃提升,手机处理速度突飞猛进,移动操作系统变得功能强大。

我认为工程师必须主动拥抱变革。这种转变不会一蹴而就——大型企业普遍仍滞后于时代,深陷供应商审批和管理架构构成的官僚迷宫,使其极易受到小型竞争对手的冲击。

但若你在小型企业或团队工作且有权使用这些工具,就该立即行动。你的工作将发生改变——软件本就不断演进。只是这次变革的速度或许会超出所有人的预期。2026年正在逼近。

我常听到一种质疑:大型语言模型只适用于全新项目。对此我坚决反对。我曾耗费大量时间解析三年以上历史的代码库,而所有编写者早已离职。智能助手能极大简化这一过程——解释代码功能、定位缺陷、提出修复方案。与其继承由质量堪忧的承包商编写、三年前弃守的代码库(毫无测试覆盖,类与方法如意大利面般纠缠),我宁愿接手由智能助手协同优秀工程师维护的代码仓库。

元素周期表抱枕

本文文字及图片出自 Has the cost of building software just dropped 90%?,由 WebHek 分享。

共有{663}精彩评论

  1. > 我认为工程师们必须真正拥抱变革。

    我尝试过积极参与。真的努力过。我并非网页开发者或游戏开发者(更偏向机器人技术和嵌入式系统)。我尝试过用Vibe编写网页应用和游戏,结果相当无趣。无法修改细节让我感到沮丧。记得有次游戏角色总卡在虚拟墙上,我反复求助Cursor修复,结果越改越糟。还有次用数据库搭建前后端分析数千条拉取请求评论,程序突然卡死却查不出原因,Cursor也帮不上忙。整个过程让我感觉自己越来越笨。

    下次开发网页应用时,我自学了Flask和基础JS,发现效率提升显著——虽非开发初期,但后期调试阶段尤为明显。

    AI在检索文档和错误信息方面帮了大忙,本质上是强化版的谷歌搜索和Stack Overflow替代品,但让它主导开发流程对我毫无用处。