当你编程交给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 时，我们省掉的究竟是什么。
重复操作当然可以少做。可那些帮助人理解问题、修正判断的过程，如果在还没掌握之前就被跳过，产出可能跑得更快，能力却未必跟得上。
页:
[1]