放下铅笔，睁大眼睛：Rails 开发者在 Rails World 之后

# 放下笔，睁开眼：一位 Rails 开发者参加 Rails World 后的思考 来源：https://caio.ca/blog/pencils-down-eyes-open-rails-world DHH 在 Rails World 的主题演讲让我以一种我认为有益的方式感到不适。我花费十多年构建 Rails 应用，尚未准备好将我热爱的工作部分视为过时的爱好。 但我不愿让这种不适演变成商业计划。我想知道什么发生了变化，什么没有，以及像我这样的开发者在智能代理承担更多编码工作时能提供什么价值。 更快的速度，更大的责任：工程师界定工作范围、审查成果并为最终交付负责。键盘只是工作的一部分。责任感贯穿始终。 ## 我从演讲中汲取的要点 在演讲进行到 20:45 时（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=1245s），DHH 阐述了 37signals 的新“放下笔”政策：手写代码现在是其正常工作流程的例外情况，而非完全禁止。如果智能代理无法处理某项任务，团队可以手动完成并随后改进工作流程。这对一家公司而言是激进的选择，并非要求每位开发者明天都必须遵从的指令。 让我无法释怀的细节是他关于 Basecamp 5 的故事（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=1354s）。设计师引入了数十个由智能代理生成的代码拉取请求，这些请求单独看似乎合理，但整体上却让架构看起来像“瑞士奶酪”。当时团队回归了更多由程序员主导的工作；DHH 现在认为，更好的智能代理和更好的工作流程才是前进的方向。他并未展示由智能代理主导修复这一特定问题的方法。对我而言，教训在于：一系列看似合理的代码差异并不等同于一个连贯的系统。 这当然不是 Rails 的悼词。DHH 描述了 HEY 正在进行的原生客户端和 Rust 后端方向（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=1535s），然后论证了 Web 仍然重要，而 Rails 的约定有助于智能代理（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=1998s）。我不需要 Ruby 在所有用例中胜出，也能继续发现它在擅长的工作领域非常有用。 可以从“放下笔”这段开始，或在 YouTube 上观看完整演讲（https://www.youtube.com/watch?v=vDjW_dRyKXY）。 ## 我有所保留的部分 五月时，我曾撰文讨论编码开始失去什么（https://caio.ca/blog/what-coding-is-starting-to-lose.html），起因是一个模型帮助我在十二分钟内修复了一个后台任务的竞争条件。测试通过了。我仍然怀念那个缓慢学习为何会出现错误的过程。如果我是那个必须理解下一次故障的人，那就不只是怀旧。 我乐于让智能代理起草枯燥的部分、建议方法，或探索我本无暇尝试的替代方案。我不认为在我需要心智模型时亲手编写一个小而复杂的代码段是失败。我也不认为手打样板代码是一种美德。真正有用的问题是：什么能帮助我理解并安全地维护这个特定系统？ 那些惊人的数字也应得到同样审慎的看待。DHH 从 100 倍到 1000 倍的比较（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=1034s）是针对最佳辅助程序员与最差非辅助程序员的推测，并非对普通团队的实测加速比。他认为手写代码对大多数程序员和公司而言已经不经济，并预测几乎所有领域到 2026 年底都会如此（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=2440s）。这是他的经济押注，并非对我职业生涯的实测期限。 他引用了早期更简单的 Rails 智能代理测试中接近 95% 的成功率（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=2063s）。主题演讲中更复杂的功能任务幻灯片（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=2084s）在所展示的努力程度下最高达到 35%。在一次最大努力的评估中（https://rubyonrails.org/2026/9/21/agents-on-rails-maximum-effort-and-deepseek-4-1-flash），在该组 20 个任务上，最佳模型在 53% 的运行中通过，但消耗了额外时间和成本。这是真实的进步，而非生产环境的可靠率，或跳过代码审查的理由。 ## 我认为我的职业生涯将如何发展 一些工作将需要更少的开发者工时。公司可能会以不同方式招聘，更容易的原型设计意味着更多人可以竞争构建相同的东西。DHH 以银行柜员的类比（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=3385s）来暗示自动化能创造新需求。我理解他的观点，但他引用的历史数据和数字与现有报道不符（https://conversableeconomist.blogspot.com/2015/03/atms-and-rising-number-of-bank-tellers.html），而且一个类比无法预测 Rails 的招聘情况。承诺每个现有岗位都安全是不诚实的。同样，仅从一场演讲就推断不再需要软件工程师也是不诚实的。 我写 Ruby 已有十五年多，构建 Rails 应用也超过十年。这种经验并非围绕编写 Ruby 的护城河。它帮助我识别简单修改在何处不再简单。在我关于 Sidekiq 到 Solid Queue 迁移指南（https://caio.ca/blog/migrating-sidekiq-to-solid-queue-rails-8.html）中，切换适配器很容易描述；安全地排空旧任务和计划任务才是真正的难点。智能代理可以协助更改，但一个仅通过的差异文件无法告诉你旧队列中还有什么。 一个三步工程循环：明确意图、验证行为、负责交付。我希望负责的工作，无论代码是否由我编写。 我想将模糊的请求转化为清晰的约束，为智能代理提供有界限的任务，并将它们节省的时间用于测试、数据边界、安全、部署和回滚。有时这意味着我自己编写代码。始终这意味着我们清楚要求是什么、得到了什么，以及客户将会体验到什么。 DHH 还设想应用拥有可让用户自身智能代理操作的命令行界面（https://www.youtube.com/watch?v=vDjW_dRyKXY&t=2715s）。这是一个有趣的方向，也是一个关于谁被允许做什么的实际问题。 ## 快速审查练习 **你会发布这个吗？** 在打开每个答案前做出判断。这是一个通过的差异文件背后的工作。 智能代理将 Sidekiq 替换为 Solid Queue。测试通过。在同一次部署中关闭旧工作进程？**还不行。**首先需要考虑 Sidekiq 中排队、计划和重试的任务；在新任务迁移过来的同时运行两个系统，观察旧队列排空，并规划重复任务和回滚。通过的测试套件无法告诉你 Redis 已清空。 一个新应用的命令行界面让智能代理可以调查客户问题。是否要给它一个生产 API 密钥以加快速度？**不能给无限制的密钥。**从有范围、可审计的命令开始。不要将广泛的凭据暴露给智能代理的提示、环境或工具；限制其网络访问，只授予必要的权限。测试不可信的客户数据能使它做什么，并要求对不可逆转的操作进行人工决策。一个能工作的工具不自动是安全的。 我可能对放下我的笔这个想法有点抵触。但我也能看到机会：Rails 的约定、来之不易的调试直觉以及使用新工具的意愿，这三者是一个有用的组合。目标不是为我本会写的每一行代码辩护，而是帮助团队交付可信赖的软件。