AI 写代码过了 75%:程序员真正该担心的不是被替代

75% 这个数字，说明 AI 编程已经不是插件

据 Semafor 和 Business Insider 近日报道，Google CEO Sundar Pichai 表示，Google 当前约 75% 的新代码由 AI 生成，再由工程师审查。这个数字在 2024 年还是约 25%，到 2025 年秋天升至 50%，如今进一步提高。

单看“75%”很容易引发情绪化讨论：程序员是不是不需要写代码了？大厂是不是准备裁掉初级工程师？AI 是不是已经可

真正的风险，不在模型会犯错，而在错误会被规模化

很多人讨论 AI 写代码的风险，仍然停留在“它会不会写错逻辑”。这当然重要，但已经不是全部。

人写错代码，通常是局部错误。AI agent 写错代码，风险在于它可能一次性改动多个模块、引入多个依赖、生成看似

AI 编程的下一层竞争，是“默认安全”

Cursor、GitHub Copilot、Claude Code、Codex、Gemini Code Assist 这类工具，过去竞争的关键词是上下文长度、补全质量、响应速度、多文件修改能力。

接下来，竞争会转向另一组词：权限边界、依赖可信度、变更可追溯、测试自动化、审查可解释、企业策略集成。

原因很简单：当 AI 只是帮个人写脚本

程序员的价值会转移到哪里

如果 AI 真的承担越来越多代码生成，程序员还剩下什么？

一个常见误解是：代码写得越少，工程师价值越低。实际情况可能相反。代码生成变便宜之后，真正稀缺的是判断力。

判断一个需求是否应该做，比实现它更

小团队更要小心“AI 速度幻觉”

大厂推 AI 编程，通常有完整的代码审查、CI/CD、权限系统和安全团队兜底。小团队不一样。

对小团队来说，AI 编程的诱惑更强：一个人可以写出三个人的代码量，原本排期两周的功能可能三天就能上线。但如果缺少审查和测试，这种速度很容易变成幻觉。

最危险的情况是：团队感觉自己变快了，但其实只是把风险从开发阶段推迟到了线上。

结语：AI 写代码越强，工程纪律越重要

AI 编程的趋势已经很清楚：它会继续深入 IDE、代码托管平台、CI 环境和企业开发流程。未来几年，越来越多代码会由 AI 生成，越来越多 PR 会由 agent 提交，越来越多重构会由模型参与完成。

但这不意味着软件工程变简单了。

恰恰相反，代码生成成本下降后，系统复杂度、审查压力和供应链风险都会被放大。过去我们担心“写不出来”，现在更要担心“生成太容易，却没有足够的治理”。

所以，程序员真正要担心的不是 AI 会不会写代码，而是自己是否还掌握判断代码是否应该存在、是否安全、是否可维护的能力。

AI 写代码的时代，工程师的竞争力不再只是手速，而是秩序感。

这也是“计算秩序”这个名字在今天变得更有意义的地方：当生成能力变得廉价，秩序本身才是稀缺资源。

参考来源：

• Semafor：Google CEO says 75% of company’s new code is AI-generated

• Business Insider：Google says 75% of the company’s new code is AI-generated

• GitHub Blog：GitHub Copilot: Meet the new coding agent

• Chainguard / PR Newswire：Chainguard and Cursor Partner to Secure Agentic Coding with Trusted Open Source

一个更稳妥的做法是，把 AI 编程纳入规则，而不是完全靠个人习惯：

所有 AI 生成的大改动必须走 PR；新增依赖必须说明理由；关键模块必须有人类 reviewer；生成代码必须跑测试和静态检查；安全相关改动不能让 AI 独立合并；对迁移、权限、支付、登录、数据删除等高风险模块设置更高门槛。

这听起来会慢一点，但它能避免团队被“代码数量增长”误导。

真正有价值的 AI 编程，不是让仓库里多出更多代码，而是让可靠的软件更快交付。

重要。判断一个抽象是否会污染系统，比写出抽象更重要。判断一个依赖是否值得引入，比安装它更重要。判断一个 AI 生成的 PR 是否改变了系统不变量，比逐行写代码更重要。

这会让工程师的角色更像“系统设计者 + 审查者 + 风险控制者”。尤其在复杂业务里，代码只是显性部分，真正难的是上下文：历史债务、团队约定、线上事故、性能边界、用户路径、合规要求。

AI 可以读很多文件，但它未必知道哪些约束不能碰。它可以生成测试，但未必知道哪些失败模式最危险。它可以跑迁移，但未必知道一个看似过时的分支其实是在保护某个边缘客户。

所以，程序员不是简单地从“写代码的人”变成“看 AI 写代码的人”。更准确地说，是从“代码生产者”变成“工程系统的责任人”。

，容错空间很大；当 AI 开始进入企业仓库、处理线上服务、参与迁移和重构，组织就必须回答几个问题：

第一，AI 能不能访问这个仓库？第二，AI 能不能改这些目录？第三，AI 引入的依赖从哪里来？第四，AI 提交的 PR 谁来审？第五，AI 的操作日志能不能复盘？第六，出了问题之后，责任链能不能追踪？

这些问题听起来不性感，却决定 AI 编程能不能从“个人效率工具”变成“组织级生产力”。

未来优秀的 AI 编程平台，很可能不是最会炫技的那个，而是最能把安全、权限和工程纪律做进默认流程的那个。

合理但未经验证的兼容层，还可能在重构时把旧系统里的隐含约束抹掉。

更麻烦的是，AI 很擅长“让代码看起来像真的”。它会给出完整的函数、注释、测试样例和错误处理分支。对于审阅者来说，这种代码的危险之处不在粗糙，而在顺滑。顺滑会降低警觉。

如果一个团队只是把 AI 当成速度工具，而没有同步升级代码审查、依赖治理、测试覆盖和供应链安全，那么产能提升越快，风险堆积也越快。

这就是为什么 Cursor 与 Chainguard 的合作值得关注。Chainguard 在 4 月 21 日宣布与 Cursor 合作，为 agentic coding 提供可信开源工件和供应链安全能力。它指向的是一个现实问题：AI 生成代码时，不只是写业务逻辑，也会选择镜像、库、包和构建方式。一旦这些选择不可靠，风险就进入了生产环境。

以接管软件开发？

但更值得看的不是比例本身，而是开发流程的变化。

过去的 AI 编程助手，更像 IDE 里的副驾驶：你写一段，它补一段；你问一个 API，它给你示例。现在的主流方向正在变成 agentic workflow，也就是“代理式工作流”：人不再只是给一句提示词等补全，而是把一个任务交给代理，让它理解上下文、修改多处文件、提交变更，再由人审阅。

GitHub Copilot coding agent 就是典型例子。GitHub 在 2025 年发布相关能力时，强调它可以被分配 issue，在 GitHub Actions 环境中工作，并提交 draft pull request。换句话说，AI 不只是坐在编辑器旁边，而是开始进入软件交付链路。

这件事的意义很大：AI 编程从“生成代码片段”，升级到了“参与工程过程”。