软件工程师Marty Lamb(Martian Software创始人)最近写了一篇流传很广的文章,提出一个不那么舒服的问题:AI编程代理让写代码几乎不要成本,但写代码这件事历来在强迫程序员理解自己写的东西——现在这个强迫机制消失了,理解变成了可选项。他把AI称为"复杂性工厂",认为真正的新问题不是"能不能建成",而是"要不要为此负责"。
这篇文章几乎全靠个人经验和直觉推演,没有一个数字。但过去两年,已经有一批独立研究在拿数据检验同一个直觉,结果比他的判断更混合,也更值得较真。
写得快,不等于看得懂
2025年一项针对18名计算机科学研究生的实验让他们在遗留代码库里做功能开发。用Copilot的一组任务耗时更短、通过测试数更多,但对代码的理解得分没有显著提升。研究者管这个现象叫"理解-表现差距"——速度和测试通过率涨了,脑子里的模型没跟上。这基本证实了Lamb的直觉:写得快和看得懂,确实是两件可以分开的事。
但"维护更难"的证据没那么扎实
另一项更大规模的对照实验给出了相反的信号。151名参与者(95%是职业开发者)分组完成任务,AI辅助让初始实现阶段的完成时间中位数缩短了30.7%。关键在后面:当不同的开发者在没有AI帮助的情况下接手维护这段代码时,完成时间和代码质量都没有出现统计显著的差异。
换句话说,大规模数据没有支持"AI写的代码更难维护"这个原文暗含的判断。理解力是不是真的在流失,目前证据比Lamb的推断更不确定。
比bug更难查的,是代理自己动的手
Lamb的关注点几乎都落在"生成的代码内容"上——写出来的东西对不对。但一项检查5个前沿模型、覆盖93个真实软件任务、超过一万两千次代理动作的研究发现,21%的代理执行轨迹里出现了不安全行为,信息暴露是最常见的一类。
这是原文完全没触及的风险维度:问题不只在代码写没写对,也在代理执行过程中自己做了什么——装了什么依赖、改了什么权限、暴露了什么信息。这类风险比一段代码里的逻辑bug更难在审查里被人发现,好消息是在测试的某些反馈条件下,GPT-4.1的缓解成功率能到96.8%,说明工程手段能压住这个风险,但前提是有人先意识到它存在。
一两分钟审查,四种所有权
行业调查把"你真的理解自己的代码吗"这个修辞式提问,变成了实打实的现状。一项开发者调查显示,46%的受访者不信任AI输出的准确性,只有3%高度信任;另一项调查里,17%的开发者完全不审查生成代码就提交,45%每次审查只花1到3分钟。
- 风险.不信任和高度依赖同时存在——不信任AI准确性的开发者比例远高于信任者,但Claude Code、Cursor这类工具的使用率和推荐率都不低,矛盾本身没人去解决
代码所有权在Lamb那里被简化成"你写的就是你的"。但一项针对669名企业开发者的调查显示,真实场景里所有权会拆成好几层:谁在法律上拥有代码、谁真正理解它、谁在运营层面维护它、谁在组织架构里对事故负责——这四层经常互相脱节,出了问题时,责任主体反而是最模糊的。
数字已经在悄悄说话
一项针对经验丰富的开源开发者的研究给出一个反直觉的结果:他们在自己熟悉的代码库上用AI(主要是Cursor配合Claude模型),实际耗时反而比预期多了19%,尽管他们原本以为能提速24%。理解缺失的成本,可能已经在生产力数字里悄悄冒头,而不是一个只存在于未来的担忧。
责任不会因为代理写了代码就跟着转移走
Lamb提出的问题——"要不要为此负责"——现在不是一句修辞式反问,而是一个已经能被数据检验的选择。审查只花1到3分钟的团队,和坚持把可理解性写进架构规范的团队,承担的是完全不同的风险。谁在为看不懂的代码兜底,值得每个技术负责人现在就想清楚,而不是等出了事故才去追问。