8月8日，程序员Senko Rašić发了一篇博文，标题直接叫板一句最近很流行的说法——“代码从来不是难点，搞清楚要做什么才难”。他用一连串反问怼回去：如果编码真的简单，为什么程序员薪资常年居高不下、为什么公司要用leetcode筛人、为什么《Clean Code》能写成一本厚书、为什么Carmack会被奉为天才？他的结论是：编码难，需求理解也难，两者本就分不开，非要二选一是在自欺欺人。
这篇博文骂得痛快，但如果只停在“他说得对不对”这一层，读者其实拿不到新东西。因为这场争论根本不是今天才有的，而支撑它的实证数据，也比一篇博客的反问句复杂得多。
四十年前，Brooks已经吵过一轮
早在1986年，Fred Brooks在《没有银弹》里就把软件的难度拆成两半：本质复杂性（搞清楚要造什么、怎么验证）和偶然复杂性（语言、工具、机器的限制）。他的判断是前者才是真正的硬骨头，后者迟早会被工具进步磨平。往前推，1968年NATO的软件工程会议提出“软件危机”，根源也被归为大型系统的组织协调失败，而不是程序员打字打得不够快。
换句话说，“代码不是难点”这句话在学术圈里流传了近四十年。AI只是把这场旧辩论重新推到了台前，赋予它一个新的紧迫问题：代码生成成本骤降之后，到底谁的技能会贬值，谁的价值会被重新定价。
提速55.8%，还是变慢19%
真正有意思的地方，是两份数据打了起来。
早期一项针对GitHub Copilot的实验里，95名开发者完成一个绿地HTTP服务器小任务，用了Copilot的一组比对照组快55.8%。这个数字后来被反复引用，成了“AI让编码变简单”的证据。
但METR在2025年做的一项随机对照研究给出了相反结果。16名经验丰富的开源开发者，在自己熟悉的成熟代码库里完成246项真实维护任务，用AI辅助反而平均慢了19%（置信区间约2%到39%）。更值得警惕的是感知偏差：这些开发者事前预期AI能帮自己快24%，任务做完之后，他们依然主观认为AI帮上了忙——尽管实测数据说的是相反的事。
- 风险.开发者对AI效率的主观感受和实测结果系统性背离，靠“感觉好用”来决定要不要大举投入AI工具，本身就是一个决策风险。
绿地任务和维护任务，是两个完全不同的战场。前者不需要理解历史包袱，AI写完能跑就算赢；后者要摸清楚十年积累的隐藏假设、边界条件和别人埋下的坑，AI给出的“看起来对”的代码，反而可能制造新的调试成本。2025年Stack Overflow的开发者调查也印证了这一点：很多人反映AI生成的代码“差不多对但不完全对”，调试起来有时比自己重写还费时间。
难点没消失，只是换了地方
Senko在博文里顺手嘲讽了一把产品经理和业务分析师——如果搞清楚需求才是硬骨头，为什么这两类人的薪水和地位常年不如程序员？这个反问听着解气，但没解释清楚一件事：AI真正压低的成本，是“把想法变成能跑的代码”这一步，而不是“判断这段代码该不该存在”。
瓶颈往后挪了。真正开始变得稀缺的，是定义问题、评估方案、设计测试用例、诊断线上故障这一组更细的能力，而不是笼统的“理解客户需求”。这也是原文和它援引的那些反问句都没有触及的地方——它们停留在“谁更难”的抽象站队，没有落到“AI具体改写了哪个环节的成本”这个更可验证的问题上。
AI没有让难点消失，只是把它从写代码搬到了判断代码。
对一线程序员来说，现实的判断是：如果你的工作大部分是绿地开发，AI工具短期内能省时间；如果你的工作是维护一个跑了多年的系统，指望AI直接提速可能落空，METR的负19%比任何一句“AI很强”都更值得放在心上。对技术管理者来说，先别急着按“接入AI=提效”的假设重新分配团队，先看清楚团队里绿地任务和维护任务各占多少。