ARTICLE · 1030465
当代码越来越廉价,软件行业的终极形态会是什么?
如果把时间拨回十年前,软件开发的核心能力很简单,也很明确:
把需求变成代码。
产品经理负责描述需求,架构师负责设计系统,程序员负责写代码,测试负责验证,运维负责上线。
代码,是整个软件产业最重要的生产资料。
所以过去十几年,程序员不断学习新的编程语言、新的框架、新的中间件、新的架构模式。
Java、Spring、MySQL、Redis、Kafka、微服务、云原生……
一个程序员的竞争力,很大程度上来自于:
我能不能比别人写出更好的代码。
但 AI 出现以后,这个逻辑正在发生一个非常深刻的变化。
今天的 AI,已经不仅仅是在编辑器里帮你补全几行代码。
越来越强大的 Coding Agent,已经可以阅读代码库、理解任务、制定计划、修改代码、运行测试、调试问题,甚至完成一个相对完整的软件开发任务。
于是,一个非常重要的问题出现了:
如果代码本身越来越便宜,未来的软件行业到底还剩下什么?
我认为,这可能比“AI 会不会取代程序员”更值得我们思考。
01一、AI 真正改变的,不是程序员,而是“代码的价格”
过去,一个需求之所以昂贵,很大一部分原因在于:
把需求翻译成代码,需要大量人工。
比如一个简单的企业系统。
一个功能可能需要:
产品经理写需求;
架构师设计方案;
后端开发写接口;
前端开发写页面;
测试人员写测试用例;
运维人员配置环境。
一个看起来很小的需求,背后可能是几个人几天甚至几周的工作。
而 AI 正在快速压低这部分成本。
以前:
一个程序员一天写多少代码,是生产效率的重要指标。
以后:
AI 几分钟甚至几十秒就可以生成大量代码。
这意味着一个非常重要的变化:
代码正在从“稀缺资源”变成“廉价资源”。
这件事情的意义,比“程序员写代码速度提高了多少”大得多。
因为当生产资料的价格发生巨大变化以后,整个产业的价值分配都会发生变化。
二、但代码便宜,并不意味着软件便宜
这里可能是很多人对 AI 编程最大的误解。
假设今天我告诉 AI:
“帮我做一个煤炭结算系统。”
AI 完全可以很快生成:
Spring Boot 后端、
MySQL 数据库、
Redis 缓存、
Vue 前端、
REST API、
Docker 配置,
甚至连测试代码都可以生成一部分。
但是问题来了:
什么叫“结算完成”?
这时候真正困难的问题才刚刚开始。
比如:
什么情况下允许结算?
订单重复提交怎么办?
结算金额如何计算?
数量按照发运量还是验收量?
质量指标出现争议怎么办?
合同发生变更怎么办?
谁有审批权限?
审批过程中数据发生变化怎么办?
下游系统调用失败怎么办?
消息重复消费怎么办?
数据库事务如何保证?
出了问题谁负责?
这些问题,根本不是“多写几行代码”能够解决的。
所以未来的软件行业会出现一个非常重要的分化:
代码生产越来越便宜,但正确的软件设计依然昂贵。
甚至可以说:
AI 越擅长写代码,“写代码”本身就越不值钱。
三、未来的软件工程,会从“写代码”转向“定义系统”
过去我们经常问程序员:
“这个功能怎么实现?”
未来更重要的问题可能变成:
“这个系统到底应该怎么运行?”
这两个问题看起来很接近,实际上完全不同。
前一个问题关注的是:
How。
后一个问题关注的是:
What + Why + Boundary。
也就是:
我要解决什么问题?
为什么这么解决?
系统的边界在哪里?
哪些事情可以自动完成?
哪些事情必须人工确认?
哪些数据可以使用?
哪些决策不能交给 AI?
出现异常以后怎么办?
这些才是软件系统真正的核心。
所以未来的优秀工程师,可能不再是“写代码最快的人”。
而是:
能够把现实世界的复杂问题,抽象成一个可靠系统的人。
四、软件开发可能从“人写代码”变成“人管理 Agent”
这是我认为未来几年非常值得关注的一种变化。
今天的软件开发大概是:
需求↓产品经理↓架构师↓程序员↓测试↓运维未来可能越来越像:
目标↓人类↓AI Agent├── 需求分析├── 架构设计├── Coding Agent├── Testing Agent├── Security Agent├── Data Agent└── DevOps Agent↓软件系统一个工程师不再只是自己写代码。
而可能是在管理一组 AI Agent。
比如:
“把订单系统增加一个批量结算功能。”
工程师把任务交给 Agent。
Agent 自己:
读取代码库;
理解现有架构;
分析数据库;
制定修改计划;
生成代码;
运行测试;
发现错误;
继续修改;
最终提交代码。
人类需要做的事情,则逐渐从:
“亲自执行每一步”
变成:
“定义目标、约束和验收标准。”
这其实是一次非常大的角色变化。
五、真正重要的能力,会越来越靠近“问题本身”
这也是为什么我认为:
AI 越强,业务理解反而越重要。
假设两个程序员。
A:
Java 写得非常熟练。
B:
Java 也不错,但同时非常懂金融结算业务。
以前两个人的差距可能没有那么明显。
因为很多工作最终都需要人工写代码。
但当 AI 可以承担大量编码以后,情况就变了。
A 可以告诉 AI:
“帮我写一个结算模块。”
B 可以告诉 AI:
“我们的结算不是简单的订单金额计算。要先根据合同确定计价规则,再根据实际验收数据计算基础金额,然后根据质量指标进行扣罚,同时考虑价格调整机制,最终进入多级审批。审批完成以后才能进入付款流程。”
谁能够让 AI 更准确地理解业务?
谁就更有价值。
所以未来非常重要的一种人才,可能是:
业务 × 软件 × AI
而不是单纯:
软件 × 软件 × 软件
六、这意味着程序员不会消失,而是会发生分层
我并不认为 AI 会让程序员这个职业简单地“消失”。
更可能发生的是:
程序员这个职业内部出现巨大的分化。
第一类,是代码执行型。
需求来了:
写接口。
需求来了:
改 Bug。
需求来了:
增加字段。
需求来了:
写 CRUD。
这一部分工作会越来越容易被 AI 自动化。
因为它本身就具有明确的输入和输出。
第二类,是 AI 软件工程师。
他们不再单纯依赖自己的编码能力,而是会使用 Agent 来完成大量开发工作。
他们需要理解:
Agent Loop、
Tool Calling、
Context、
Memory、
RAG、
Workflow、
Evaluation、
Observability,
以及传统的软件工程。
第三类,是系统架构师。
他们关注的是:
系统边界、
业务模型、
数据模型、
可靠性、
安全、
权限、
一致性、
成本、
演进。
第四类,也是我认为未来非常有价值的一类:
真正懂业务的人。
他们知道企业到底在解决什么问题。
他们知道哪些流程可以自动化,哪些流程不能自动化。
他们知道哪些决策可以交给 AI,哪些决策必须由人承担责任。
七、未来的软件可能越来越不像“软件”
这可能是整个变化中最有意思的一点。
我们今天理解的软件,大多是:
打开系统↓点击菜单↓填写表单↓提交↓查看结果软件是一组“功能”。
但是未来的软件,可能越来越像一个“执行者”。
比如老板说:
“帮我找出这个月所有异常采购订单,并分析原因。”
过去可能需要:
打开采购系统;
导出数据;
打开 Excel;
筛选金额;
查询历史价格;
打开合同;
核对供应商;
整理结果;
写报告。
未来可能只需要一句话。
Agent 自动完成:
理解目标↓查询数据↓分析异常↓查询合同↓查询历史记录↓判断异常原因↓生成报告↓通知相关人员↓跟踪处理软件不再只是:
等待人操作。
而开始:
主动完成任务。
这其实意味着软件正在从:
Application
走向:
Agent。
八、未来的软件界面,甚至可能越来越少
过去几十年,软件行业一直在不断改善 UI。
按钮越来越漂亮。
页面越来越复杂。
功能越来越丰富。
但如果 Agent 足够强,一个很有意思的事情可能发生:
我们不再需要操作那么多界面。
你不需要找到:
“采购管理 → 采购订单 → 高级查询 → 条件筛选 → 导出”。
你只需要说:
“把今年采购价格明显偏离历史平均水平的订单找出来。”
Agent 自己去调用:
数据库、
API、
ERP、
CRM、
文件系统、
搜索系统。
所以未来的软件可能出现一个趋势:
过去:人 → UI → API → 软件现在:人 → UI + AI → 软件未来:人 → Agent → Tools → 软件UI 仍然存在。
但它不再一定是人与软件之间唯一的入口。
九、那么软件公司的护城河会是什么?
如果 AI 可以越来越快地写代码,那么一个很现实的问题是:
以后大家都能做软件,软件公司靠什么赚钱?
我认为答案不会是“代码”。
因为代码越来越容易复制。
真正的护城河可能逐渐变成:
数据、业务流程、行业知识、客户关系、系统集成、组织能力以及信任。
比如:
一家 AI 公司可以很快生成一个 CRM。
但它很难在一天之内获得:
某个行业十年的业务数据;
几千家企业客户;
复杂的行业流程;
稳定的上下游系统连接;
客户长期形成的信任。
所以未来的软件竞争,可能从:
“谁的代码更好?”
逐渐变成:
“谁更理解这个行业,并且能够持续解决这个行业的问题?”
十、这也是为什么我不太担心“程序员会不会消失”
我反而觉得:
程序员这个职业会变得更像工程师,而不是代码工人。
过去:
程序员=代码生产者未来:
软件工程师=问题定义者+系统设计者+AI Agent 管理者+结果验证者代码仍然重要。
但代码只是最后一公里。
真正困难的事情,会越来越靠前。
十一、软件行业最终可能变成一种“自然语言驱动的软件生产”
如果把时间拉得足够长,我甚至认为未来的软件生产链条可能变成:
人的目标↓自然语言↓AI 理解↓业务模型↓系统模型↓Agent 自动实现↓自动测试↓自动部署↓自动监控↓自动修复↓持续演进到那个时候:
“开发一个软件”可能不再是一件需要几个月才能完成的事情。
真正困难的问题会变成:
你到底应该开发什么?
为什么要开发?
它应该遵守什么规则?
什么情况下不能自动执行?
如何证明它是正确的?
于是软件工程的核心,会从:
生产代码
转向:
生产可靠的决策系统。
十二、但这里有一个非常重要的边界
AI 越来越强,并不意味着所有事情都应该交给 AI。
恰恰相反。
未来真正成熟的软件系统,很可能不是:
“全部 Agent 化。”
而是:
该确定性的时候确定性,该智能的时候智能,该人工的时候人工。
例如:
固定规则→ Workflow明确计算→ 程序知识查询→ RAG开放任务→ Agent高风险决策→ Human-in-the-loop这可能才是未来软件架构真正值得研究的方向。
不是:
“怎么把 Agent 塞进所有系统?”
而是:
“这个问题到底应该由谁来解决?”
十三、所以我对未来软件行业有一个简单判断
如果让我用一句话概括:
未来的软件行业,不是从“有程序员”走向“没有程序员”,而是从“人生产代码”走向“人定义系统,AI 生产和运行软件”。
代码会越来越便宜。
开发会越来越快。
软件会越来越容易被生产。
但与此同时:
正确地定义问题,会越来越重要。
理解业务,会越来越重要。
设计系统边界,会越来越重要。
建立规则和约束,会越来越重要。
验证 AI 的结果,会越来越重要。
十四、而这可能是程序员最应该提前准备的事情
如果你现在还是程序员,我觉得最危险的学习方式是:
AI 出了什么新框架,我就学什么。
今天学 LangChain。
明天学 MCP。
后天学某个新的 Agent Framework。
再过几天又换一个新的 Coding Agent。
这样很容易陷入:
永远在追工具。
更值得长期积累的是下面这条能力链:
编程能力↓软件工程↓系统架构↓业务建模↓AI 能力↓Agent 系统↓AI + 业务最后真正形成的,不应该是:
“我会使用某个 AI 工具。”
而应该是:
“我能够让 AI 帮我解决真实的软件问题。”
这两者之间,差别非常大。
过去几十年,软件行业最大的变化,是:
让更多人可以使用软件。
未来十几年,可能发生另一场变化:
让更多人可以生产软件。
当软件生产成本越来越低以后,软件本身可能不再是最稀缺的东西。
真正稀缺的,可能变成:
对问题的理解。
对业务的理解。
对系统的理解。
以及:
知道什么时候应该让 AI 做,什么时候不应该让 AI 做。
所以,如果一定要问我:
软件行业的终极形态是什么?
我的答案不是:
“程序员消失。”
也不是:
“AI 取代软件公司。”
而是:
软件会逐渐从一个“被人操作的工具”,变成一个“能够理解目标、调用工具、执行任务并持续演进的系统”。
而软件工程师,也会从代码生产者,逐渐变成这种智能系统的设计者、指挥者和最终责任人。
真正值得关注的,从来不是:
AI 会写多少代码。
而是:
当代码已经不再稀缺之后,我们究竟还能创造什么价值。