本文永久链接 – https://tonybai.com/2026/09/23/thorsten-ball-predictions-future-of-software-development

大家好，我是Tony Bai。

【导读】

AI写代码这件事，讨论了三年，但很少有人像Thorsten Ball这样，把“变化会走到哪一步”这个问题一次性说穿。这位以《Writing An Interpreter In Go》闻名、现供职于Sourcegraph/Amp的资深工程师，2026年9月19日在X上发布长文，抛出16条对软件开发未来的判断——从“代码审查已死”到“终端已死”，从“好代码”的定义崩塌到工程师价值坐标的整体迁移。这些话不是危言耸听的流量文案，而是一个每天用AI写几百行代码、看着模型把Arduino C一次编译通过的人，基于一线体感给出的推演。

【文章要点】

  • 代码审查、单元测试、终端命令行——这三样“人类质量把关”的经典工具，正在从必需品变成可选项
  • 工程师的价值坐标正在迁移：从“写代码的手艺”迁移到“理解业务、判断取舍、拿到反馈”的能力
  • “好代码”的行业共识可能是人类协作时代的产物，未必是永恒真理
  • Token被视为一种新的计算范式，堪比80年前二进制计算机的确立
  • PM/设计/工程的传统协作三角，在AI可以直接生成可用系统的背景下面临重构
  • 组织规模的分化会加剧：小团队因约束更少，反而可能比“学大厂做法”的初创公司跑得更快
  • 这不是一夜之间的革命，Thorsten Ball自己也承认，新旧范式的更替需要一代人的时间

代码审查是不是快死了？

单元测试还有没有必要写？

命令行终端是不是快成“文物”了？

这些问题，程序员们私下讨论过无数次，但很少有人愿意公开、系统地把答案摊开来说。

2026年9月19日，开发者Thorsten Ball在X上发布了一条长文，标题就是《我对软件开发未来的看法》（What I believe about the future of software development）。这条推文迅速引发大量转发和讨论。

Thorsten Ball不是一个陌生的名字。他是《Writing An Interpreter In Go》和《Writing A Compiler In Go》两本书的作者，长期活跃在Sourcegraph、现在的Amp团队，是那种每天真的在用AI写代码、而不是纸上谈兵的一线开发者。

也正因如此，他这16条判断更值得认真拆一遍。

第一层震荡：代码审查、单元测试、终端，为什么会"死"

Thorsten Ball开篇就是三记重拳。

第一条，代码审查会死。 他甚至说，其实已经死了——不是说没人做代码审查，而是说未来人类不会再在合理时间内，从模型产出的代码里找到bug或问题。人类会审查的，是“系统与其组合方式”，而不是一行行地看PR里的代码。

第二条，单元测试也可能会死。 他举了个具体的例子：他让模型写了900行Arduino C代码，编译时零错误，烧录到设备上直接完美运行。他的判断是，900行在未来根本不算什么。既然摔不了跤，为什么还要戴护膝？

第三条，也是最扎心的一条：写代码这门手艺会消失。 他用了一个略带自嘲的比喻——“是的，意大利手工鞋匠依然存在，但看看你脚上穿的是什么”。潜台词很直白：手艺可以存在，但不会是主流。

如果把这三条放在一起看，其实是同一个逻辑在不同环节的展开：当模型产出代码的可靠性足够高时，原本为了“防止人犯错”而设计的一整套人工质量关卡，会逐渐失去存在的必要性。

我们可以用一张图，把这个逻辑变化的整体轮廓画出来：

值得注意的是，Thorsten Ball并不是说“审查”、“测试”、“命令行”这些行为本身消失了，而是说执行这些行为的主体在变：审查的主体从“人看代码”变成“人看系统”，测试的主体从“人写用例”变成“模型自证”，交互的主体从“敲命令”变成“对话”。

价值迁移：从“写代码”到“造软件”

如果写代码这门手艺真的会贬值，那工程师的价值在哪？

Thorsten Ball给出了一个明确的答案：“造软件”这门手艺，会比以往任何时候都更重要。 具体来说，是知道如何用软件解决业务问题、知道别的软件是怎么做的以及为什么这么做、知道什么时候该上线、以及如何拿到真实反馈——这才是新的游戏规则。

与此呼应的，是他另一条判断：大多数bug将不再是“代码”bug，而是“你需求提错了”的bug。 当代码本身的正确性问题被模型大量消化之后，剩下的、真正难解的问题，会集中在“我们到底要做什么”这个更上游的环节。

这条逻辑其实解释了很多正在发生的现象：为什么现在很多团队开始强调“把需求写清楚”比“代码规范”更重要，为什么Prompt和Spec正在变成一种新的“工程语言”。

他还提到一个容易被忽略的边界条件：性能优化这类高难度的人工贡献，会继续保持在“边缘案例”的位置。 他的原话很直接——99%的软件里，你写没写出更快的算法、选没选对数据结构，根本不重要，因为你没有客户、没有用户、没人在真正跑这段代码。真正需要极致性能的时候，模型可以处理。不要拿“最顶尖1%的开发者”去对比剩下的99%。

认知升级：Token是新的计算范式

这条判断可能是整篇推文里最“形而上”的一条，但也最值得咀嚼。

Thorsten Ball说：Token是新的计算范式，一切都会在它之上被重新构建。 我们已经用了80年确定性计算机，所以很容易把“计算机过去是怎么运作的”和“计算机必须怎么运作”这两件事搞混。我们正在进入“后二进制时代”。

配合这一条，他还提出终端已死——他特别强调自己是终端和开发者工具的忠实爱好者，但依然认为Shell、文本编辑器、CLI工具会被token“冲刷”掉，未来人类不会再直接使用它们，命令行参数和jq用法，会像今天的Perl一行流一样，被视为一种“古老技艺”。

这两条判断放在一起，其实是在说一件事：当“和计算机交流的方式”从确定性指令变成自然语言token时，建立在确定性范式之上的整套工具体系，都需要被重新审视。

组织地震：三角瓦解，大厂小厂分化

如果说前面几条讲的是“技术层面”的变化，接下来这两条讲的是“组织层面”的变化。

第一，PM、设计、工程的传统三角协作会瓦解。 Thorsten Ball的判断很直接：这种分工方式已经没有意义了，Agile、Scrum这些方法论，都会“死”。那些扮演“人肉代理”、只会把需求丢进AI Agent、再把结果汇报给人类的“工程师”，将不再有价值。

第二，大公司和小公司在软件工程能力上的差距会拉大。 他的观察是，如果初创公司还在照搬Google那一套工程实践，会显得比以前更荒唐，因为现在的小团队完全可以用更快的速度、更少的约束把软件造出来。

上面这张示意图不是Thorsten Ball原文里的内容，而是我们基于他的判断做的一种推演——当执行环节被大幅压缩之后，组织结构大概率会围绕“谁真正拥有问题的判断权”重新排列，而不是继续按职能切分三角。

最颠覆的一条：“好代码”的定义可能正在崩塌

如果说前面的判断还在“效率提升”的框架里，那这一条已经触及了行业的价值观基础。

Thorsten Ball提出：没有证据表明“好代码”在未来还会重要。

他的逻辑是，“好代码”这个概念，本质上建立在“代码要方便、便宜、高效地让人类去维护”这个前提之上。但如果人类以后根本不会去修改绝大多数代码，那这个前提本身就站不住了。他举了个略带调侃的例子：认为“每行不超过80列”或者“换行要放在哪里”这种规则对Agent有意义，本身就很荒唐——如果连这些细枝末节都失去意义，那我们对“好代码”设想的其他所有属性，是不是也该重新审视一遍？

与此相关，他还提出了两条关于资源与开源生态的判断：

  • 开源在现有形式下已经不太合理——“足够多的眼睛能让所有bug无所遁形”这句老话依然成立，但现在我们有了“人工眼睛”。
  • 一部分人会被排除在软件生产之外——就像80、90年代不是所有人都买得起个人电脑一样，接下来几年，如果你拿不到足够的token，你就只能打“次级联赛”。你需要先拿到token。

他甚至进一步追问：更便宜的模型是否真的会被广泛使用，本身就存疑。 他的理由是——虽然token会变得极其充裕，今天我们眼中的“聪明模型”，未来会被视为很笨，但一个更聪明的模型犯错更少、需要的交互轮次更少。你真的愿意为了省钱，接受模型多犯几次错吗？

最后一条关于UI的判断也值得一提：模型足够快之后，UI会被实时生成。 很多菜单、设置页面、仪表盘、筛选器，本质上是"因为软件理解不了你想要什么"而存在的、面向人类的API。当机器足够聪明，需要的UI会大幅减少。

冷静看：这只是个人判断，还是趋势？

把16条判断摆在一起看，会发现Thorsten Ball其实给自己留了退路——他在文章末尾明确说：这一切需要一代人的时间才能完成。就像今天依然有人开开心心地做着ASP开发一样，10年后依然会有人靠写代码为生，只是他反问了一句：但你真的想要那份工作吗？

这句反问，大概是整篇文章里最“扎心”又最留有余地的一句。

对于这16条判断，我们认为有三个问题值得读者带着自己的经验继续追问，而不是简单站队：

  • “代码审查已死”和“审查系统”之间，责任到底怎么划分？ 如果人类不再逐行审查代码，那当系统真的出问题时，责任链条会落在谁身上——是提需求的人、审系统的人，还是模型本身？
  • “好代码”标准的崩塌，是不是低估了长期演化成本？ 即便短期内人类不再直接修改代码，一个系统长期迭代、排查故障、做安全审计时，代码的可读性和结构是否依然重要，这本身可能还需要更长的时间观察。
  • “token定价决定谁能造软件”，会不会加剧已经存在的技术鸿沟？ 如果生产力的门槛从“会不会写代码”变成“买不买得起token”，这对个人开发者和小团队而言，究竟是解放还是新的壁垒？

结语

Thorsten Ball这16条判断，与其说是在预测未来，不如说是在描述一种他已经真实感受到的“体感”——当他亲眼看到模型一次性写出900行零错误的Arduino代码时，很多过去被视为“理所当然”的工程实践，在他眼里已经开始动摇。

变化会不会真的如他所说全面发生，需要时间去检验。但至少有一点是清楚的：关于“软件工程未来长什么样”的这场讨论，已经不再是“AI会不会取代程序员”这种简单的二元问题，而是在追问一个更根本的问题——当写代码的成本趋近于零时，软件工程这门学科，到底还剩下什么是不可替代的。

参考链接：https://x.com/thorstenball/status/2101305394190557466

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。