我对软件开发未来的判断

这篇最初以 发布在X上 为标题发布，引发了热议。为了留下我的印记，表明这些是我2026年9月所坚信的观点，我把它放在博客上，让它不再转瞬即逝。

其中一些预测只是观察所得，在像 Amp 这样的公司里早已成立；另一些则需要时间才能逐步实现。

代码审查将走向终结。 我的意思是：它其实已经死了。但在未来，人类几乎不可能在合理时间内发现由模型生成的代码中的缺陷或问题。

人们只会审查系统及其整体架构，而不会再逐行查看 Pull Request 中的代码。

单元测试也可能消亡。 如果从不摔倒，又何必依赖辅助轮？我曾让模型写出900行 Arduino C 代码，编译时毫无错误，直接部署到设备上，程序运行得完美无缺。

而在未来，900行根本不算什么。

编写代码这门手艺将逐渐消失。 是的，意大利手工制鞋匠依然存在，但看看你的脚吧。

构建软件这门技艺将比以往任何时候都更重要。 如何用软件解决业务问题，其他软件是如何做的、为什么这么做或不这么做，何时以及如何交付，如何获取反馈——这才是新的核心竞争力。

大多数 Bug 不再是“编码”类的。 它们更多是“你提的需求本身就有问题”的类型。

以当前形态存在的开源已不再有意义。 “只要有足够多的眼睛，所有的 Bug 都会浮出水面”这句话仍然成立，但现在我们有了人工“眼睛”。

由人类做出的性能关键性贡献仍将只是个例。 在99%的软件中，你是否写出了更高效的算法或选择了更好的数据结构并不重要——因为你没有客户、没有用户，甚至没有人真正执行这段代码。

当真正重要的时候，模型可以帮你优化。不要把顶尖1%的开发者与其余99%相提并论。

终端已死。 大多数开发者工具都将被 Token 浪潮所淘汰。Shell、文本编辑器、命令行工具都不再由人类使用。你再也不需要记住各种命令行参数和 jq 的用法了，那将被视为如同用 Perl 一行代码搞定一切般晦涩难懂。

（我本人其实是终端和开发工具的爱好者。）

Token 是新的计算范式。 一切都会基于它重新构建。过去80年我们习惯了确定性计算机，以至于把“计算机一直以来的工作方式”等同于“计算机必须如此工作”。

我们正在迈入后二进制时代。

PM/设计/工程的三驾马车将不复存在。 这种分工早已毫无意义。敏捷、Scrum 等方法论也已过时。“工程师”作为“人力代理”，把任务塞给 AI 并向人类汇报的做法将不再有价值。

大公司与小公司在软件工程上的差距将进一步拉大。 那些照搬谷歌做法的初创企业如今看起来更加可笑，因为他们现在能以更快的速度、更少的约束完成开发。

没有任何证据表明“好代码”在未来仍会重要。 “好代码”这一概念很大程度上源于它对人类而言易于理解、成本低廉且高效。然而，人类将不再修改大部分代码。

想想看，假设“代码宽度仅限80列”或“这里那里要加换行符”对 AI 而言有多荒谬——再联想到你心目中“好代码”的其他种种特性，答案就显而易见了。

有些人将被排除在软件生产之外。 就像上世纪八九十年代只有少数人买得起个人电脑一样，未来几年里，如果你无法获得足够的 Token，你就只能屈居二线。

你需要掌握 Token 的获取途径。

更廉价的模型是否会得到广泛应用尚存疑问。 Token 将无处不在，我们将被 Token 所包围。而今天我们视为“智能”的模型，在未来会被认为相当“笨拙”。

但更智能的模型犯错更少，所需交互次数也更少。你真的会愿意接受它偶尔出错几次吗？

模型的速度将快到足以实时生成 UI。 很多 UI 的存在，是因为软件无法理解用户的意图。菜单、设置界面、仪表盘、过滤器——它们大多只是为“哑机器”提供的人类可用接口。

而智能机器则需要更少的 UI。

这一切还需要一段时间才会完全显现。 新一代软件取代旧有软件需要整整一代人的时间。就像今天仍有人乐于从事 ASP 开发一样，十年后也会有人继续写代码。

但你真的想做这份工作吗？