放下铅笔，睁开眼睛：Rails World 之后的一个 Rails 开发者

← 首页

DHH 在 Rails World 上的主题演讲让我感到一种不适，而我认为这种不适是有用的。我做了十多年 Rails 应用，还没准备好把自己热爱的那部分工作当成过时的爱好。

但我不想让这种不适变成一份商业计划。我想弄清楚什么变了、什么没变，以及当 agent 承担了更多敲代码的活儿之后，像我这样的开发者还能提供什么。

键盘只是这份工作的一部分。责任贯穿始终。

我从主题演讲里读到了什么

在演讲的第 20:45 处，DHH 解释了 37signals 新的“pencils down”政策：手写代码如今是正常工作流程的例外，而不是被禁止。如果 agent 处理不了某个任务，团队可以手动完成，事后再改进工作流程。这对一家公司来说是激进的选择，而不是要求每个开发者明天都必须照做的指令。

让我挥之不去的细节，是他讲的 Basecamp 5 的故事。设计师提交了几十个 agent 生成的 pull request，单独看每个都说得过去，合在一起却让架构变得像“瑞士奶酪”。当时团队回到了更多由程序员主导的工作方式；DHH 现在认为更好的 agent 和更好的工作流程才是出路。他并没有展示用 agent 主导修复那个具体问题的过程。在我看来，教训是：一堆看似合理的 diff 加起来，并不等于一个连贯的系统。

另外，这不是给 Rails 写的悼词。DHH 描述了 HEY 正在推进的原生客户端加 Rust 后端的方向，随后又论证 Web 依然重要，而 Rails 的约定对 agent 有帮助。我不需要 Ruby 在每个场景里都赢，也能继续觉得它在自己擅长的领域里有用。

可以先从 pencils-down 那段看起，或者在 YouTube 上观看完整主题演讲。

我抗拒的那部分

五月，在一个模型用十二分钟帮我修好一个后台任务的竞态条件之后，我写过编码正在失去什么。测试通过了。我仍然怀念那个慢慢弄明白 bug 为什么发生的过程。如果接下来还得由我去理解下一次故障，那这就不只是怀旧。

让 agent 起草枯燥的部分、提出方案思路，或者探索一个我本来没时间尝试的替代方案，这些我都乐意。需要建立心智模型时，亲手写一小段棘手的代码，我不觉得这是失败。手敲样板代码也不是什么美德。真正有用的问题是：什么能帮我理解并安全维护眼前这个具体系统？

那些大数字同样值得认真对待。DHH 的100 到 1000 倍对比说的是最好的辅助程序员与最差的非辅助程序员之间的猜想，不是普通团队实测的提速。他认为手写代码对大多数程序员和公司来说已经不划算，并预测到 2026 年底几乎所有领域都会如此。这是他的经济赌注，不是对我职业生涯的实测截止日期。

他引用的是早期一个更简单的 Rails agent 测试中接近 95% 的成功率。主题演讲中更难的功能工单幻灯片在所示投入下最高只有 35%。在一次最大投入的评估中，最好的模型在那 20 张工单上通过了 53% 的运行，代价是额外的时间和成本。这是真实的进步，不是生产环境的可靠性指标，也不是跳过 review 的理由。

我认为我的职业生涯会怎样

有些工作需要的开发者工时会更少。公司招人的方式可能改变，原型开发变容易意味着更多人能竞争做同一件事。DHH 用银行柜员的类比暗示自动化可以创造新需求。我明白他的意思，但他给出的历史日期和数字与现有报道不符，而且类比预测不了 Rails 的招聘。承诺每个现有岗位都安全是不诚实的。从一场主题演讲推断没人再需要软件工程师，同样不诚实。

我写 Ruby 超过十五年，做 Rails 应用超过十年。这些经验不是围绕“敲 Ruby”的护城河。它帮我识别一个简单的改动在哪里不再简单。在我的 Sidekiq 迁移到 Solid Queue 指南里，切换 adapter 很容易描述；安全地清空旧任务和定时任务才是真正的工作。agent 可以帮忙完成改动，但一个全绿的 diff 本身不会告诉你旧队列里还堆着什么。

这是我想负责的工作，不管代码是不是我敲的。

我想把含糊的需求变成清晰的约束，给 agent 划定有边界的任务，把它们省下来的时间花在测试、数据边界、安全、部署和回滚上。有时这意味着自己写代码。但永远意味着：清楚我们提了什么要求、得到了什么、用户会体验到什么。

DHH 还设想了一种带 CLI、用户自己的 agent 可以操作的应用。这个方向很有意思，也引出一个实际问题：谁有权做什么。

一个小练习

你会发布吗？

每道题先自己判断，再看答案。这就是绿色 diff 背后的工作。

一个 agent 把 Sidekiq 换成了 Solid Queue。测试通过。在同一次部署里关掉旧的 worker？ 还不行。 先盘清 Sidekiq 里排队中、已调度和正在重试的任务；让两套系统并行运行，新任务逐步迁移，盯着旧队列排空，并为重复执行和回滚做好准备。测试全绿并不能告诉你 Redis 是空的。

新的应用 CLI 让 agent 可以排查客户问题。给它一把生产 API key 让它跑快点？ 不能给不受限制的。 从有范围、可审计的命令开始。不要把宽泛的凭证暴露在 agent 的 prompt、环境或工具里；限制它的网络访问，只授予必要的权限。测试不可信的客户数据能让它做出什么事，不可逆的操作必须由人决定。工具能用，不等于它安全。

放下铅笔这件事，我多少有点抗拒。但我也看得到机会：Rails 的约定、多年调试练出的直觉，加上愿意用新工具，这个组合很有用。目标不是守住每一行我本来会写的代码，而是帮团队交付他们信得过的软件。