上个月，Rails 之父 DHH 在 Rails World 上宣布 37signals「pencils down」，不再把手写代码当正常生产方式——这件事我们之前聊过了。
但真正值得追的，是那句话之后的余波。
The Pragmatic Engineer 的 Gergely Orosz 写了一期 The Pulse，把这件事引发的连锁反应串了起来。结论有点刺：手写代码是不是死了，可能还要吵；但软件质量正在肉眼可见地崩，这件事已经不需要吵了。
先补一句 DHH 最狠的话之前我们引的是他「手写代码是异常状态」那段。但 Gergely 挖出了更狠的一句——DHH 说自己连「职业程序员」这个身份都退休了：
> 我大概在 4 到 5 个月前退休了，也许是 3 月。我花了四分之一个世纪手工雕琢代码，而且乐在其中。这不是要带着遗憾回望的事；这是要带着喜悦回望、并接受它已经结束的事。
>
> 对绝大多数公司的绝大多数程序员来说，手写代码已经不再是一项有经济产出的活动了。
他还给了一个时间点，说是 AI 时代的「柯达布朗尼时刻」：2025 年 11 月 24 日，Opus 4.5 发布。 「历史书往后会把这个日子标记为 agent 时代的拐点。」
顺带一个细节挺有象征意义：37signals 正在把后端服务迁到 Rust（性能原因，也因为「agent 写 Rust 足够好」）——这话从 Ruby on Rails 创造者嘴里说出来，分量不轻。而 Rails 之所以还留着，恰恰是因为它「约定优于配置」的设计对 agent 友好。
然后是一封让全网破防的匿名吐槽就在上个周末，一位 Big Tech 工程师用 ID「voxium」发了段吐槽，戳中了一大批人：
> 现在工程的状态糟透了。我入职一家大公司才半个月。
>
> 这里没人懂任何东西。spec、代码、测试、PRD、ticket、ticket 的处理、报告……全都是 Claude Code 做的。我们团队没人喜欢这样。
>
> 他们被逼着尽可能多地上线。我从高层听过好几次：既然推代码不是瓶颈，那我们为什么这么慢？
>
> 大家一天干 12 到 13 个小时，就为了按回车。没人在读任何东西。公司里的人类，什么都不是自己做。
>
> 从 L1 到 L7，每一个人，真的每一个人，都在做同一件事：跟 Claude 说话。
>
> 没有胜利感。没人在解 bug。现实中，没人在思考了。 一切都是 LLM 做的。太掏空灵魂了。
>
> 说实话，如果我们至少有时间去看看代码、看看发生了什么，我也不会介意。但没有，目标就是上线。不管发生什么。
Gergely 的判断是：这段话之所以「听起来是真的」，是因为它真的在很多 AI 用得越多的地方发生——工程师把「思考」外包给了 LLM，最后除了「往生产环境塞点什么」之外，什么都不在乎了。
质量下滑不是感觉，是有证据的Gergely 自己就抓了个现行。他这周用 Uber Eats 点餐，撞见一个新上线的「加料选择器」功能，一眼看出三个 bug：
「最多可选 999」：没有工程师、设计师或 PM 检查过「餐厅没填数量」或「填了个离谱数字」会怎样。他屏幕上最多只能选 6 个，所以连「999 个汉堡」这个选项都选不了。文字溢出：他在 Uber 时的经验法则是「文字永远不该溢出，本地化之后也不行」。结果荷兰语的「basil mayo」（basilcummaynaise）破了这条规矩，还照常上线了。选择器功能 bug：他想点一份「不要米饭或麦粒」的墨西哥碗，但选「nothing」会被算成额外配菜，app 根本不让他下单一个没有底料的碗。他的原话是：用了 Uber Eats 这么多年，这是第一次看到这么潦草的功能发布。唯一的解释是：做它的开发和 PM 都「躺平」了，不做正经 QA，默认 agent 会兜住一切。
（顺带说，Uber Eats 团队后来主动联系，说会修这三个问题。）
但 Gergely 的反转：软件工程会变得比以往更重要这里是最有意思的地方。Gergely 说自己已经走过了「agent 抢走编码」的震惊和悲伤阶段。他一开始也以为这会让工程师的工作变少，结果恰恰相反：
一，我们需要更懂 LLM 的特性。 LLM 看起来像人，因为它能像人一样产出文本——但它更不可靠、会幻觉、会有「能力煤气灯」（capability gaslighting），还可能又贵又慢。这些都得被工程化地理解。
二，需要被工程化的系统是全新的。 现在有了 agentic「软件工厂」，能根据输入产出代码——但这些代码怎么验证？ 缺陷检测能自动化到什么程度？这是个全新领域，要靠老思想搭新系统。他点名的例子：OpenAI 的软件工厂，以及 Ramp 内部的 Inspect coding harness。
三，一个被严重低估的方向：用 LLM 生成「确定性代码」来替代 LLM。 比如：与其在所有 PR 上跑又贵又慢的 AI code review，能不能让 AI 生成 linter，去抓大多数常见问题？如果可行，复杂 lint 规则会比 LLM 调用更快、更可靠、更便宜。
他的结论是：那些「懂」LLM 和 AI 工程的工程师，会去构建全新类别的系统和产品。 对跟得上技术的人来说，这其实是好消息——公司在投创新，而且愿意为能帮他们做 AI 产品或变成 AI-native 的软件工程师付市场顶薪。
这对你意味着什么一，「不思考」才是真正的风险，不是 AI。 voxium 那段吐槽里最扎心的不是「代码是 AI 写的」，而是「没人在思考了」。DHH 说要重新审视「抽象」——因为在 agent 时代，重复的代价趋近于零，为「不重复自己」而做的抽象，可能不再划算。但判断力反而更值钱了。
二，验证是新的护城河。 当产出代码的成本趋近于零，瓶颈就全压在「怎么验证」上。无论是人工审查、Computer Use 自动化测试，还是「让 AI 生成 linter」，本质都是在造验证系统。
三，DHH 的话要打折听。 那些数字（CPU 少用 99% 之类）都是 37signals 自报、没有第三方验证；而且性能提升可能来自语言之外的东西。认真地说，应该讲「DHH 声称」，而不是当成普遍规律。
四，质量下滑已经是可以观测的现象。 从 Spotify 的莫名宕机，到 Uber Eats 的潦草发布，再到匿名工程师的咆哮——这不是个别现象，是一整套「只求上线、不求正确」的工作方式在扩散。
一句话收尾：代码正在变得便宜，而判断正在变得昂贵。 手写代码死没死可以继续吵，但「谁来为这堆没人读过的代码负责」这个问题，已经摆到每个人面前了。

来源：blog.pragmaticengineer.com/the-pulse-ror-creator-sparks-new-death-of-coding-by-hand-debate