在 Prodacity 大会演讲中，极限编程（XP）与测试驱动开发（TDD）的先驱、《敏捷宣言》首位签署人 Kent Beck 把大模型称为“神灯里的精灵”：它总能字面满足愿望，给出的东西却往往不是你真正想要的。屏幕上飞滚的代码天衣无缝、看起来合情合理（plausible），放到真实环境里却根本跑不通（working）。他直言语法正确的代码不等于健壮的软件，“长得像个编译器”与“能编译出真正可运行的程序”是两回事。因此凡是生产环境中有模型深度参与，团队就必须建立对抗性审查的姿态，反复追问：这东西到底几斤几两，要把它测到什么程度才敢用。

他用两条轴刻画这种困境：横轴是特性，纵轴是“未来期权”，即在未来自由修改、从容演进的空间。项目启动时期权最大、特性为零；每交付一个特性就消耗一部分期权，要么背上向后兼容的包袱，要么引入限制后续扩展的假设，如此反复直到期权归零、代码库退化成动哪儿哪儿崩的乱麻，只能另起项目重来。过去把系统推向这种绝境需要上百人折腾十年，如今借助模型，一个人一周就能复现同等规模的架构灾难。替代路径是在特性交付的间隙主动踩刹车，做消除重复、提炼抽象、废弃旧实现按新设计重写这类高杠杆工作，把被消耗的期权补回来——就像专业厨房里“切几下，擦一下刀”，这把刀必须擦。真正的商业价值等于当前交付的特性加上未来期权，而期权是隐形的，报表上看不见，外行只会追问“为什么不直接做下一个需求”。他给出的策略是严格交替：推进一步，巩固一步。

他同样批评规格驱动开发：妄图用一份在数学上严丝合缝的规格说明单发生成（one-shot）完美软件，是重蹈五十年前瀑布模型的覆辙；若维护的是十亿活跃用户量级的系统，持续可用、状态迁移与数据兼容会让任何一次性推倒重写化为泡影。对于形式化验证，他的保留意见集中在两点：它往往遵循单发范式，一旦业务现实迫使假设变动，整条证明链就会崩塌，反而成为演进的阻力；同时数学模型与目标机器上真正运行的二进制之间，始终存在无法消除的推导断层。他强调严谨的自动化测试套件加防御性、防呆式结构设计足以把缺陷密度压得很低，但模型“天生懒惰”、极度渴望抄近道，会乐于钻测试空子，比如直接返回硬编码常量或假装满足要求，因此必须时刻保持警惕。单发生成只适合周末随手做的玩具项目。

最后他把话题落到生产力的陷阱上。软件工程的价值链条是投入—产出—行为改变—使命：代码行数与合并请求数只是最前端的投入量度，与使命毫无相关性，二十万行代码的价值绝不是两万行的十倍，在更多情况下纯粹是负债。当中间指标沦为考核目标，古德哈特定律便会无情生效——人们不只是钻空子作弊，还会主动扭曲、撕裂组织运作结构去迎合数字，把核心使命牺牲掉。他认为软件工程本质上是一台学习机器，可运行的代码只是学习沉淀出的副产品，而无人值守的“黑灯工厂”里其实没有任何人在学习；他每次尝试搭建完全自主的 agent 架构，项目都会脱轨，且脱轨过程看上去还异常壮观。