一开始也有点担心 AI 会让程序员变笨，代码能力下降，但用了一段时间后，尤其是最近几个月，发现完全不是那么回事。感觉自己的代码能力，反而是不降反增了。
其实挺反直觉的。按理有人帮你写代码，动脑子的地方就少了，能力自然就退化了。但实际是想让 AI 写出 能用 的代码得先把需求描述得清清楚楚。你得精确地告诉它上下文是什么，输入输出是什么，不能有任何歧义，尤其是 3.5 的时代。就逼着你把问题想得更透彻，这种表达能力得到了很好锻炼。以前我容易有个思路就闷头就写，不知不觉现在习惯是先细化列点再写。
而且 AI 生成的代码，你敢直接用吗？反正我不敢。你总得去读去理解它的思路去检查有没有坑。有时候 AI 会用一些你没用过的库，或者一些比较刁钻的写法。这个过程中你就被迫去阅读大量的、不同风格的代码，尤其是写一些系统级的程序。有时候还不得不去看上游代码，修 AI 造的 bug ，看多了感觉阅读代码能力飞升。
另外 AI 的上下文能力是真的捉急。稍微复杂一点的项目是没法把代码全放进去的，更遑论有很多小众外部依赖的情况。比如我最近在搞的 mo 编译器 (moinfra/mo)，这东西的编译流程复杂，而且没有用 LLVM ，想让 AI 帮我写个复杂点的 Pass 几乎不可能，因为它完全不知道上下文，只会当成基于 LLVM 写。没办法，只能自己硬着头皮去梳理，把接口、依赖关系梳理清楚，整一个专门的知识库给 AI ，才能让 AI 写点局部的辅助函数。换句话说我需要反复梳理相关的上下文，提取给 AI ，代码阅量++。不过有了 gemnini2.5 感觉这个又变了。
就是 AI 写的代码里有多少 bug 真的无花八门，写点前后端还行，如果是比较冷门的（比如写 ZK ） AI 就会乱编，这种情况它自己基本修复不了这些 bug ，在一个错误的逻辑里反复打转。最后得靠人去 debug ，你去调试 AI 写的代码，往往比调试自己写的代码更费劲，因为它的逻辑可能跟你习惯的完全不一样。这个过程，对你理解代码、定位问题的能力，绝对是高强度的训练。
最有意思是，有些以前没完全搞懂的原理，现在反而因为调试 AI 写的烂代码而搞懂了。就说我那个 mo 编译器里的 LSRA 分配。原理大致知道，但实现细节，特别是 spill code 怎么插，还有多个 interval 的处理一直有点模糊。我让 AI 帮我写了个基础框架，结果 bug 一堆，逻辑硬伤也不少，但大方向的原理是对的。我就对着这个半成品，一点点调，一点点改。在这个过程中，反复琢磨寄存器的分配策略、活跃区间、冲突解决、溢出代码的插入时机和位置……最后，硬是把所有分配细节给彻底搞明白了。这个过程，调试 AI 写的 bug ，反而不断强化了我对底层原理的理解。
现在感觉，写代码的心态也变了。以前很多时间都浪费在查 API 、写各种样板代码、纠结一些语法细节上。这些琐碎的事情，现在大部分可以丢给 AI 。感觉编程这件事情变得更有趣了一点。我能把更多精力放在更宏观的层面，比如算法设计、整体架构的权衡。看代码的速度也快了很多，以前可能要一行一行地看，现在一大段代码扫一眼，基本就能瞟出来它的实现思路和核心逻辑。相比起来，面试还要一个白框手搓代码，筛选的到底是什么人？背诵仙人？
我另一个个人项目，一个大模型客户端 ，几乎全是 AI 开发的，UI 审美比我好多了，大家可以看看自己的组能不能一天内设计出这个水平。这种模式下我基本上不写代码，纯读然后修细节，更专注于功能和架构。对我来说，结论就是这样：AI 没让我变菜，反而让我变强了。
说了这么多其实关键就是，以前是读代码占 6 分，写占 4 分，现在感觉是读占 9 分，写占 1 分。而读代码的重要性一直以来被很多人低估了，读代码真的特别提升理解能力。以前一半时间写初版，一半时间修 bug ，现在基本上除了 C/V 就是修 bug ，也是相当锻炼人。以前一个团队干的活，现在一个人就能搞。遇到别人的大项目也敢去看代码提 PR 了。感觉程序员正在朝更牛逼的工种进化，可能以后反而不会失业？但是分化可能会越来越明显。