十月回头翻看 Mira 的 GitHub，整个组织一个月创建了七百个 Pull Request，其中六百四十一个合并。如果只把软件开发理解为提交代码，这当然是一份漂亮得有些不真实的成绩单。几十张任务卡同时施工，Agent 在不同仓库里编写代码、运行测试、提交修改，过去需要一个团队连续忙上几周的事情，如今可以挤在同一天发生。
但我们自己的感受并不那么振奋。功能确实增加了，架构也在逐渐成形，然而每次准备宣布一个东西完成，总有人不得不重新确认：用户真正要的是什么，跨仓库接口是否一致，真实设备上的运行链路通不通，Cloud Auth 返回的是签名公钥还是前端页面，CI 的绿灯能不能代表产品已经可用。写代码的人越来越多，最后能够看懂全局并作出判断的人，反而显得越来越少。
2026 年 9 月 19 日，Amp 联合创始人 Thorsten Ball 发表了《What I believe about the future of software development》，一口气提出十六条关于软件开发未来的判断。他认为代码审查将死，单元测试也许会死，终端会退场，传统的产品经理、设计师和工程师三元结构将会解体；开源的理由将被重写，代码质量不再按人类的阅读舒适度衡量，甚至界面都可能在运行时即时生成。
这些话不够谨慎，甚至有些故意冒犯。但我不想用“这不适用于所有项目”来轻易化解它们。一个预言即使过于激进，也可能准确指出某种旧制度正在丧失赖以存在的条件。真正值得追问的，不是给每条判断盖上同意或反对的印章，而是承认：我们已经习惯的一整套编程方法，原本是为人类缓慢地生产、理解和修改代码而设计的。如果这个前提突然改变，还剩下多少事情值得照旧做？
以下十一条，是我认为最值得认真讨论的断裂。
一、源代码开始失去中心地位#
1. 代码审查会消失吗？会，至少我们今天认识的那一种会#
人类通过 Pull Request 逐行审查代码，本来就是一种建立在特定成本结构上的制度。一个程序员花几天写出几百行改动，另一个程序员花几十分钟到几个小时看完差异，成本大致还算对等。可当 Agent 能在一段时间里同时修改数十个文件、重构几个模块，甚至把一套实现整体替换掉，审查者如果仍然逐行追赶，就会很快成为整个系统中最昂贵、最缓慢的工序。
因此我基本接受 Ball 的方向判断：人工逐行 Code Review 不会继续是软件交付的默认入口。 更有价值的审查对象，将是系统由哪些部分组成、模块之间承担什么责任、数据和权限越过了哪些边界，以及需求是否真的被正确实现。以前我们问“这一行会不会空指针”，以后要更频繁地问“这台手机究竟有没有权力要求另一台电脑执行命令”。
不过，审查代码的形式会衰落，不等于审查责任会消失。十月 Mira 就遇到过这样的场景：一个 Worker 写完代码、跑过测试，却因为创建 PR 时缺少 GitHub 权限导致整个流水线失败。如果只看 CI 红灯，它似乎什么都没有交付。另一方面，如果 AI Reviewer 给了绿灯，但手机用户登录以后依然看不到对话列表，也不能说软件已经完成。这两件事需要的都不是重新读几千行代码，而是判断什么才算真正的交付。
Ball 在十月展示过自己的 Amp 工作流：团队把改动直接推到主干，借助 Agent 检查生产日志、部署状态和端到端效果；重要变更使用 Feature Flag 隔离，自己先试，再逐步开放。他偶尔仍会阅读关键代码，但不再把阅读所有代码当作准入条件。这种方法最值得学的，不是删掉 PR 这个动作，而是有人真的建起了替代它的验收能力。把人类审查拿掉，却没有验证体系、权限控制和回滚手段，那不叫先进，只叫放弃检查。
2. 单元测试可能消失，因为整栋楼都可以重建#
Ball 举过一个例子：模型替他写了大约九百行 Arduino C 代码，编译一次成功，烧录到设备里也顺利运行。在他的想象里，既然 AI 能持续生成大规模正确实现，为什么还要把精力放在一块块“砖头”上？
我理解这种判断的诱惑。过去系统重构很贵，一个经过充分单元测试的函数可以在漫长的版本周期中被反复依赖。现在模型也许下一轮就拆掉整个模块，换上完全不同的函数、数据结构和依赖关系。如果测试紧紧依附于实现细节，那么重建房屋的同时还要逐块修复旧砖的检测报告，确实荒唐。
因此，传统单元测试的占比可能下降，接口测试、集成测试、端到端测试和系统性质验证会获得更高地位。 一个关于结算金额的关键规则，最好不因为支付服务内部换了几个类就需要重新定义；一个关于退出登录后必须切断云连接的约束，也应该在桌面端、移动端和服务端完整的运行链路上成立。
但我不会据此宣布单元测试没有任何价值。纯计算、不变量、权限判断、复杂的边界算法，仍可能用小而快的测试最经济地证明。真正应该淘汰的，是为了覆盖率而覆盖、照着实现写 Mock、再用模型自己写的测试为同一份误解背书。十月 Folio 在真实消费者环境里暴露过典型缺陷：仓库内 TypeScript 没有问题，独立项目安装打好的 npm 包，却找不到虚拟模块的类型。再如某些默认 CSS 声明会通过继承影响宿主页面。仓库内部一片绿灯，到了真实使用边界就出错。审查一百块砖头，不如找一个真正住进房子的人。
我更愿意这样重述这一条：该减少的是围着实现细节转的测试，而不是测试本身。
3. 软件开发的重点，将彻底离开“会不会写代码”#
过去一个优秀程序员的能力，通常通过代码体现。能把复杂逻辑写对，能用较少资源解决性能问题，能处理别人不愿碰的旧系统，这些都是稀缺能力。软件行业因此很自然地把写代码的熟练度，当成衡量一个人是否有资格构建软件的重要标志。
现在这个标志正在迅速贬值。不是编程知识突然没用，而是掌握语法、熟悉框架、快速写出实现，已经不足以证明一个人能够独立负责软件产品。 当 Agent 可以承担越来越多机械劳动，程序员不得不面对自己曾经能够藏在代码背后的问题：用户到底遭遇了什么困难？解决它是否值得？为什么选择这种产品形式？什么情况下必须停止上线？新功能投入真实环境以后，要怎样知道它确实带来了价值？
这些问题以前就存在，只是常常被“先把功能做出来”遮住。如今代码能很快做出来，遮羞布自然没有了。
Mira 十月最深的教训就是这样：基础设施方向大多正确，施工能力也不差，真正的问题是同时开了太多正确方向，最后无法及时确认它们是不是一起构成了用户真正需要的东西。一个人能够调度十个 Agent 写代码，并不意味着他能够同时承担十个产品方向的判断和验收。软件开发正在从“把需求变成代码”变成“把模糊目标变成能够验证的现实”。前者会越来越自动化，后者反而更要求经验、审美、业务理解和对结果负责的能力。
4. Bug 的重心会转向需求，但世界不会因此不再出错#
Ball 有一句很锋利的话：未来的大多数 Bug，不再是代码写错，而是人要求了错误的东西。
我认同他想指出的方向。一个模型把登录按钮画出来、把接口接通、把自动化脚本跑过，通常不需要你再从第一行教它怎么写。但“登录成功”这四个字能够藏下无数种完全不同的实现。是只有浏览器会话成功，还是手机彻底结束进程之后仍能恢复？是允许云账号登录，还是登录后应该发现属于自己的电脑？退出账户时，要不要同时撤销尚未结束的远程调用？
如果任务只说“实现云登录”，那么一个能够通过编译并正确返回 Token 的程序，完全可能是一项失败的交付。它不是在代码里打错了一个字符，而是把产品应当承担的行为缩小到了容易实现的一小块。
但我们也经历过另一类错误。Cloud Auth 的 JWKS 路由曾经返回 HTTP 200，内容却是前端 SPA 的 HTML；修正路由后又遇到签名器未正确部署。此类问题不是简单的需求表述错误，也不一定是源代码里的经典 Bug，而是运行环境、配置和系统边界出了问题。
所以我愿意把话说得更准确：代码 Bug 会失去今天的中心地位，取而代之的是目标、合同、运行环境和现实结果之间的错位。 越依赖模型自动施工，越要明确什么结果不允许出现。这比要求 Agent “认真一点”有用得多。
二、旧的组织方式，也在失去理由#
5. 软件开源不再天然等于质量提升#
开源世界长期流行一个信念：如果有足够多双眼睛看代码，错误最终就会浮现。现在 Ball 提醒我们，AI 已经可以提供数量近乎无限的“眼睛”。一个私有项目也可以安排多轮模型审查，运行静态分析、自动测试与安全扫描，甚至模拟不同角色寻找缺陷。把代码放到 GitHub，并不能自动证明它比闭源软件可靠。
这一点我赞成，而且应该比过去说得更难听一些：公开源代码从来就不等于有人认真审查，更不等于有人为安全负责。 无人维护的仓库、过时的依赖、迟迟没有合并的漏洞修复，不会因为源代码开放就获得质量保证。AI 只是让这层幻想更难维持。
但如果顺着这句话再走一步，宣布开源没有意义，我就不同意了。开源不只是查 Bug 的方法，也是一种关于所有权、可迁移性、公共协作和权力分配的安排。用户是否有权检查软件究竟做了什么，能不能自行修复，项目停止维护以后能不能接着往前走，有没有替代服务商的自由，这些都不是几个模型通宵审查一份私有仓库就能解决的事。
AI 也可能让开源更加重要。当代码生成变得便宜，每个人都可以迅速复制一套近似产品，真正昂贵的反而是长期维护的协议、兼容性、公共知识和可信供应链。代码可以再生成一次，公共信任却不能每次从零开始。开源正在失去一种旧理由，同时获得另一种更严肃的理由。
6. 敏捷编程可能先于程序员退休#
敏捷、Scrum、Sprint、站会、估点、看板、工单，原本是在应对一个非常实际的困难：人类团队的施工能力有限，沟通成本高，需求不断变化。我们需要协调谁先做什么，避免几个人互相等待，也要为不断被打断的工作建立某种秩序。
如果执行者变成能够并行启动、随时交接的 Agent，很多传统流程确实会显得可笑。一个需要三次会议才能明确责任人的小改动，可能在会议结束前已经被模型完成。如果所谓敏捷最终变成让产品经理填单、项目经理搬单、工程师读单，再把单子转给 AI，那么这条人肉传输链确实没有必要继续存在。
我不怀念为了流程而存在的敏捷。 但我也不相信，把工单直接推给模型，就等于解决了协作问题。
在 Mira，我们尝试让 External Worker 按 Issue 施工，交付分支、日志、测试和 Draft PR。生产确实变快了，代价是开始不断遇到目标漂移、任务交接失败、返工、依赖冲突和审核等待。这些问题不可能靠每天开一次站会解决，却也不会因为不再开会而自动消失。
真正需要替换的，是把流程完成误当成交付完成的习惯。工单要更清楚地描述边界和结果，任务要能够随时观察、接手和终止，依赖关系要能被系统理解。未来也许不再需要 Scrum 的仪式，却仍需要协作本身。死去的可以是一套仪式，不能是面对现实变化的能力。
7. PM、设计师、工程师的三元分工，会被拆散重新组合#
传统软件团队经常把产品、设计和工程视为三个角色，依次负责决定做什么、做成什么样、怎样做出来。这种分工既能发挥专业优势，也经常制造翻译损耗：产品经理写需求，设计师做视觉，工程师指出实现成本太高，三个人再开会重新解释一次。
AI 使一个人跨越这些边界的成本大幅下降。懂业务的人可以直接做出可用原型，设计师可以让模型实现交互，工程师也能快速验证几套完全不同的产品方案。过去必须等待其他岗位才能继续推进的事情，如今很多可以先在一个人手里完成。
所以我相信，三种职责会继续存在，但不必再严格对应三个人。 一个人能同时提出产品假设、制作界面、部署服务，再通过真实反馈修正设计；一支小团队能完成过去只有大团队才能承担的一部分工作。这会重新分配公司的成本，也会迫使每个岗位证明自己不只是负责传递文件。
问题在于，“一个人可以做”不等于“一个人有足够判断力把所有事情做好”。一位会写提示词的开发者不一定理解真实用户，一位擅长设计页面的人不一定熟悉安全边界。跨岗位能力扩张固然让人兴奋，专业判断却不是一道可以通过代码生成省略的手续。
我最担心的不是哪个岗位被取消，而是一个人拥有过去整个团队的生产能力之后，却继续只用一个人的视野和注意力承担全部风险。Mira 在十月遇到的，就是这个问题的早期形态。
三、所谓“好代码”，到底好在哪里#
8. “好代码”的传统标准，会失去一部分前提#
我们曾经花费大量时间讨论怎样让代码更易读、易于重构、方便维护。好的命名、合适的抽象、清楚的模块边界、统一的代码风格，都被赋予了近乎道德的意义。理由其实并不复杂：代码要由人阅读和修改，人类的理解成本足够昂贵，因此值得专门优化。
假如未来绝大多数实现都由 AI 写、由 AI 改，人类又不再逐行维护，那么其中一些标准确实需要重新审视。为了一行代码是否超过八十个字符争论半小时，显然已经谈不上工程效率。但我不接受由此推导出的另一个结论：代码质量本身不重要了。
软件运行在真实环境里，而不是审美比赛里。一个模块没有清楚的权限边界，模型重写一万次都不能让它自动安全；同一个业务事实被存放在两个不同的地方，Agent 可能更快地同时修改两处，也可能更快地让它们互相矛盾。复杂度、性能、安全性、可观察性、可回滚性，这些不是为了让维护者看得舒服而存在的装饰。
我更愿意用一个不那么浪漫的标准定义新时期的好代码：它是否容易被理解为一个系统、能否被独立验证、出了问题能否及时定位，以及替换它会不会让整个系统陪葬。 人类读得舒服不再是全部，但系统拥有清楚的结构，反而会让机器和人都更容易负责。
9. Linter 与代码风格会贬值，但别把便宜的约束也一起扔掉#
关于缩进、尾随逗号、换行、命名规则的争论，在旧时代很容易占据令人难以置信的会议时间。Ball 对这一套不耐烦，我完全能理解。模型本来就能迅速完成格式化，人类继续像审阅手抄本一样检查换行，已经不合时宜。
然而，linter 并不只会检查制表符与空格。规则可以阻止危险 API、无效依赖、未处理的异步错误、错误的 React Hook 调用、被误用的权限参数，或某些已知会导致安全和稳定性问题的结构。它们是廉价、确定性、能够每次重复执行的约束，也是 Agent 批量施工时很好的反馈机制。
因此我的立场并不矛盾：风格规范没有必要继续被神圣化，格式化应该尽可能无感地自动完成；但凡是一条规则真能以极低成本挡下实质问题，为什么要因为 AI 出现就主动废掉它？我们真正需要淘汰的是没有收益的形式主义，而不是所有不需要模型思考就能执行的检查。让一个昂贵的模型每次重新琢磨一条写死就能执行的约束，才是不合理的浪费。
10. 用户界面会发生根本变化，但“没有 UI”不等于“没有设计”#
我认为 Ball 对 UI 的判断，可能比他关于终端和代码审查的宣言更有穿透力。
传统软件之所以拥有复杂的菜单、设置页、筛选条件、仪表盘和层层嵌套的工作流，很大一部分原因在于软件无法直接理解人的意图。用户只能通过界面，把自己的需求拆成系统能够识别的一次次点击。对于越来越多能够理解语言、调用工具、组织任务的 Agent 而言，这套交互逻辑显然会被改变。
假如我告诉系统“找出本月所有异常订单，按供应商汇总原因，并只把需要我批准的事项列出来”，它理应能够调用数据和服务，临时组织出一张符合任务的表格，而不是要求我先学习每一个筛选字段、导出菜单和统计页面的入口。许多传统 UI 的确可能变成按需生成的视图，甚至退化为 Agent 可调用的 API。
但千万不要把这件事理解为视觉设计不重要。一个系统能不能准确理解用户希望做什么，与用户能不能看懂系统已经做了什么，是两件不同的事。 生成一个看上去漂亮的页面很容易，生成一个在权限、数据含义、操作后果和可访问性方面都可靠的页面，要困难得多。
尤其在支付、医疗、账号授权、数据删除这样的场景里，稳定、一致、可以核对的 UI 并不是因为机器不够聪明才存在，而是因为人需要确认自己正在授权什么，系统将产生什么后果。即使许多界面交给 Agent 动态生成，涉及不可撤销行为的确认、审计和解释也不应该跟着消失。
未来最好的 UI 也许不再是一组永远固定的页面，而是一种在任务需要时把复杂系统重新翻译成人能理解、能判断、能控制的形态。这不是取消设计，而是把设计从画页面提升到管理人与机器之间的理解关系。
四、Token 为王，但钱买不来判断#
11. 谁买得起更多 Token，谁就可能拥有更强的生产能力#
Ball 对 Token 的判断很不客气：未来几年，一部分人会因为负担不起足够多的模型调用，被排除在高水平软件生产的竞争之外。这与早期个人计算机价格高昂的年代有点相似。拥有更强模型、更长推理预算、更大并行额度、更充足工具环境的人，当然更有机会尝试、失败、改写，再尝试。充足的 Token 正在把过去由团队规模决定的一部分产能优势，转移到算力和模型预算上。
从 Mira 的经历看，我愿意承认这种变化。免费的 Worker 能承担不少机械施工，但复杂任务常常需要更强的模型、更长的执行窗口和更多独立检查。如果为了省下一次模型调用，让任务连续失败、重复返工、污染代码，表面上节省 Token，实际上却把成本转移给了人的注意力。我们甚至已经开始认真讨论：有些时候，花钱买一个更聪明的施工者，可能比免费跑三轮更便宜。
但如果只看 Token 的总消耗，很快又会掉进新的陷阱。一次调用的费用，不是完成一项工程任务的费用；生成的代码量，也不是交付的软件价值。应该计算的是从理解任务、施工、测试、返工、审查到真正投入使用的完整成本，包括等待时间、运行资源和人的注意力。最昂贵的模型也可能在错误方向上工作得更勤奋，最便宜的模型也可能在清晰、低风险的任务里足够好。
因此，“Token 为王”至少包含两个互相牵制的事实：没有足够的计算资源，你可能连尝试的机会都不够；但只有计算资源，没有方向和验证，你只是更快地制造出一大堆需要处理的东西。
这也是为什么我不相信“后面模型足够聪明，一切工程纪律都会失去意义”的乐观叙事。模型成本持续下降，只会让更多组织同时拥有大量生成能力。当每个人都能生产代码，如何发现值得做的事情、如何建立用户信任、如何处理复杂系统留下的债务，反而更不容易靠增加 Token 解决。
面目全非之后，我们还剩下什么？#
Thorsten Ball 的原文还谈到终端将死、性能优化将成为少数特例、Token 可能成为新的计算范式，以及大型公司与小型团队的工程实践差距会继续扩大。我不打算把十六条预言硬凑成一份未来职业指南。它们都围绕同一个变化展开：当生成代码的能力突然变得便宜，过去为了节约编程劳动而建立的许多制度，确实可能不再划算。
但这不代表软件工程只剩下“把工单交给 AI”。过去那些被源代码的生产过程包裹起来的事情，如今开始被迫暴露：为什么要做这个产品、谁有权决定它的行为、什么证据才足以证明它可用、用户出了问题向谁追责，以及一项看似正确的局部修改会不会破坏别的地方。
十月 Mira 最鲜明的教训，是代码规模、PR 数量和部署通知都无法独自证明进步。用户能否成功登录、恢复对话、发起一次远程调用，终究要由真实链路回答。自动化报告的是它观察到的事实，产品验收则必须把证据放回用户的目标中判断。
旧时代的工程仪式不值得仅凭资历保护。PR 可以简化，测试可以重建，团队边界可以变化；但用代码行数、故事点或会议数量维持职业尊严，只会把注意力留给正在贬值的东西。
可是，新工具可以替我们承担劳动，却不能仅凭自动化本身证明事情值得做。某项能力能够被执行，不代表它应该被授予；某个功能已经存在，不代表用户需要它；一次模型判断非常自信，也不代表它具有最终裁决权。
它最让人兴奋的地方，是许多曾经需要组织和资本才能动手的事，重新进入个人的能力范围；最令人不安的地方，则是我们可能顺手把理解、验证和责任当成旧时代的累赘。
编程正在变得面目全非。值得我们守住的，不是过去写代码的方式，而是软件最终必须对现实负责。
资料与编辑说明#
- Thorsten Ball：《What I believe about the future of software development》，2026-09-19 —— 本文主要讨论对象；十六条观点均以作者博客原文为准。
- Amp：《How I use Amp》 —— 作者对自己实际工作方式的说明。
- Amp Chronicle：《How Thorsten Ball Uses Amp》，2026-10-13 —— 可观看的实际工作流、生产验证与 Feature Flag 案例。
- Addy Osmani：《The Code Nobody Reads》，2026-09-28 —— 对“代码审查将死”的直接回应。
- Addy Osmani：《Agentic Verification》，2026-10-14 —— 关于端到端、性质与差异验证的进一步论述。
- 《Mira 十月开发回顾：路太宽就是没有路》，2026-10-31 —— 本文所用 PR 数量、Cloud Auth、Mobile、Folio 和 External Worker 案例的公开工程记录。
- 《AI 审查开始能批准 PR，绿灯到底代表什么？》，2026-11-01 —— 代码审查、合并批准与交付责任的进一步讨论。
《见π》008 封面故事。本文基于 Thorsten Ball 的公开观点与 Mira 工程实践独立写作，不是原文翻译。关于未来的预言是编辑判断，实际工程经历以所引公开资料为依据。
