网硕互联帮助中心手写代码还没到清零的时候。代码仍然要懂，关键逻辑仍然要看。只是当实现速度突然提高，开发者的难题已经换了：怎么把问题讲清楚，怎么让多个Agent沿着同一套架构工作，又怎么在上线前发现那批“每个都合理、合起来却危险”的改动。
DHH：“I have not written… any of the code.”
DHH：上线到Quattro的代码，没有一行是我亲手写的。
说这句话的人，是Ruby on Rails之父David Heinemeier Hansson，开发者更熟悉他的名字DHH。
备注：David Heinemeier Hansson，开发者通常称他为DHH。他是Ruby on Rails创始人、37signals联合创始人兼CTO。Rails最初诞生于Basecamp的开发过程中，后来被GitHub、Shopify、Airbnb等大量互联网产品采用。
一年前，DHH还不喜欢AI补全代码，也不愿把聊天框嵌进编辑器。
但是在最近发布的Lex Fridman访谈中，他给出了完全不同的答案：Omarchy Quattro过去两个月的新增代码，已经全部交给Agent完成。
紧接着，他讲了一段经历。
一批设计师借助AI提交了大量PR。单独看，每个改动都有理由；合在一起，系统架构却被改坏了。
代码生成越来越便宜之后，开发者面对的麻烦并没有减少。它只是从“怎么写出来”，挪到了“谁来判断、谁来验收、谁为整体负责”。
以下内容根据Lex Fridman对DHH的访谈翻译、整理。
DHH谈Agent承担全部编码
13个月，他从排斥AI走到了“Or 100”
Lex提到，AI写代码的占比已经从5%、20%一路走到80%。DHH立刻补了一句：
DHH：“Or 100.”
DHH：或者，百分之百。
这不是一句随口夸张。
DHH回忆，13个月前的AI编程体验让他提不起兴趣。自动补全打断思路，聊天框需要人反复搬运上下文。模型能帮忙，却仍然像一个需要时刻盯着的助手。
Agent改变了这套交互。
现在，他会把问题和一个大致方向交出去。Agent自己读取仓库、寻找相关文件、提出方案、修改代码、运行测试，再把结果拿回来。DHH在访谈里描述这种变化时，重点不在模型会写多少语法，而在它开始接管完整任务。
过去，他需要先想清楚“准备怎么实现”，再让工具补几行代码。现在，Agent会反过来告诉他：这件事准备往哪里走。
DHH说Agent可以走到100%
两个月没亲手写代码，他还在逐行审什么
Omarchy Quattro是DHH近期投入最多的项目。他说，过去两个月上线的代码没有一行由他亲手敲出。
这句话这句话不是说“程序员不用写代码了”。
DHH没有退出开发。他看过所有改动的整体形状，涉及模型层和关键业务逻辑的部分，仍会逐行检查。普通代码可以交给Agent跑，架构方向、数据约束和关键边界没有一起交出去。
他的工作台也随之变化。Neovim不再主要用来手写代码，而是用来浏览项目、查看diff、核对Agent做了什么。
DHH的做法可以概括成一句话：实现权可以下放，判断权不能一起下放。
对普通团队来说，这条边界比“AI能写多少代码”更实用。数据库模型、权限、计费、并发和数据迁移一旦出错，测试通过也未必代表改动可以上线。Agent可以给出实现，人仍要知道哪些地方值得逐行看。
每个PR都说得通，系统却被改坏了
访谈里最值得警惕的案例，来自Basecamp 5。
设计团队开始使用Vibe Coding后，提交PR的速度明显加快。每一份PR拿出来，都能解释它为什么合理；问题出在这些改动之间没有共同的架构约束。
DHH：这些改动合在一起，把系统架构毁掉了。
DHH谈Vibe Coding破坏架构
AI编程很容易制造这种假象：局部完成得很快，整体债务却在背后累积。
一个Agent改登录，一个Agent改缓存，另一个Agent顺手抽象公共组件。三个任务都通过测试，不代表它们采用了同一套边界。重复逻辑、隐性依赖和风格分裂，往往要到后续迭代才会一起暴露。
DHH没有因此否定Vibe Coding。他给出的处理方式很工程化：让更多人获得实现能力，同时把架构审查提到更靠前的位置。
过去，架构问题常在Code Review里发现。Agent并发工作以后，等PR全部生成再看已经太晚。任务拆分时就要写清楚哪些模块不能碰、哪些抽象必须复用、数据如何流动，以及改动之间由谁统筹。
一个人同时跑16条Agent线程，开发者成了总调度
DHH：我最初用tmux管理并行Agent，后来嫌切窗口、等通知太麻烦，又做了Herdr。它把tmux会话和通知接在一起：某个Agent需要确认、完成任务或遇到错误时，再来叫人。
他的日常规模已经到了4到5台机器、约16条Agent线程同时运行。
DHH谈同时运行16条Agent线程
这套工作方式看上去很爽，新的瓶颈很快就冒了出来。
当16个Agent同时产出结果，人不可能逐个实时陪跑。开发者需要先判断哪些任务可以并行，哪些改动会碰到同一片代码，哪些结果必须等前一个任务完成后才能继续。
并发Agent最适合边界独立的任务：依赖升级、补测试、生成迁移脚本、清理重复代码、调查不同Bug。涉及同一份状态或同一套架构的工作，线程开得越多，冲突越难收拾。
管理Agent也不能只看“完成”通知。每条任务至少要带回四样东西：改动摘要、测试结果、风险点和回滚办法。少任何一项，人都得重新钻进仓库补上下文。
别再比谁写得多，代码行数已经失效
Agent一天可以生成成千上万行代码。继续拿代码量评价工程师，只会鼓励更多无效改动。
DHH：“lines of code is a stupid metric.”
DHH：代码行数是个愚蠢的指标。
DHH谈代码行数失去意义
DHH随后把评价标准拉回了产品：不要问写了多少行，先问做出了什么。
对开发团队来说，这意味着绩效和项目看板都要换口径。
一个Agent生成5000行代码，最后没有改善用户体验，也没有降低故障率，这5000行只会增加维护成本。另一个工程师删掉300行旧逻辑，让发布速度提高一倍，价值反而更高。
更合适的指标包括：问题是否解决、变更是否可维护、线上指标是否改善、事故率是否下降、交付周期是否缩短。代码是实现这些结果的材料，不是结果本身。
机械式编码受威胁，会做产品的人仍有机会
DHH没有回避就业问题。如果明天必须重新找工作，他认为自己很难再靠“手写代码”获得过去那种报酬。这项工作他做了25年，如今模型已经能承担其中越来越多的机械部分。
DHH：“the mechanical process is under threat.”
DHH：机械式编码这道工序正在受到威胁。
DHH谈机械式编码受到威胁
但他把“喜欢编程”拆成了两件事。
如果一个人最享受的是手工敲出语法、记住API和亲自完成每个实现细节，接下来的变化会很难适应。如果真正喜欢的是把东西做出来、解决问题、看着产品落地，Agent反而让这件事发生得更快。
DHH自己就是例子。他早年爱写代码，是因为代码能让程序出现。后来，大型项目、漫长周期和维护工作冲淡了这种即时反馈。AI让他重新获得了快速做出东西的感觉。
开发者的价值不会凭空消失，但会向任务上游和结果下游移动：前面要定义问题、选择方案、约束边界；后面要验收结果、处理失败、维护系统。
写在最后
DHH的转变很有代表性。
一年前，他不喜欢AI补全；现在，他可以让Agent承担全部新增编码，同时管理十几条并行线程。但他没有把软件交给模型自治，反而把更多精力放在架构、审查和结果上。
手写代码还没到清零的时候。代码仍然要懂，关键逻辑仍然要看。只是当实现速度突然提高，开发者的难题已经换了：怎么把问题讲清楚，怎么让多个Agent沿着同一套架构工作，又怎么在上线前发现那批“每个都合理、合起来却危险”的改动。
Agent可以把代码写完。系统最后长成什么样，仍然需要有人负责。
评论前必须登录！
注册