关于 AI 编程，不聊趋势，聊体感。
我写了十几年代码，在 nginx 团队工作。最近做了个实验：让 AI 从零写一个 HTTP 可编程压测工具。C + QuickJS，大概两千行，一天就能跑。
然后我花了几周，把它的架构重新做了一遍。
这个过程给我的体感，跟网上大多数 AI 编程的讨论不太一样。
AI 最危险的 bug，你看不见
重构中我发现了一个问题。
jsbench 有个模式：用户写 JS 脚本调 fetch() 发请求做压测。AI 写了这个功能，也写了测试。测试报告：16576 次请求，0 错误。通过。
但我 review 代码发现：每一次 fetch 都失败了。
Worker 线程里没有事件循环，fetch 根本跑不起来。但代码把每次调用无条件计入"成功"。16576 次请求，0 成功，报告说 0 错误。
原因很有意思：AI 写的代码和 AI 写的测试，有一致的盲区。 代码不检查错误，测试也不验证错误。它们完美地互相配合，制造了一个"一切正常"的假象。
这类 bug 才是最危险的：不是崩溃，不是报错，而是程序正常运行、测试全部通过、结果全是错的。
如果你用 AI 写代码又用 AI 写测试，心里要有个数：它们可能在同一个地方一起瞎了。
方向对了，AI 就是整个团队
但故事还有另一面。
我发现 fetch() 不支持并发——Promise.all 发三个请求，理论 300 毫秒，实际 900 毫秒。AI 用了"伪异步"：函数签名是异步的，实现是同步阻塞的。
我知道正确的做法：fetch 注册到全局事件循环，返回 pending Promise，事件循环统一驱动 I/O。这不是什么创新，是所有高性能异步框架的标准模式。
我把问题、方向、已有基础和约束告诉 AI。它一次改对了——9 个文件，905 毫秒 → 302 毫秒。
如果我只是说"fetch 有 bug"，AI 大概会在原来的架构上缝缝补补。但因为我能给出明确的架构方向，它一步到位做了正确的改动。
AI 的能力上限，取决于你给它的方向质量。
判断力是最大的杠杆
后来我做了更多重构，体感越来越清晰。
比如我决定把 epoll 和定时器组合成一个工作引擎对象。这个想法本身很简单，但落到代码上涉及 6 个文件、20 多处修改。AI 一次改完，没有遗漏。
反过来，如果这个判断是错的——比如不该组合而该分离——AI 也会一丝不苟地帮你把错误落到每一行代码上。
你的一个架构判断，AI 能落实到几十个文件的每一行代码上。判断对了，是几十倍的杠杆。判断错了，也是几十倍的杠杆。
什么能力变得更值钱了
现在到处在讨论 AI 会不会取代程序员。Vibe coding、AI agent、一句话生成应用——听起来程序员快没活干了。
根据我的实战经验，这个问题该换个问法：AI 改变的不是程序员有没有用，而是哪种程序员更有用。
架构判断。 AI 能帮你实现任何方向，但不会帮你选方向。代码怎么组织、模块怎么拆、抽象放在哪一层——这些在 AI 时代反而更重要了。方向对了，AI 的执行力放大你的判断；方向错了，AI 的执行力放大你的错误。
Code Review。 AI 写代码的速度远快于人，bug 产出的速度也远快于人。能看出代码哪里不对——不是语法错误，而是逻辑和架构层面的问题——这个能力现在是防线，不是锦上添花。
领域深度。 我能判断 fetch 该用事件循环而不是同步阻塞，不是因为 prompt 写得好，是因为写了十几年事件驱动程序。AI 放大的是你已有的能力，不是凭空创造能力。 你在某个领域越深，AI 给你的杠杆越大。反过来，如果什么都知道一点但什么都不深，AI 放大的就是浅薄。
至于"写代码"本身？它的权重确实在下降。不是不需要，是它不再是瓶颈了。
一句话
AI 时代，懂技术不是为了自己写代码，而是为了看出 AI 写的代码哪里不对。
看得出来，你就有了杠杆——一个判断，AI 帮你落到几十个文件。看不出来，你就是在用一个自己也不确定对不对的工具——它会非常自信地告诉你一切正常。
这篇文章的观点来自我重构 jsbench 的实战经历。完整的技术系列「一个 nginx 工程师接手了 AI 的压测工具」已在公众号连载 6 篇，持续更新中。
GitHub: github.com/hongzhidao/…
更多文章和后续更新，关注微信公众号：程序员洪志道
