Ruby on Rails 的创造者 David Heinemeier Hansson 上周在 Rails World 主题演讲中的言论引起了不小的轰动，他透露在他的公司 37signals，手写代码已经死了。

这是一件大事，因为 37signals 创造了 Ruby on Rails，而且他们以软件工艺闻名，尤其是在代码质量方面。这还是一家已有 27 年历史且盈利的企业。尽管有着这样的资历，DHH 还是在开发者社区中引起了轰动，他说：

“在 37signals，几周前，我们做出了决定，这显然意味着我们不再手写代码了。我们已经放下铅笔，不再把作为正常业务创造流程的一部分来手写代码当作常态。在 37signals，手写代码现在是一种例外状态。这就像在 Sentry 中看到一个 bug：这里出了问题；为什么智能体没能产出我们想要的东西？好吧，也许有一小段时间，我们还会拿出旧铅笔替它们记下来，但之后我们会修复机器，修复工厂，让事情重新运转起来。这是对已经在发生的事情的承认。”

DHH 将 AI 工具逐渐成熟、在编码方面变得极为强大，与相机出现对绘画工艺的影响进行了比较：

“2025 年 11 月 24 日，我们得到了这个时代的‘柯达布朗尼’。我们得到了 Opus 4.5。AI 技术以一种许多人负担得起使用的工具形态出现，并第一次体验到与一种新智能形式结对创建软件是什么感觉。这对我来说是临界点。11 月 24 日之前的一切是一个时代，之后的一切则是另一个时代。这将成为未来的历史书标记智能体时代拐点的日期。”

他分享了 37signals 如何拥抱一个几乎完全不再手写代码的未来：

• 拥抱原生移动应用而非 Web：众所周知，37signals 对原生 iOS 和 Android 应用并不看好，而是构建了 Web 版本。借助 AI，他们押注原生应用将更容易由小团队构建，并且已经在构建新的原生应用。

• 将后端服务迁移到 Rust，而不是 Ruby：这是出于性能原因，也因为智能体能够写出足够好的 Rust。从 Ruby on Rails 的创造者口中听到这一点，实在令人瞩目！

• Web 应用仍保留 Ruby on Rails：37signals 并没有抛弃 RoR，但这只是因为 Ruby on Rails 的约定优于配置设计让智能体更容易使用它。

DHH 最后透露，他甚至不再把自己视为职业程序员（重点为我所加）：

“我已经从职业程序员退休了。我想大概是在四五个月前，也许是三月。我花了四分之一个世纪手工雕琢代码，并热爱其中的每一刻。这不是一件要带着遗憾回顾的事；这是一件要带着喜悦回顾并接受它已经结束的事。对于绝大多数公司中的绝大多数程序员来说，手写代码不再是一项经济上高产的事业。在另一边，是一种新的职业：作为职业造物者，驾驭直到不久前还只存在于科幻中的智能。我们必须重新审视的一件事，是我们自以为知道的关于软件架构的一切。我们长期以来使用的主要工具是抽象。在智能体时代，抽象不再具有完全相同的意义。我们进行抽象的部分原因是为了不重复自己；好吧，现在重复的代价已经几乎降为零。”

值得注意的是，DHH 的主题演讲为一场由在个人和职业上都投入于构建软件工艺的工程师参加的会议选择了一个颇具争议的话题！

手工编码的衰落早已被预言

在今年1月6日的The Pragmatic Engineer第一期文章中，我写道：

“当AI编写几乎所有代码时，软件工程会怎样？这不再是一个假设性问题，而是一个即将冲击科技行业的巨大趋势。(...) 坏消息是，变化可能会很迅速。距离Claude Code的想法在Boris Cherny脑海中诞生还不到一年，像OpenCode、Codex、Factory、Amp、Cursor这样的类似工具以及更强大的智能体已经在改变软件的编写方式。变化一直是科技工作的一部分，但我不记得有过如此之快的变化，或者整个行业同时发生的变化！”

我得出结论，这种变化正在到来，基于我自己使用Opus-4.6和GPT-5.2构建软件的经验，以及与经验丰富的工程师的交谈——他们曾有理有据地抵制“AI炒作”，但后来逐渐认识到AI现在可以在许多情况下生成“足够好”的代码。

当时，我对当AI智能体为工程师生成大部分代码时会发生什么做了一些预测：

• 更草率的代码

• 薄弱的软件工程实践会更早造成伤害

• 不是软件工程师的“编码员”需求减少

• 工程师的工作与生活平衡更加艰难

• 初级工程师被快速推向高级

• 新员工越来越需要计算机科学教育背景

• 代码和软件的大规模爆炸，必须有人对其负责

到目前为止，这是一个混乱的过渡期，我们工程师对大量并非由我们编写、但仍在生产环境中运行的代码负有责任和问责。

非工程师也在进入智能体领域

在1月底，我分享了一篇对我而言非常贴近生活的深度报道：我兄弟那家拥有30人、15名工程师的初创公司Craft Docs，通过为非工程师构建自己的AI工具链——名为Craft Agents——实现了向AI的急剧转型，这比Claude Cowork发布早了两周，比ChatGPT Work推出早了数月。

Craft在AI感觉没有生产力时抵制了使用它的诱惑，但随着2025年11月的模型发布，他们发现LLM不仅对编码有用，对客户支持等非工程工作也有用。在深度报道中，我更详细地介绍了非工程用例（由工程师赋能），例如：

• 使用智能体自动分类错误报告

• 在所有工作流中添加数据丰富化

• 客户支持“技能”，如处理功能请求

• 营销团队在没有开发人员的情况下构建网站

• 人力资源自动化繁琐工作

• 财务自动化个人工作流

Craft Docs似乎早早抓住了这一已变得更加普遍的趋势，让自身的工程和非工程人员都接入AI工具链。现在，有迹象表明其他公司也在做同样的事情：在OpenAI，财务、招聘和法律等非工程部门已于2026年6月迁移到Codex：

在某些方面，知道不仅是软件工程领域的工具和工作流程在快速变化，可能会让人感到些许安慰：科技行业中的其他职能也在经历同样的变化！

目前局面很混乱

就在上个周末，一位大型科技公司的匿名工程师的吐槽触动了许多业内人士的神经。一位用户名为 voxium 的工程师发帖称（着重号为笔者所加）：

“当前工程领域的状况糟透了。我在一家大公司开始新岗位已经半个月了。这里没人懂任何东西。规格文档、代码、测试、PRD、工单、工单的解决、报告等等，一切都是 Claude Code 生成的。我团队里没人喜欢这样。他们被迫尽可能多地交付。我多次从高层管理那里听到，推送代码不是瓶颈，那我们为什么还这么慢？人们每天工作 12 到 13 个小时，只是为了按回车键。没人在读任何东西。企业里的人自己不思考任何事情。每个人，真的是每个人，从 L1 到 L7 的工程师都在做同样的事。跟 Claude 对话。没有任何成就感。没人在解决 bug。实际上，没人在思考了。一切都由 LLM 完成。这太消耗灵魂了。说实话，如果我们至少有时间去看看代码、了解发生了什么，我不会介意。但没有，目标就是交付。不管发生什么。”

这个帖子引发共鸣，因为它正在许多 AI 使用更多的地方发生：工程师将思考“外包”给 LLM，最终除了向生产环境交付东西之外，什么都不关心。

质量在下降

自今年年初以来，软件质量几乎在所有地方都在下降，其中很大一部分原因是过度依赖 AI，或者更准确地说，是将思考和决策外包给 AI。7 月，在一系列无法解释的故障之后，我将我的视频播客从 Spotify 迁移了出去，而 Spotify 的工程团队似乎对修复问题的根本原因没有真正的自豪感或责任感。

就在本周，Uber 在 Uber Eats 应用中向生产环境发布了一项新功能——一种选择餐品附加项的新方式——似乎没有经过任何 QA 测试：

在 Uber Eats 这个新的“附加项选择器”中，我一下子注意到了三个 bug：

• “最多选择 999”：没有工程师、设计师或 PM 费心去检查当餐厅没有填写可添加多少种配料的数量，或者填了一个荒谬的大数字时会发生什么。我的屏幕允许选择的最多配料数是六，而不是 999，所以我甚至无法为我的汉堡选择 999 个面包的选项。

• 草率的溢出。我在 Uber 工作期间的一条经验法则是，文本永远不会溢出，即使本地化后也是如此。Basilcummaynaise（荷兰语中的罗勒蛋黄酱）打破了这个规则，但仍然发布了。

• 选择器中的功能性 bug。我最初尝试从我最喜欢的墨西哥餐厅点餐：一碗不加米饭或碾碎干小麦作为基底的餐品。有选项可以选择“米饭”、“碾碎干小麦”或“什么都不加”作为基底，但选择“什么都不加”会被算作额外配菜，而应用不允许点一碗没有基底的餐品。

我用 Uber Eats 应用已经很多年了，这是我第一次看到如此草率的功能发布。我猜构建它的开发者和 PM 都已经“躺平”了，不再做正规的 QA，并认为智能体会处理好一切。没有其他方式可以解释三个 bug 被发布给所有客户，却似乎在我发帖之前没人注意到。值得肯定的是，Uber Eats 团队主动联系了我，并正在着手修复这三个问题。

软件工程将比以往任何时候都更加重要

我个人已经度过了智能体接管编码活动所带来的震惊和悲伤阶段。起初，我以为这一变化会减少工程师的工作量。但出乎意料的是，工作量实际上似乎在增长：

• 我们需要更好地理解 LLM 的特性。LLM 让人感到熟悉，因为它们能以过去只有人类才能做到的方式生成文本。但它们的可靠性较低，仍然容易出现幻觉，存在能力认知偏差（capability gaslighting）以及许多其他问题。它们还可能既昂贵又缓慢。

• 新系统需要被工程化构建。智能体“软件工厂”现在可以根据提供的输入生成代码。但这些代码如何验证？检测缺陷或各种问题能在多大程度上实现自动化？这是一个全新的领域，我们需要构建新型系统，往往基于旧有的理念。其中一个例子是 OpenAI 的软件工厂，另一个是 Ramp 的 Inspect 内部编码工具链。

• 非确定性的 LLM 可以生成确定性的代码。我认为一个尚未被充分探索和重视的领域是：利用 LLM 生成确定性代码，来替代智能体“软件工厂”中对 LLM 的使用。例如：与其对所有 PR 请求运行昂贵且缓慢的 AI 代码审查，AI 能否生成 linter 来捕获大多数常见问题？如果这可行，复杂的 lint 规则将比 LLM 调用运行得更快、更可靠、成本更低。

新类别的系统和产品将由那些“真正理解”LLM 和 AI 工程的工程师来构建。我们看到大部分风险投资正涌入 AI 公司，因为 AI 创造了新的商业模式、新的收入来源，并颠覆了“传统”软件。例如，谁能想到公司会为每位工程师在 AI 编码工具上花费数万美元？或者 AI 推理提供商这一类别会从两年前几乎不存在发展到如今如此庞大的规模？

这一技术变革将重新调整科技行业的部分格局：赢家必将大获全胜，而选择不作为的团队和公司可能会被灵活的竞争对手超越和取代。在许多方面，这对我们这些紧跟技术发展的软件工程师来说是个好消息。公司现在正在投资创新，并愿意为能够帮助他们构建 AI 产品或实现 AI 原生的软件工程师支付市场顶级薪酬。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：The Pragmatic Engineer

原创地址：https://blog.pragmaticengineer.com/the-pulse-ror-creator-sparks-new-death-of-coding-by-hand-debate/