Heavybit 的 Joseph Ruscio 在 2026 年 2 月写了一篇 Write-Only Code。他的核心观点是：随着 AI 代码生成的普及，企业软件里将有越来越大比例的生产代码不再被人类逐行阅读，不是偶尔跳过，而是系统性地成为常态。
这不是在替「不 Review 代码」辩护，而是在描述一个结构性的现实：代码产量在增长，人的注意力没有。下面整理它的五个主要论点。
1. 核心判断：生产代码跑赢了人类注意力
AI 正在写大量企业软件。Ruscio 认为，更值得关注的变化不是「写得快了一点」，而是人类的审查能力正在跟不上代码产量。
他把这类代码称作 Write-Only Code（只写代码）：由机器生成、上线并运行，却没有人逐行阅读。人的责任并没有消失，但「理解每一行实现」不再是默认前提。
在这个框架下，工程师真正长期存在的工作是在模糊的业务目标与可靠的机器行为之间持续管理风险，而不是亲自编写每一行代码。
2. 历史类比：每去掉一个瓶颈，下一个就会露出来
企业软件交付曾经卡在物理基础设施：买服务器、上架、连网，等几个月才能跑起来。
云计算和持续交付之后，服务器从被精心照顾的「宠物」变成可随时替换的「牲畜」，直接登录生产机反而成了异常信号。
基础设施可编程之后，瓶颈转移到了开发者产能。如今 AI 代码生成正在移除这个限制，整个软件开发生命周期又要被迫重新调整。
写代码变便宜，并不等于软件变可靠。它只是把压力推到下一层：验证、隔离、观测、问责。
3. 从审查到信任：信心需要新的基础设施
当测试、监控和规格都不完善时，人工 Code Review 长期充当最后一道防线。大规模 Write-Only Code 会打破这个假设。
Ruscio 认为，团队需要从以下地方建立信心，而不是只靠「有人读过这次 Diff」：
- 清晰的接口与边界
- 不变量与约束（invariants）
- 自动验证
- 故障隔离与可控影响范围（blast radius）
- 可观测性
这些不会一夜到位。更现实的路径是：先从「故障容易被发现、影响容易被隔离」的领域开始，真正关键的系统继续保留人工审查。
4. 工程师的角色：从代码作者到系统管家
Ruscio 认为工程师的角色会继续偏移：
- 更像系统设计者、约束编写者、权衡管理者
- 更多时间塑造意图，更少时间打磨具体实现
- 接口、失败模式、保证条件、责任归属，会变成一等设计对象
这不是取消工程师，而是把工程师放回更高杠杆的位置：决定什么必须被人读，什么可以在无需逐行审查的情况下安全交付。
5. 结论：问题不在纪律，在于机制
Write-Only Code 并不是在主张「没人读代码是好事」。它描述的是软件产量超过人类注意力上限之后的现实。
若把未读代码简单归因为「纪律松懈」，就误判了问题所在。真正需要升级的是保障机制本身：建立更强的信任机制、更好的问责手段和更完善的控制工具，让系统在没有人逐行阅读的情况下依然可靠运行。
原文：Write-Only Code · Joseph Ruscio / Heavybit，2026-02-09。本文为读后整理，版权归原作者所有。