DHH 论 Agentic Engineering

来源：DHH (37signals 创始人，Ruby on Rails 创造者)

核心观点

1. 开发哲学的转变

DHH 对 AI 的哲学没有改变，但可用工具已经彻底改变。

• 6 个月前的自动补全式编码助手对资深开发者来说很烦人
• 从 tab-completion 到 agent harnesses 的转变改变了局面
• Opus 4.5 等强大模型的出现——agent 开始生成 DHH 愿意直接合并的代码

2. 美丽的代码是正确性的信号

"When something is beautiful, it's likely to be correct."

• Steve Jobs 希望电脑内部也美丽，因为关心电路板布局的人也会关注 UI 细节
• 美丽的代码和产品不是虚荣，而是正确性的信号

3. 当前开发工作流

DHH 现在的开发设置：

• tmux：分屏运行两个模型
• neovim：中央编辑器
• Lazygit：用于审查 diffs

具体配置：

• 一个终端运行快速 LLM（通常是 Gemini 2.5）
• 另一个终端运行慢但更强的模型（通常是 Opus）

4. Ruby on Rails 的复兴

Rails 正在享受 AI 带来的复兴：

• 构建 Web 应用最 token-efficient 的方式之一
• 测试内置于框架，帮助 agent 编写测试并验证输出
• 生成的代码人类可以阅读和验证——这对快速审查 agent 输出很重要

5. AI Agent 的最大收益

** tackling 以前不会考虑的工作**

案例：37signals 的一位资深工程师进行 "P1 optimization" 项目，将最快 1% 的请求从 4 毫秒优化到半毫秒以下——这种工作以前不会被考虑！

6. 穿着机甲套装

运行多个 AI agent 的感觉：

• 不像"项目管理"
• 更像"穿着机甲套装"

DHH 不喜欢做 agent 的项目经理，但现在感觉他在控制被超加速的工作。

7. 资深工程师比初级受益更多

37signals 和 Amazon 都得出相同结论：

• 资深工程师能验证 agent 的输出是否可用于生产
• Amazon 不再允许初级程序员未经审查就将 agent 生成的代码发布到生产环境

8. 设计师即实现者

37signals 的比例：1 名设计师 : 2 名工程师

设计师做的远不止设计：

• 也是产品经理
• 也是"实现者"
• 决定应该构建什么、如何工作
• 经常构建第一个版本

DHH 将设计比作珠宝设计："你应该了解黄金的属性，知道它如何弯曲。"

9. AI 将推广 37signals 的"设计师模式"

AI 工具让设计师能够直接实现更多愿景。 DHH 怀疑行业正在 converging 到 37signals 一直以来的做法：

• 小团队工作
• 设计师也是构建者

10. CLI 是终极 AI 界面

"Command Line Interfaces feel like the ultimate AI interface, which validates the Unix philosophy of the 1970s."

DHH 正在为所有 37signals 产品构建 CLI，因为：

• 让 agent 可以链式调用工具
• GitHub、Sentry 都有 CLI
• Agent 可以：检查错误 → 写修复 → 提交 PR → 向 basecamp 报告

11. Shape Up 方法论的终结

《Shape Up》中描述的两个月产品开发周期现在需要重写，因为 AI 加速让那个时间线感觉太慢。

12. 8 小时睡眠不可妥协

即使在 AI 淘金热中，DHH 也坚持 8 小时睡眠。

原因：与 agent 一起 shipping 的多巴胺循环令人陶醉，可能导致更高的倦怠风险。

关键洞察

关联

• harness-engineering/overview — Harness Engineering 概览
• product-trends/agent-native-architecture — Agent-native 架构
• claude-code/overview — Claude Code

Sources

• dhh points on the agentic engineering and dev