达里奥·阿莫代伊给出的判断是，AI 将在未来三到六个月内编写 90% 的代码，一年内几乎包揽全部编程工作。这个预测真正锋利的地方不在于时间表是否精确，而在于它把问题从「程序员会不会被替代」推到了另一层：当写代码的边际成本趋近于零，工程师身上还剩下什么稀缺性。
如果只把它当成就业焦虑，会漏掉更现实的推演。软件交付中最贵的环节从来不是敲键盘，而是把模糊需求收敛成明确约束、把接口约定清楚、把线上故障定位出来、把系统长期维护下去。当「写」这一环被大幅压缩，压力会顺着链路向两端转移：上游是如何把意图翻译成 AI 能执行、也能被验证的规格，下游是如何确认生成的结果真的成立。
验证能力因此被推到台前。AI 生成代码的速度远高于人阅读和理解它的速度，产量上升会直接转化为审查负担。这里需要的不是通读，而是构造测试、设计边界条件、判断失败模式的能力——知道该验证什么，比知道代码长什么样更重要。能快速识别「这段逻辑在什么条件下会崩」的人，价值高于能快速写出同样逻辑的人。
与验证并列的是问题定义能力。AI 擅长在给定约束下求解，不擅长替人决定约束本身。把一段含糊的业务诉求拆成边界清晰的输入、输出和异常路径，仍然是需要人来完成的工作，也是最不容易被商品化的一层。
再往上，是系统级判断。模块边界怎么划、依赖朝哪个方向引、当前选择会在半年后带来多少演进成本，这类判断依赖的是对具体系统的长期上下文，而不是通用语料里的模式。AI 可以在局部给出看起来合理的方案，但对整体演进代价的感知，仍然需要有人兜住。
有两种常见的错位值得警惕。一种是把能力重构等同于学习提示词技巧，而这层技能恰恰最容易被工具自身的迭代吞掉；另一种是转身去做纯协调工作，放弃读代码和技术判断。审查 AI 产出的前提，是自己仍具备判断产出的能力，而这种能力只能靠在系统里持续阅读和修改来维持。
更实际的评估方式或许是：把自己日常工作中真正耗时、真正需要判断的环节列出来，看其中有多少是「写」，有多少是「决定写什么」和「确认写对了」。这个比例的变化，比任何时间表预测都更能说明该往哪里投入。