深度解读软件与工程generatedpublished

十天提了295个PR发了30个版本,为什么这位35年老程序员说自己一行代码都没读?

机制

一个人,十天,给 49 个开源代码仓库提了 295 个 PR,发了 30 个正式版本。 算下来,在后台烧掉了差不多 12 亿个 AI token。 最吓人的是他的原话:这十天里,自己一行代码都没写,甚至一行都没读。 这可不是哪个刚学会用大模型的新手在 GitHub 上刷垃圾提交。 干这件事的人叫 Daniel Doubrovkine,开源圈里大家都叫他 dblock。 前 Artsy 首席技术官,写了 35 年代码的资深工程师。 他发出的 295 个 PR 里面,有 257 个被各个仓库的维护团队直接合进了主分支。 其中一个叫 Hashie 的基础组件库,全网有 17 万个开源项目都在用。 里面积压了许多年的疑难杂症,他带上 AI,只花了一天时间,把整个历史待办全部清空。 很多人第一反应是:这怎么可能? 不读代码、不写代码,靠大模型自动敲出来的东西,能直接发版本? 他刚写了一篇长文复盘,把整个后台账本和调用明细全贴了出来。 仔细看完他的过程,你会发现一个很有意思的现实: 开源维护最折磨人的地方,根本不在写核心算法。 大把的时间,全被那些又脏又累的泥潭吞掉了。 比如他在 Mongoid 组织里翻出来的一个陈年问题,从 2013 年挂到现在,整整晾了 13 年。 当年有人提交报告,说在分片集群环境下一个加锁功能会偶尔失效。 为什么 13 年来没人去动它? 因为要复现这个故障,成本高到让人头皮发麻。 你得先在本地装上十多年前的 Ruby 2.0,配上当年的 MongoDB 2.4.6。 接着用容器搭出配置服务器集群、分片集群和路由节点,把一整套古董分布式系统全拉起来。 然后还要写各种极端边界情况的自动化测试,看加锁究竟在哪个环节丢了。 普通开源维护者平时都有全职工作,还有家庭。 谁愿意在周六下午花四个小时,去给一个陌生人十几年前碰到的诡异报错搭这样一套复杂测试环境? 这种问题一旦挂出来,基本就成了永久死档。 结果这次呢? 他把历史工单扔给 AI 智能体。 不到四分钟,智能体把测试环境全部搭好,拉起 Docker 容器集群,跑完了完整的端到端测试。 甚至还用当年的老版本依赖重新比对了一遍。 最后给出的测试结果证明:当年报出来的故障,根本就跟分片没有任何关系。 原本需要消耗资深工程师一整个周末的考古脏活,瞬间变成了四分钟的确定性验证。 那 12 亿个 token 又是怎么回事? 一看账单明细,里面的玄机就露出来了。 12 亿个输入输出 token 里,有 97.4% 都是上下文缓存读取。 真正花算力新生成的,其实只有 3400 多万个 token。 也就是说,AI 在后台的大部分工作,是在不知疲倦地反复翻看整个代码库、对比老测试、验证历史提交。 Daniel 自己甚至不是全职在做这件事。 每天正常上班,中午吃便当时看两眼进度,晚上回了家再集中处理一阵。 既然敲键盘和搭环境的体力活全被机器接管了,那人还剩下什么? 是不是只要有个模型,谁都能管 49 个仓库? Daniel 给出的答案很有分量。 他说,敲键盘确实变得极度廉价,但做决定的成本变得空前昂贵。 他那 35 年的工程经验,非但没有贬值,反而成了驱动这台机器唯一的方向盘。 AI 跑得极快,但它既不懂得克制,也没有工程品味。 在这十天里,Daniel 真正干的事情只有几件: 辨别 AI 写出来的测试到底是不是真测试,还是在为了通过而伪造场景; 砍掉那些没有必要的抽象层,阻止模型为了修一个两行的小毛病而把整个架构复杂化; 守住语义化版本的红线,坚决把破坏向后兼容的改动扣下来,放到下一个大版本; 审查对外的说明文档与更新日志,确保用户看到的行为承诺完全准确。 那些本该被拒绝的无理功能请求,哪怕 AI 写得再快,也必须由人来坚决说不。 过去软件开发里最耗费生命的,是无休止的环境配置、依赖打架、补测试覆盖率。 当这些繁杂的摩擦力被廉价算力彻底荡平之后,工程师的角色终于变了。 你不再是一个天天忙着清空工单的打字机。 你成了一个手握重型机械、带着严格审美和边界意识的现场指挥官。

语义相关 / RELATED

同领域解读 / SOFTWARE & ENGINEERING

查看全部「软件与工程」解读 →

规范引用 / CANONICAL CITATION

十天提了295个PR发了30个版本,为什么这位35年老程序员说自己一行代码都没读? — 墓碑科技 MUBEITECH(https://mubeitech.com/deep/mb-20261023-e3415b)

导出 / EXPORT

订阅 · SUBSCRIBE

每周一封独立、不受审查的科技与 AI 深度评论,周一发出。带出处,可核查。

不追踪邮件打开与邮件链接点击,一键退订。 或用 RSS · 详情