一、全文翻译
原文https://www.oreilly.com/radar/the-end-of-debugging/
这篇文章是对上周一篇关于“日志记录进展”的文章的后续。一位同事对我们即将运行自己并不完全理解的代码这一想法提出了质疑。他怀疑地说：“代码还是由我们自己写的，对吧？只有自己写的代码才能提供支持，对吧？……对吧？”
这只是一个假设——但这个假设已经开始动摇。
你不再需要写（甚至读）每一行了
我给他举了一个简单的例子：我需要在一个表单里实现“拖放排序”。我以前做过类似功能，但这次我直接问 Cursor：“用这个 React 组件，让每一行都可以拖动；保存排序结果；并生成测试。”
它确实做到了。我运行了测试，一切正常；然后我甚至没打开代码就把这个功能发布上线了。不是因为我做不到，而是因为我没必要。但这并不意味着我总是这样发布。大多数时候，我仍然会进行代码审查——只是现在，越来越多的时候，我不需要这么做了。
这并不是不规范的操作，也不是凭感觉“瞎写”。这种信任来自两点：第一，我知道如果出问题我可以调试并修复；第二，我拥有足够的验证信号来判断输出是否可靠。如果代码运行正常、测试通过、并且实现了需求，那我就不需要对每一行代码进行显微镜式的管理。这种转变已经发生，并且正在加速。
已经舒适地让渡控制权
这让我再次想到“网站可靠性”这件事。生产系统也正在朝着同一个方向发展：我们正走向一个软件能够自我监控、预测故障、并在人类介入之前悄然修复的世界。
想想空客是如何建议飞行员在遭遇湍流时保持自动驾驶的：计算机不会惊慌失措，也不会过度修正；它会平稳地应对。这就是未来运营系统的方向——系统能吸收各种颠簸，而无需你接管控制。
这种转变不会把人完全替代，但它会改变工作方式。我们不再需要整天盯着各种图表，因为关键决策不会再以“要不要点这个按钮”的形式出现在仪表盘上。Elastic、Grafana、Splunk 这类供应商不会消失，但它们必须重新定义自己的价值：在这个新世界里，软件会在发出告警之前就完成自我诊断与自我纠正。
而且这一切发生得比你想象的快得多。这并不是因为技术沿着缓慢、可预测的曲线成熟，而是因为激励机制极其残酷：最先把停机时间和值班呼叫消除掉的公司，将获得无可匹敌的优势；其他公司会争相效仿。用不了几年（抱歉，我的意思是几周），默认做法就会变成：为 MCP（标准机器控制平面）构建程序——它接收你的日志、解读你的信号、并代表你采取行动。如果你不为它写程序，你就会被淘汰。
更强大的原语（而我们也许尚未完全理解）
最后我想说：我大学主修计算机工程。我知道如何用 FPGA 设计一个 8 位微处理器……那是 90 年代末的事了。你觉得我完全理解现在这台笔记本里的苹果 M4 芯片吗？在概念层面，是的——我理解它的原理；但我并不知道每条指令在芯片内部究竟如何被执行。可这也没关系。
我们早就习惯了这种抽象。正如艾兹格·W·迪科斯彻所说：“抽象的目的不是为了含糊其辞，而是为了创造一个新的语义层面——在这个层面上可以做到绝对精确。”抽象为我们提供新的构建模块：更小、更清晰的思维单元，让我们不必盯着每一个晶体管，而能在处理器、操作系统、或编程语言的层面进行设计。
代码生成即将再次重新定义这种“构建模块”。它不仅是又一层抽象；它会成为我们思考软件方式的一种全新“原子”。一旦这种转变确立，我们将开始“升级”——不是因为我们知道得更少，而是因为我们将使用更强大的原语来构建软件。
二、解读：5问5答
1）作者的核心观点是什么？
作者认为：“写代码—读代码—逐行掌控”不再是软件工程的唯一中心。在可靠的验证机制（测试、运行结果、可观测信号）支持下，开发者会越来越多地接受“我不必逐行阅读也能上线”的工作方式——因为产出可被验证，且问题可被回滚/修复。
2）为什么作者敢“不打开代码就发布”？
他给出的“信任来源”有两条：
- 可修复性：出了问题我能调试与修复（能力仍在我这里）。
- 可验证性：我有足够的证据判断结果可靠（测试通过、功能符合、运行正常）。
换句话说，信任不是盲信，而是从“过程控制（逐行审查）”转向“结果控制（证据驱动的验证）”。
3）这和“网站可靠性/运维”有什么关系？
作者把它类比为从“人工驾驶”到“自动驾驶”的让权：未来生产系统会越来越像一个自动化的控制平面——提前预测故障、自行诊断、在告警前就修复。
这意味着传统运维的工作重心会变化：从“盯仪表盘、响应告警”转向“设计系统的自愈策略与控制逻辑”。
4）作者为什么强调“激励机制残酷”？
他想说明变化会很快，不是因为技术自然成熟，而是因为商业竞争强迫加速：谁能更早消除停机与值班成本，谁就获得优势；于是行业会迅速把“自动化修复/自动化运行”变成默认要求。
这里的逻辑类似：当某项能力直接改善成本结构与可靠性指标，它就会被迅速规模化复制。
5）“更强大的原语/新的原子”到底指什么？
作者把“代码生成”看成一种新的抽象层，但更激进：它会变成我们构建软件的基本单位——不再是“函数/类/模块”，而更像“用自然语言或意图描述生成可运行系统的构件”。
对应到工程实践，就是开发者的能力从“写每一行”迁移为：
- 提出正确问题与约束（需求表达、边界条件、非功能指标）
- 设计验证体系（测试、监控、回归、灰度、回滚）
- 在更高层做架构与风险管理（可解释性、可维护性、合规与安全）
