在近期举行的 Rails World 大会上，Ruby on Rails 框架创始人大卫·海涅迈尔·汉森（David Heinemeier Hansson，简称 DHH）抛出一个颇具争议的观点：在他所在的 37signals 公司，手写代码的时代已经结束。这番表态迅速在开发者社区引发讨论——当一家以代码质量著称、拥有 27 年历史且持续盈利的软件公司主动放弃传统编码方式时，AI 辅助编程究竟只是效率工具，还是正在重塑软件工程的基本流程？
从“写代码”到“指挥代码”
DHH 在主题演讲中将 AI 编程工具的成熟比作相机对绘画艺术的冲击：技术没有消灭创作，而是改变了创作的形态。他透露，37signals 如今几乎不再依赖手工编写代码，而是通过 AI 工具完成大部分实现工作。更引人注目的是，他坦言自己已不再视自己为一名“专业程序员”。
这一说法之所以激起强烈反响，是因为 DHH 的身份特殊。作为 Ruby on Rails 的创造者，他长期被视为软件工艺（software craftsmanship）的代表人物。而 37signals 本身也是靠精细工程文化赢得行业尊重的企业。正因如此，他的转向被许多一线工程师解读为一种信号：即便最重视代码质量的团队，也开始接受由 AI 生成主体代码的新范式。
AI代码普及，质量问题浮出水面
不过，围绕 AI 编程的乐观叙事并非没有反例。一位匿名大型科技公司工程师近期发帖指出，随着 AI 使用率上升，越来越多工程师开始“把思考外包给大模型”，只关注能否上线，而不再深究逻辑是否严谨、边界是否覆盖。这种心态正在悄悄侵蚀软件质量。
实际案例已经出现。Uber Eats 近期上线了一项新功能——允许用户在点餐时选择附加选项。但有用户发现，该功能在发布时至少存在三个明显界面与交互错误，且未经验证即推送给所有用户。尽管 Uber 团队随后回应并着手修复，但此次事件暴露出一个隐忧：当开发流程高度依赖 AI 生成代码，而人工审查和测试环节被弱化时，产品缺陷更容易被忽视。
- AI 可快速生成大量代码，但未必理解业务上下文
- 工程师若仅做“提需求”角色，容易失去对系统细节的掌控
- 缺乏严格 QA 流程的产品，上线风险显著上升
责任重构：代码可以自动生成，但问题仍需有人负责
AI 编程带来的另一重挑战是责任归属模糊。过去，工程师对自己编写的每一行代码负责；如今，他们可能需要审查和承担大量并非亲手所写、却已部署到生产环境的代码。这种转变正在重新定义“编码”的含义——从逐行实现，转向需求拆解、结果验证与系统集成。
一些公司尝试将 AI 能力扩展至工程之外的领域。例如，OpenAI 内部的财务、招聘和法务等部门自 2026 年 6 月起开始使用 Codex 处理任务；初创公司 Craft Docs 则基于自研的 Craft Agents，让非技术人员也能参与自动化流程构建。这表明，AI 正在成为跨职能协作的基础设施，而不仅仅是程序员的辅助工具。
然而，工具的普及并不自动意味着效率或质量的提升。真正决定成败的，仍是组织如何设计新的工作流：谁提出需求？谁验证输出？谁为线上故障负责？这些问题尚无标准答案，但已成为每个采用 AI 编程的团队必须面对的现实。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dhh-xuan-chen-shou-xie-dai-ma-shi-dai-luo-mu-ai-bian-cheng
