antirez在X上说,很多程序员这些年反而因为盯着代码,失去了本该有的影响力。这话立刻炸出了一票反对声,同为知名开发者的Matteo Collina当场追问:你不是说你会审查所有Redis的AI生成代码吗?
这个追问问到了点子上。antirez确实审,而且是逐行审。可他刚刚在博客里说,程序员不该再逐行读代码了,该做的是"控制想法"。一个人一边这么主张,一边自己不这么做——这中间的缝隙,比新闻本身更值得掰开看。
三条论据,读起来像一份清单
antirez给出的理由不复杂:
- AI一天能吐出去大量代码,靠人力逐行审查根本跟不上产出速度。
- 大模型擅长写"局部最优"的代码,却不擅长把握系统级设计,逐函数扫读性价比很低。
- 一天工时有限,花在读代码上,就意味着少花在"这软件该往哪走"上。
结论顺理成章:与其审代码,不如审设计。这套逻辑本身站得住——《人月神话》里"概念完整性"那套老话,说的正是好软件靠统一连贯的设计理念撑着,而不是靠堆代码量。这本1975年的书,拿来解释2020年代的AI编程,居然毫不违和。
DwarfStar:自动化的样板,还是没完工的样板?
antirez拿自己的开源项目DwarfStar当例子:一个专为推理DeepSeek v4定制的原生C推理引擎,不是通用GGUF运行器,支持Metal和CUDA后端,他说通过"完全自动化"的方式实现了对DeepSeek v4和GLM 5.2的推理支持,过程中还发现别的实现里藏着更多隐藏错误——比如超过一定上下文长度后,某些attention实现会出现明显的性能滑坡。
这套叙事听着漂亮,但对照DwarfStar自己的项目文档和GitHub issue,口径不太一样:GLM 5.2支持目前被明确标注为"可能的下一个目标",相关讨论还停留在一个尚未合并的issue上,并非已完成的既成事实。
这些数字说明一件事:DwarfStar本身就是个窄而深的专用工程,绑死了特定模型的张量布局和量化方案。它能跑起来,靠的不是"少人参与",而是antirez本人对attention实现、上下文窗口边界这类细节的深度判断。他自己都承认"你不能只说实现XYZ,然后指望它自动生效"——这句话恰恰在反驳他自己那条推文。
说一套,做一套
真正的张力在这里:antirez公开主张程序员该少看代码、多想设计,但他自己对Redis的每一份AI生成代码都逐行看,理由是"出于对用户的尊重"。他还亲自动手改了Redis Arrays的实现,眼下正在准备提交一份让排序集合内存占用减半的优化PR,同样是自己写的。
一个理论如果连提出者都没完全照做,它更像是安慰剂,而不是方法论。
- 风险.如果"控制想法不控制代码"被简化成招聘和培养标准的调整依据,却没人追问antirez自己都做不到彻底放手,这套主张很容易被年轻团队照单全收,变成省审查成本的借口。
新人怎么办
antirez自己也留了一个口子:他说不确定年轻程序员是不是还需要精读代码,建议他们去实现一个小解释器、一个小数据库、一张哈希表,而不是花时间审查客户网站上的JavaScript。这话听着务实,但也暴露了这套理论的适用边界——它建立在antirez几十年攒下的架构判断力上,新人恰恰缺的就是这个。天下熙熙皆为利来,把一套只有老手才玩得转的方法论,包装成人人可用的新常态,受益的往往是省成本的团队,担风险的往往是刚入行的人。
对Redis用户和贡献者来说,真正该盯的不是antirez说了什么,而是他即将提交的那份排序集合内存优化PR,评审到底是走过场,还是照旧逐行来。对DwarfStar的社区开发者来说,GLM 5.2从"下一个可能目标"变成正式支持的那天,才是检验"全自动"这个词分量的时候。