一篇讲软件工程的论文，标题里为什么敢直接放 indispensable？
arXiv 2610.10226，作者 Alfonso Fuggetta。10 月 7 号挂的 v1，11 号更新了 v2。六页。已经被 Communications of the ACM 收了。
标题翻译过来大概是《为什么在编码代理时代，软件工程仍然不可或缺》。
先说结论：这篇值得看，但不是因为它的结论。
搞软件工程的人写论文，说软件工程不会过时，结尾你大概猜得到。太安全了。
值得看的是中间那段。作者列了 LLM 的三个结构性属性，然后把三条摞在一起。
第一条，概率性生成。它吐出来的东西是采样出来的，不是算出来的。
第二条，不可知论。它不知道自己不知道什么。你问它，它不会举手说这块我没学过。
第三条，语义无状态性。这个说法有点绕。我理解是它没有一份持久的、关于你这个项目的意义账本。上下文窗口一关，什么都不剩。
单拎一条出来，哪条都不新鲜，行内人都清楚。摞在一起就不一样了。简单说，这是结构性的空洞，不是能力不够，喂再多数据也填不上。
这句是全篇最硬的。
因为整个行业默认的假设是反过来的。模型不够好，是数据不够、参数不够、上下文不够，再等一代就好。这篇说的是你等不到。缝不在能力那一侧。
那缝在哪一侧。作者给了四类知识：方法论、领域知识、设计选择、流程选择。这些得有人固化下来，变成能传、能查、能回滚的工件。写工件的人，他分了三个角色：方法学家、中介者、保管者。
老实说这三顶帽子我只看懂两顶半。先放在这里，等我再读一遍 v2 补上。方向我是认的。
认它，是因为我自己用工具的时候，反复撞到同一面墙。
举个上周的例子。让 agent 把一个数据处理脚本改成能读多种输入格式。十分钟给了一版，看着挺像回事，异常处理有，日志也打了。跑，跑通了。
第二天换了个字段脏一点的输入。它没报错，安安静静输出了一个错的结果。
这才是最要命的地方。它要是崩了，我三秒就知道。它安安静静给我一个看着对的错答案，我可能一周后对账才发现。
论文里那句“表面上合理、却无法验证”，说的就是这个。读到的时候我停了一下。这不是假想。
所以这篇论文真正的价值，可能不在它自己以为的地方。
它以为自己在替软件工程辩护。这个辩护有点自证。但它顺手讲清了一件事：AI 编程的门槛在降，验证的门槛没降。生成变快了，验证就成了瓶颈。
这里我得推翻一句前面的话。我说它结论太安全，不太公平。
作者的结论不是“软件工程不会消失”这么一句废话。他往前推了一步：没有软件工程这层底，AI 辅助开发出来的东西，最终是不可信的。
这一步有攻击性。等于说，那些“不用懂代码也能做产品”的话术，短期能跑通 demo，长期会攒下一堆没人能验证的东西。
代价不当场付，延后付。延后付的账最难被看见。
顺带一句。我翻了 v2 的第 1 节，作者补了今年 7 月以来的新证据。这篇不是写完就发的，中间跟着情况改了一版。
一个说“别急着下判断”的论文，自己先改了一版。这个动作比什么论证都说明问题。
那四类知识和三个角色，我不在这儿展开。不是讲不清，是讲了对你现在没用。你现在需要的是在自己那个项目里，先把验证这一步补上。方法论那层可以晚点再来。
对普通人是好消息还是坏消息，看你怎么用。我的看法偏得比较明：好消息。
以前卡人的是写不出来。现在卡人的是看得出来。前者要几年训练，后者可以在一个具体项目里逼出来。每次多问一句“我怎么知道它是对的”，问上二十遍，习惯就有了。
硬要抄一句作业，就这句：每次 agent 给你一版能跑的东西，逼自己用一句话说清它为什么是对的。说不清就别上线。
背后就是那篇论文想说的全部。
本周就这些。
这篇你要是读了原文觉得我讲歪了，欢迎告诉我。尤其是那三顶帽子，我确实没吃透。
下周见。