最近软件圈有个很诱人的说法：AI 来写代码，人类退到上层，只负责写规格、编排任务、审核结果。

听起来像工程师终于“升维”了。Lars Faye 在《Agentic Coding is a Trap》里泼了冷水：人离代码越远，未必更高级，也可能只是更看不见系统怎么坏掉。

这篇文章真正反对的不是 Claude、Copilot 或其他 LLM 辅助编码。作者承认，LLM 对学习、探索、解释概念、生成草稿都有长期价值。他反对的是把全代理工作流默认化：让 AI 大规模写代码，人类在后面追着审。

Agentic Coding 被吹成什么，又漏掉了什么

Agentic Coding 大致是这样一套流程：人写需求和规格，AI 代理拆计划、改文件、跑实现，人再 review、纠偏、重试。

更激进的玩法，是同时开多个 agent。像开多条生产线。代码产出很快，问题也被放大得很快。

它常被包装成“规格驱动开发”的未来。程序员不再亲手写实现，而是写清楚意图，管理 AI 输出。

Faye 的反对点很直接：这不是单纯换工具，而是在改软件生产关系。过去工程师通过写代码建立系统心智模型；现在这一步可能被代理吞掉。

代价具体表现谁会先感到疼
系统复杂度上升为了压住 AI 的非确定性，测试、审查、回滚、提示词流程都要变厚技术负责人、维护团队
技能萎缩写、读、调代码的肌肉变弱新人工程师，也包括长期不碰实现的资深工程师
供应商锁定Claude Code 等服务一旦变价、限流或停摆，工作流会被卡住依赖单一模型平台的团队
token 成本不确定模型价格、调用量、重试次数都在变要做预算和采购的管理者

最刺眼的是 Anthropic 自己提到的“监督悖论”：有效使用 Claude 需要监督，而监督 Claude 又依赖那些可能被 AI 过度使用削弱的编码技能。

这句话很要命。

你得足够懂，才知道 AI 哪里错。可你越少亲手写，就越可能不够懂。

这不是 FORTRAN，也不只是更高抽象

支持者常拿历史类比说事：过去有人不信 FORTRAN，不信编译器，不信云计算；今天质疑 AI 代理，也许只是老派工程师害怕新工具。

这个类比只像一半。

FORTRAN、编译器、云计算，确实提高了抽象层。它们大体是在稳定规则上封装低层细节。LLM 代理不同，它把概率性和模糊性引进了生产链路。

更模糊，不等于更高级。

写代码也不只是敲字符。很多工程师是在写类型、拆函数、调整目录结构时，才真正想明白系统该长什么样。

代码不是计划之后的体力活。代码本身就是计划的一部分。

如果流程变成“写规格—等 AI 生成—人工审核”，少掉的不只是劳动，还有摩擦。工程能力往往就在摩擦里长出来。

新人最容易受影响。过去他们通过读错、写错、调错，慢慢建立判断力。现在如果直接接触的是 AI 生成的大段实现，他们学到的可能是如何接受答案，而不是如何形成答案。

资深工程师也不是天然安全。长期不碰细节，只看 PR 和摘要，心智模型会变薄。系统一旦出问题，没人能只靠“我大概知道业务意图”去修复杂 bug。

Simon Willison 也提过类似担忧：如果你对应用能做什么、怎么工作的模型不够牢，每加一个功能都会更难推理。

至于一些研究和材料提到的调试能力下降，比如 Anthropic 相关材料中出现过 47% 的说法，不能直接当成行业定论。证据还没到那个强度。

但它至少提醒一件事：工具替你绕过困难时，也替你绕过训练。

AI 要留在手边，不要坐上主位

我更在意的不是 AI 会不会写错代码。人也会写错。

真正危险的是团队把“出代码速度”当主指标，把 review 当万能保险，把 token 消耗当先进生产力的仪表盘。

这样会把优先级倒过来。过去好工程师先追求理解、简洁、可维护，再谈速度。全代理流程天然先给你速度和规模，再逼你补理解。

天下熙熙，皆为利来。模型厂商当然希望开发能力变成持续 token 消费。

过去一个工程师靠键盘、编辑器和脑子能完成的事，未来可能先要接上某家模型服务、某套 agent 工作流、某个订阅账单。

这不是阴谋论，是商业结构。供应商锁定未必让公司立刻出事，但会抬高平台议价权。基础开发能力一旦外包，团队就得接受外部价格、能力边界和服务稳定性的约束。

对软件工程师来说，比较现实的做法不是拒绝 AI，而是保留手感：

  • 用 AI 解释陌生代码、生成草稿、补测试、做探索；
  • 关键模块、核心架构、复杂调试，仍要亲手过一遍；
  • 不要只看 AI 摘要，要能回到代码本身；
  • 每周保留一定比例的纯手写、纯调试、纯阅读训练。

对技术负责人和正在采购 AI 编码工具的团队，动作要更硬一点：

管理动作目的不做的后果
给 AI 使用分级区分脚手架、测试、业务逻辑、核心基础设施所有代码都被同一种流程吞掉
要求关键 PR 说明人类判断让工程师解释取舍，而不是只贴生成结果review 变成形式确认
保留非 AI 路径确保模型不可用时还能开发和修复工作流被供应商状态绑架
记录 token 成本和重试率看清真实效率，不只看产出速度账单和返工成本被隐藏
给新人安排手写训练维持基本编码、调试、阅读能力培养出只会指挥 agent 的开发者

接下来最该观察的，不是某个模型又快了多少，而是三个变量。

一是 AI 生成代码进入主干后的维护成本。短期 demo 很漂亮，半年后的修改和排障才算账。

二是团队对单一模型供应商的依赖度。越依赖，迁移成本越高，采购谈判越被动。

三是工程师的代码心智模型有没有变薄。这个最难量化，却最要命。

我的判断很简单：AI 编码工具应该留在手边，不该坐上主位。让它加速局部工作，没问题；让它默认接管实现，再让人类在几千行生成代码后扮演“清醒的审核者”，这就有点自欺。

工程管理者要问的不是“我们用了多少 AI”，而是“团队还剩多少不依赖 AI 的判断力”。这才是下一轮软件组织的分水岭。