AI 编程真正危险的地方，不是写不出来，而是八个月后没人敢接着改
一条关于阿里测试 18 个 AI agents 的帖子，把 AI Coding 的真正短板说透了：让模型把代码“先写出来”已经不难，难的是在长周期维护里不持续引入回归和技术债。真正的问题不是首轮生成，而是后续谁来接住。
来源参考： X
AI Coding 这波热潮，最容易把人带偏的地方，是大家都在看“它这次写出来没有”，却很少盯着“八个月后这坨东西还有没有人敢动”。能生成，不等于能维护。
Priyanka Vergadia 这条 X 帖子之所以传播得快，不只是因为语气狠，而是它一下子把很多团队心里那个隐约的不安说穿了：AI 也许不是来抢程序员工作的，它更像是在批量制造未来要靠人类收拾的遗留代码。
“Passing a coding test once is easy. Maintaining that code for 8 months without it exploding? Apparently, it’s nearly impossible for AI.”
帖子的核心信息并不复杂。阿里据称测试了 18 个 AI agents，在 100 个真实代码库、233 天维护周期 里观察它们的长期表现。不是看一次性 patch 能不能过，而是看代码在持续演化后会不会开始崩、会不会把原本能跑的东西越修越坏。
配图里最刺眼的一句其实不是哪家模型赢了，而是这句：75% 的模型会在维护过程中破坏原本正常工作的代码。 这意味着很多模型擅长的是“把答案先写出来”，但不擅长“让系统继续活下去”。
如果这个结论成立，那它打掉的就不只是几个 benchmark 神话，而是整个 AI Coding 叙事里最偷懒的一层：过去太多人拿 HumanEval 这类快照测试来证明模型“已经会写代码了”，但现实工程从来不是一次性答题。真正的工程环境更像帖子里提到的这个方向：功能上线之后，需求继续变，依赖继续动，边界条件继续冒出来，系统要在一次次修改中活下来。
换句话说，很多 agent 今天交付的不是软件，而是短期可运行、长期难维护的脆弱产物。当这些代码还在 demo 阶段时，问题不明显；一旦进入真实团队、真实仓库、真实协作链条，技术债就不会消失，只会转移。省下来的那点生成时间，最后往往要靠更高的 review 成本、排障成本和重构成本补回去。
这也是为什么我越来越觉得，AI Coding 的真正分水岭不在“谁 first draft 更快”，而在“谁能在长周期里控制回归、控制债务、控制复杂度”。帖子里提到的 SWE-CI 这类思路更接近真实问题：不是问“现在对不对”，而是问“过了很多轮修改之后，它还稳不稳”。
如果以后行业真的开始从快照 benchmark 转向维护 benchmark，那很多今天看起来很能打的模型和 agent 产品，估计都得重新排座次。因为写一个能过测试的 patch，不算太难；写一段八个月后团队还敢继续改的代码，才算真本事。
所以这条帖子最值钱的地方，不是情绪，而是它把评价标准往前推了一步。AI 写代码这件事，真正贵的部分从来不是生成那一下，而是后面那一长串维护责任。模型可以帮你把第一棒跑得更快，但接力赛最后摔不摔，还是看代码本身能不能活到终点。
文中提到的原帖在这里：X 原帖。如果只看速度，AI Coding 确实已经很强；但如果把时间轴拉长，维护能力才是下一阶段真正见高下的地方。