最近我一直在想一个问题：AI 写代码越来越强以后，程序员还需要像今天这样看代码吗？
我的答案是：可能不需要了。至少，不一定需要像今天这样逐行看代码。
我其实挺相信一个方向：以后可能不再需要传统意义上的编译器了，AI 可以直接把人的想法变成可执行程序。这个想法听起来很激进，但放在编程的发展历史里看，它并没有那么离谱。
编程这件事，过去几十年一直在往更高层抽象走。最早写程序，要跟机器码、汇编打交道。后来有了 C、Pascal，再后来有了 Java、Python、JavaScript，各种框架、云服务、低代码平台也一层层叠上来。
每一次抽象层级往上走，都会有人担心：这是不是太黑盒了？程序员是不是越来越不懂底层了？工具链是不是越来越不可控了？但结果往往是，工具变强了，人并没有被淘汰，只是工作重心变了。
我们不再手写汇编，不代表我们不懂计算机。我们不再手动管理每一个底层细节，不代表我们不懂工程。很多时候，正是因为底层被更好的工具托住了，程序员才有机会把精力放到更复杂、更有价值的问题上。 所以在我看来，AI 编程很可能就是这条抽象链的下一环。
以前是人写源码，编译器把源码变成机器能执行的东西。以后很可能是人描述目标、约束和上下文，AI 直接生成代码，甚至直接生成可执行程序。也就是说，代码可能不再是人和机器之间唯一的中间层。
这个变化如果真的发生，意义会非常大。因为它不是简单地让写代码更快，而是改变了我们表达意图的方式。
但这里有一个很重要的前提：抽象层级变高，不代表理解要求变低。恰恰相反，越是高层抽象，越需要人能判断方向对不对。
今天你写一段代码，错了可能只是一个函数有 bug。以后如果你把目标、边界、约束描述错了，AI 可能会沿着一个错误方向，把一整套系统都生成出来。那时候真正危险的，不是你少写了一行代码，而是你根本没意识到自己的系统设计有问题。
所以我支持 AI 继续把编程往上抽象，但我不认为这意味着程序员可以不用看、不用懂。只是我们看的东西会变。
以前我们看代码，更多是在看具体实现：这一行有没有写错，这个变量名合不合适，这个循环有没有边界问题。
以后我们可能会更少盯着每一行实现，而是更多去看：系统边界是不是清楚？模块职责是不是合理？接口是不是稳定？数据流是不是简单？权限模型有没有漏洞？失败场景有没有被考虑进去？
换句话说，程序员的注意力会从"代码怎么写"，转向"系统为什么这样设计"。
这不是能力要求降低了，而是能力要求上移了。
AI 确实可以帮我们生成代码，也可以帮我们解释代码。它能补样板逻辑，能生成测试草稿，能快速搭一个实现方向，也能帮我们理解陌生模块。
但它不能替我们判断一个系统是否值得这样设计。因为判断这件事，背后需要的是上下文、取舍、经验和责任。
你要知道这个功能为什么存在，谁会用它，它以后会怎么演化，哪些地方必须稳定，哪些地方可以试错，哪些复杂度是必要的，哪些复杂度只是提前透支未来。这些东西，不是"会不会写代码"那么简单。
所以如果有一天，AI 真的可以直接把人的想法变成可执行程序，我反而觉得程序员更应该看懂系统设计。因为当代码越来越容易生成，真正稀缺的就不是敲代码的速度，而是判断系统好坏的能力。
以前你可以说："这段代码太复杂，我看不懂。"以后 AI 可以帮你解释，帮你拆解，帮你把上下文铺开。真正的问题会变成：解释你能看懂，但你能不能判断它是不是合理？
这才是未来程序员之间真正拉开差距的地方。
所以我想说的是：
AI 不是让你不用看代码，而是让你更该看懂系统设计。
未来也许我们真的不再需要像今天这样写代码、看代码，甚至不再需要传统意义上的编译器。但只要我们还在构建复杂系统，就仍然需要有人理解系统、判断系统、为系统负责。
这个人，还是程序员。