2026 年 6 月 15 日，两篇短文几乎同一天出现，说的却是同一件事的不同侧面：
- Honeycomb CTO Charity Majors：AI demands more engineering discipline. Not less——从 SRE 与不可变基础设施视角，论证 AI 时代要更多纪律，不是更少。
- 工程师 Matt Sayar：Yes, we still need engineers——从日常原型工作出发，列一张 「Loom 里很炫、离生产还很远」 的清单。
Charity 回答「哲学上该怎么想」；Matt 回答「具体还差什么」。合在一起，正好说明：人类编程（更准确说，人类工程）并没有过时——变的是分工，不是必要性。
下面是我读完两篇后的重排解读，不是翻译稿。
一分钟版
| 论点 | 内容 |
|---|---|
| 2025 变了什么 | 写代码从「贵、慢、稀缺」变成「近乎免费、即时、可再生」 |
| 代码的新角色 | 从「资产」变成 理解的物化视图（cache）——有用时保留，过时即删 |
| 人的强项 | 创意、灵感、跳跃推理——不是当最严的质量闸门 |
| 机器的强项 | 验证、重复、挑刺——人类在这方面是短板 |
| 核心结论 | 非确定性系统要 更多 工程纪律：规范、观测、生产验证，不是更少 |
| 2026 趋势 | 从 vibe coding 走向 回归纪律——先把知识编码进系统，再谈 AI 红利 |
| Matt 的补充 | Demo 加速「想法→沟通」；上生产仍要工程师填完长尾清单 |
Matt Sayar：Loom 很炫，生产很远
Matt 的工作流很典型：克隆 UI 仓库，打开 Claude Code，prompt 加一个按钮、造测试数据、录一条完整流程的 Demo。Loom 里看起来很好。 但他紧接着说——离 production-ready 还差一整座山。
他 随手 就能列出一串：后端、回归/功能/安全/性能测试、扩展性、边界情况、架构、无障碍、设计系统、可维护性、权限……以及日志/指标/追踪、监控告警、CI/CD 与回滚、Feature Flag、限流、幂等与并发、备份容灾、Schema 迁移、缓存失效、PII 与合规、鉴权与会话、多租户隔离、本地化、空态/错态/慢网络、成本、Runbook、文档……
有趣的是，清单后半截他自己也是用 Claude 生成的。这恰好是一个隐喻：
AI 能帮你 枚举「生产还需要什么」；但 谁来做、按什么标准做、出了问题谁扛——仍是工程师的工作。
Matt 的原话很直：觉得 vibe 出来的原型就能上生产的人，是在骗自己。 原型最大的价值是 把想法翻译成可讨论的东西——产品、设计、工程都能对着同一个 Demo 说话——而不是替代交付。
他还提到一个与舆论相反的数据点：2025 年 11 月代码生成质量拐点之后，他们团队 并没有因此少招工程师，反而在加人。软件业一贯自动化「无聊的部分」，好让人去做 解决真问题 的事——而真问题往往 不是多打几行字。
这和 Charity 的论点咬合：代码生成便宜了，「把系统做对、做稳、做久」并没有便宜。
Charity：先澄清她在反对什么
Charity 来自 SRE / 可靠性 一侧。她承认自己和同类人有时难以接受「进步是真的」——bug 还在，不代表大片问题空间没被大致解决。
2025 大部分时间里，「AI 代码是 slop、永远会是 slop」是主流默认立场。到 Opus 4.5（2025 年底）前后，局面翻转：对常见模式，AI 生成的代码 约等于中位工程师水平，且更快更便宜。Agent harness（工具循环、MCP 等）在 2025 年中后段成熟， enthusiast 说的「来得比你想的快」——他们是对的。
第一次「等眼见为实」可以理解；在指数曲线里第二次还同样观望，就难说了。
但她反对的是： 把「代码便宜了」理解成「Review、测试、生产 rigor 都可以省」。
2025 真正翻转的是「代码经济学」
历史上，人们主要通过 写代码 来理解软件；熟练之后靠读代码和讨论补全。SRE 一脉则一直强调：团队真正的产出是 production——「Only prod is prod.」
2025 发生的是：
造代码的成本被颠覆。 行数从被珍惜、复用、精心维护，变成 可丢弃、可整段重写。
另一派工程师认为，好团队真正的产品是 共享理解——意义活在人脑里，Git 和 prod 只是缓存。Charity 不否认协作与「部分大脑住在别人脑子里」的行业特质，但指出：人脑是糟糕的容器——健忘、习惯化、模型与用户真实体验 perpetual 脱节。
两边看似打架，她后面会收束到：当代码可再生，瓶颈就从「写」转向「评」和「守」。
Chad Fowler 的 Phoenix：这段我经历过
Charity 的兴奋点来自 Chad Fowler 的 Phoenix Architectures 系列。Chad 2013 年提出 Immutable Infrastructure；核心前提：
不要修正在跑的东西，替换它。
AI 把这一前提从基础设施 推到了应用代码：重写便宜时，原地改代码变风险——变异累积熵，替换才重置。
她引用的 「Deletion Test」 值得单独记：
想象删掉整个实现。若你不敢删，通常不是因为「代码本身神圣」，而是因为：
- 不知道必须满足哪些行为
- 不知道哪些失败不可接受
- 不知道哪些不变量必须成立
- 不知道怎样判定新版本正确
- 不知道哪些 bug 其实是 forgotten edge case 的修复
这些是评估问题，不是代码问题。 代码之所以显得珍贵，往往因为它是 知识的唯一存放处。
当再生成本很低，代码更像：
理解的物化视图——当前有用，过期可弃。
Charity 做过 sysadmin，亲历 宠物服务器 → cattle / 不可变基础设施。她在《Observability Engineering》第二版里写：可变性是理解的敌人，原地编辑制造 drift；能杀掉再拉起 Kafka 节点，是因为 bootstrap 可重复、承诺在别处。
代码不能同样再生，说明我们并不真正理解它——依赖关系、隐含契约，多半靠「弄坏了才发现」。
代码占用了本不该独占的注意力
因为维护行数太贵，很多领域被忽视：
- 架构图在哪？能否先对齐架构再 由架构生成代码，而不是从代码反推架构？
- 行为测试、characterization test、capture/replay——来自 QA 和运维的思路，工程圈 historically 有点 snobbish
- 这些不是测「应该怎样」，而是 编码「实际怎样」——加上好的 Observability
她 不 断言将来所有代码都会 AI 按 spec 生成、人类完全 bypass 理解——做过痛苦数据库迁移的人，对「形式化用户期望」应有 humility。但 每往 spec / 评估方向走一步，都是好事。
人类别抢机器的活：验证
非确定性代码进生产，终于逼我们做 早该做的事：
- Trace 级 instrumentation
- 生产里的 test / eval
- Production 不是开发结束后的阶段，而是开发的一个阶段
人类大脑 不擅长验证——挑剔、重复、逐行找茬。把「人类在软件里的护城河」押在 最佳质量闸门 上，她觉得是输家 argument。
创意、灵感、逻辑跳跃——人还能赢很久；验证请交给机器。
2026：纪律回归，不是纪律退场
许多工程师反感 AI discourse，是因为太多声音在喊「软件不再是工程问题」「SaaS 已死」。Charity 的立场相反：
非确定性系统需要更多工程纪律，不是更少。
- 2025 若是 vibe coding 年（代码生成 ≈ 中位工程师）
- 2026 像是纪律回归年
脑子里的知识 AI 用不到，除非你 编码进系统——这类投资的回报巨大且非线性。CEO 都在要 AI cookie；她的顺序是：纪律先行，cookie 其次。
行业里真正 短反馈环 的团队一直很少（她估 5%，肯定不到 10%）。AI 工具让纪律 更可达——但没有纪律的 AI 投资，她不太担心会产生断层式回报（很多人会试，会很好玩）。
价值最终 backed by durability，不是无限 disposable：用户不想每天登录 Slack 发现按钮 subtle 地换了位置，也不想要「大多数时候成功」的金融交易。确定性不会消失。
人类编程到底重要在哪
两篇合在一起，可以把这个常被吵糊的问题说清楚：
「人类编程」≠「人类打字」。 Matt 的原型里，Claude 已经替他写了大量 UI 代码；Charity 也预期更多实现会被再生、替换。若还把工程师价值绑在 手速 上，argument 确实站不住。
但 人类工程 至少还包括这些 AI 原型默认不会替你完成的事：
| 维度 | 人类在做什么 | Matt 清单里的例子 |
|---|---|---|
| 边界与失败 | 决定什么算 bug、什么可降级 | 错误处理、graceful degradation、重试与幂等 |
| 信任与安全 | 在威胁模型下做取舍 | 鉴权、PII、合规、审计 |
| 时间与规模 | 把「能跑」变成「能撑」 | 性能、扩展、缓存、成本 |
| 协作契约 | 让多方对同一「完成定义」对齐 | 设计系统、无障碍、文档、Runbook |
| 长期演化 | 为六个月后的自己留路 | 迁移、兼容、废弃策略、可观测性 |
Charity 说的 Deletion Test 和 Matt 的 「不敢删原型」 是同构的：若你只能指着 Loom 视频说「就要这样」，却列不出上面这些约束——那缺的不是模型能力，是 工程判断被编码进系统的能力。
所以「仍需要工程师」不是说 仍需要人肉补全每一行 CSS，而是：
- Prototype 阶段——人定问题、定范围、定 Demo 要证明什么（Matt：沟通加速器）。
- Production 阶段——人（ increasingly 借助 AI）把 Matt 那张长尾清单 逐项落地，并把 Charity 说的 eval、trace、生产验证 写进流水线。
- 演进阶段——人决定何时整段替换实现、何时守 invariant 不动（Charity：Immutable / Phoenix 思维）。
AI 越会写代码，第 2、3 步的相对权重越高——这正是「更多纪律，不是更少」的通俗版。
对我这类读者的 takeaway
- AI 让代码变便宜，没有让「什么叫对」变便宜。 Deletion Test 问的是 eval、spec、invariant 在哪；Matt 的清单问的是 上生产还缺哪几类能力。
- Demo 是资产，不是交付物。 用来对齐认知；别用 Loom 的流畅掩盖 Matt 列出的那一长串空白。
- Review 的对象在变。 从逐行抠 diff，转向架构 artifact、行为契约、生产信号——和 Charity 在 Honeycomb 做的事同构。
- 别和机器比挑刺，也别假装机器能替你扛生产。 验证、监控、合规类重复劳动交给工具；范围、取舍、责任 仍在人。
- Immutable 思维可以上移一层。 实现可替换，行为与承诺 要显式化——否则 AI 只会更快地产出 能跑但不敢删 的代码。
Charity 结尾说期待新 artifact、永远不要再做两年 API 重写；Matt 结尾说软件业会继续自动化无聊部分、让人做有趣的问题——有趣的问题里，很大一部分正是「怎么把 Demo 变成用户敢用的系统」。 那仍然是工程师的事。
参考
- Charity Majors — AI demands more engineering discipline. Not less
- Matt Sayar — Yes, we still need engineers
- Charity 前作：AI enthusiasts are in a race against time…（2026 年 6 月）
- Chad Fowler：Phoenix Architectures 系列（含 The Deletion Test、The Death and Rebirth of Programming）
本文为阅读笔记与重排解读，不代表原作者立场。