当你编程交给AI时 你已经丧失了成长的过程

寂静回声

最近看了 CSDN 分享的一个案例，写了 20 多年代码的 Brett，在使用 AI 编程 18 个月后，决定彻底停用 AI。
这 18 个月里，他完成的任务更多了，交付代码也更快，一度觉得这就是未来。
可回头再看，他却说自己的开发者成长几乎停滞了。哪怕因此被解雇，找不到工作，他也不想再继续使用。
一个效率明显提高的人，为什么会觉得自己的成长停了。答案就藏在他这 18 个月的使用经历里。任务完成得更快，并不足以说明能力也在同步提高。

Brett 认真使用 AI 后，很快尝到了好处。AI Agent 可以修改文件、实现功能，他用这些工具做音乐播放器和其他小项目，完成的事情明显变多了。
如果只看任务有没有完成，这当然是生产力提高了。
可在 Brett 自己的描述里，他过去学习编程，靠的就是亲自解决问题，经历困难、调试和失败，再慢慢找到可行的实现。
写出代码只是结果，前面的判断和试错也在不断改变他对问题的理解。
这些步骤里既有重复劳动，也有能力形成的过程。AI 直接给出实现时，两类过程很容易被一起压缩。
至少在 Brett 的使用方式里，结果常常赶在理解之前出现。他可以更快交付，却没有像过去 20 年那样继续学习。这也解释了为什么任务越来越多，他对自己的成长感受却越来越弱。

随着越来越多的实现交给 AI，Brett 的工作内容也变了。
他开始写 Markdown 文件约束 AI，审查大量生成代码，再像 QA 一样检查结果。代码一多，审查就成了在干草堆里找针。他逐渐不知道某段实现在哪里，也很难掌握代码库是怎样一点点变化的。
真正影响 Brett 的，是他没有参与那些实现决定怎样形成，却要在结果出来以后判断它们是否可靠。
在他的经历里，这种距离带来的后果很具体。理解越来越少，对代码的在意也跟着变少。他觉得自己对 AI 生成内容的关心程度，远低于过去 19 年里亲手写下的代码。
对 Brett 来说，一旦说不清某段代码为什么存在、经历过哪些修改，后续的审查和维护就很难建立在完整理解上。他所谓的离代码越来越远，说的正是这种掌控感在消失。

把 Brett 的经历拆开看，完成一个需求，多交付一段代码，就能提升能力。
遇到陌生问题的理解力，在哪次失败里改掉了错误的判断，下次能不能少走一点弯路，这些变化很难立刻被统计。
已经理解的重复工作交给 AI，主要省下的是执行时间。面对自己还没有理解的问题，如果关键实现也直接交出去，被跳过的就可能包括形成判断的机会。
Brett 后来回到手写代码，做游戏，还尝试写一个小型游戏引擎。
速度慢了，解决问题也更费劲，可学习和创造的满足感又回来了。于是，他给自己的答案是彻底停用 AI。
其他人未必要照搬这个选择，更需要想清楚的是，把一项工作交给 AI 时，我们省掉的究竟是什么。
重复操作当然可以少做。可那些帮助人理解问题、修正判断的过程，如果在还没掌握之前就被跳过，产出可能跑得更快，能力却未必跟得上。