Google 说，公司新代码里 75% 由 AI 生成。微软 CEO 曾说比例最高到 30%，CTO Kevin Scott 预期到 2030 年微软 95% 的代码会由 AI 生成。Anthropic 也说，多数团队 90% 的代码来自 AI。

这些数字很适合放进发布会、财报和效率故事里。但 404 Media 采访到的多位匿名开发者讲了另一面：AI 不是单纯把代码写快了，它也把审查、理解、debug 和维护成本推回给人。

数字很亮，工程现场没那么亮

这轮争议的核心，不是“AI 能不能写代码”。它当然能写。

真正的问题是：当公司开始高调展示 AI 代码占比，一线工程师是否也真的少干了活、少背了风险、少欠了债？目前能看到的匿名反馈，答案并不稳。

维度公司叙事开发者反馈
代码占比Google 75%、微软最高 30%、Anthropic 多数团队 90%、微软 CTO 预期 2030 年 95%占比上升，不等于质量上升
使用方式AI-first、效率提升、工具升级绩效评估、组织重组、工具替换在推动采用
直接成本更快交付、更低人力压力PR 膨胀、审查更累、debug 更慢
受影响者全体工程团队初级开发者、新员工、维护复杂系统的人最吃力

开发者的抱怨并不玄乎。

AI 会写错。复杂分布式 Web 应用里，上下文很难喂完整。它能一次生成大量代码，也能一次制造大量不确定性。

有人提到，要审 1000 多行 AI 生成的 pull request。省下的不是工作量，只是把工作从“写”挪到了“查”。更糟的是，查错比写错更累，因为审查者要先猜模型到底误解了什么。

还有开发者说，Claude Code 的 token 用完后，自己竟然“没法继续工作”。这句话刺耳。工具本来该增强能力，结果变成了临时拐杖。

这里要加一个限制：这些反馈主要来自匿名开发者，不能直接推成全行业定论。它更像一条越来越清楚的一线反叙事：AI 编程的收益真实存在，副作用也开始进入工程日常。

受影响最大的是两类人

AI 编程不是一无是处。

做原型、探索陌生领域、查日志、找文档、定位某个请求在哪里被处理，这些场景很有价值。它像一个很快的检索员，也像一个不知疲倦的草稿助手。

边界一旦被抹掉，问题就来了。辅助检索被讲成生产主力，原型速度被包装成工程能力，团队就会误判成本。

最容易吃亏的是初级开发者和新员工。

新员工进入代码库，本来要靠读代码、改小功能、踩边界来建立地图。系统怎么流动，约定在哪里，历史包袱为什么还没删，这些东西靠长期接触长出来。

如果一上来就把路径外包给模型，代码可能提交了，人却没有真正进入系统。短期看，交付更快；长期看，判断力没长出来，依赖先长出来了。

对软件开发者来说，现实动作很简单：别把 AI 输出直接当答案。更该保留自己的心智模型，尤其是关键路径、权限边界、数据流、异常处理。AI 可以帮你找路，但不能替你知道这条路为什么存在。

对技术管理者来说，动作更硬：不要用“AI 使用率”当核心绩效。更应该看三件事：

  • AI 生成 PR 的审查耗时有没有下降；
  • 代码返工、回滚、debug 时间有没有增加；
  • 新人是否还能解释自己提交的关键改动。

如果这些指标没变好，只是生成行数变多，那不是提效，是把技术债包装成产能。

关注 AI 生产力叙事的人，也该换一个看法。不要只看公司说 AI 写了多少代码，要看这些代码谁审、谁维护、谁在事故后解释。

真正坏掉的是激励设计

我更在意的不是模型能力，而是组织激励。

当管理层把 AI 使用率当成绩效指标、组织方向和资本市场叙事，工程行为会变形。质量不再是第一信号，参与姿态才是。

这就危险。

软件工程的核心资产，是长期积累的判断力：什么代码该删，什么抽象先别上，哪个改动会在三个月后反咬系统。AI 可以放大熟手的速度，也可以放大生手的幻觉。

“天下熙熙，皆为利来。”放在这里不复杂：公司需要 AI 效率故事，管理层需要可量化采用率，工具厂商需要更多 token 消耗。于是代码量变成成绩单，审查和维护成本留给工程团队内部消化。

这也是裁员叙事和 AI 编程绑在一起的原因。不能说 AI 代码必然导致裁员，但科技公司确实在用“效率提升”解释缩编。Meta、Microsoft、Snap 等公司都把 AI 使用和减少人力放在同一套话术里。

对员工来说，工具不再只是工具。它还成了组织压力。

这件事和早年的流水线有一点像，但不完全一样。流水线把工人动作拆细，换来规模效率；AI 编程把工程判断的一部分外包给模型，换来生成速度。前者更容易计件，后者更难验收。

软件不是砖头。代码越多，系统未必越强。很多时候，真正值钱的是少写、删掉、延后、拒绝一个看似聪明的抽象。

接下来最该观察的，不是哪个大厂又宣布 AI 写了多少代码，而是四个更硬的变量：

  • AI 生成代码的审查时间是否被单独统计；
  • 团队是否限制 AI 大批量提交关键模块；
  • 新人培养是否仍要求读懂代码库，而不是只会提 prompt；
  • 管理层是否把 AI 采用率从绩效硬指标里拿出来。

好的团队会把 AI 放在可验证、可回滚、可审计的位置。差的团队会让它制造更多代码，再让人类在疲惫中签字。

前者是工具升级。后者是表演式自动化。

回到开头那组漂亮数字。75%、90%、95% 都能讲故事，但它们不能证明工程系统更健康。最后留下来的，不是发布会上的百分比，而是谁还能解释自己提交了什么。