Anthropic工程师不再亲手写代码

Anthropic 把“写代码”交给了 Claude

Anthropic 平台工程团队已经把实际编码工作全面交给 Claude，工程师的主要职责则转向系统设计、结果验证和代码质量把关。

10 月 22 日消息，Anthropic 平台工程团队负责人 Katelyn Lesse 在 Grafana Labs 举办的 ObservabilityCON 活动上表示：就其团队负责的系统开发与维护而言，“所有代码都是 Claude 写的，真的是全部”。该团队还已允许 AI 智能体在没有人工干预的情况下自主修复测试，并开始探索让智能体直接修改实际代码库。

这句话的边界需要说清楚：Lesse 描述的是 Anthropic 平台工程团队，不是 Anthropic 全公司的每一行代码；“全部由 Claude 编写”也不等于 Claude 可以不经审查直接把任意修改送进生产环境。当前更准确的工作流是，人类决定做什么、系统应该满足哪些约束，Claude 负责把这些意图转化为代码，人类再对结果承担最终责任。

平台工程是为研发团队建设和维护内部基础设施、开发工具、核心服务与交付流程的工程职能。 这类团队面对的通常不是一个孤立网页，而是权限系统、部署管线、监控设施、服务框架和开发者平台，因此此次变化比“让 AI 写一个功能页面”更有代表性。

“全部由 Claude 写”不等于工程师退出

Anthropic 的变化不是用 Claude 替换完整的软件工程流程，而是把流程中最容易规模化的代码生产环节交给模型。

AI 编程智能体是能够读取代码库、拆解任务、编辑多个文件、运行命令并根据测试结果持续迭代的软件代理。 它和早期的代码补全工具不同：补全工具主要预测光标后的几行内容，智能体则可以围绕一个目标连续工作，在发现测试失败后定位原因、修改实现，再次执行测试。

Lesse 给出的典型案例，是一次大型代码库从 Python 迁移到 Rust 的项目。Python 到 Rust 的迁移并不是逐行翻译：两种语言在类型系统、所有权、并发模型、错误处理和依赖生态上均存在明显差异，机械替换语法往往会生成“能够编译但行为不一致”的代码。

在这次迁移中，人类工程师首先设计验证机制，明确兼容性要求、性能目标和允许发生的行为变化；Claude 再完成组件开发、代码改写、监控接入以及验证流程中的大量具体工作。换句话说，人类编写的是“判卷标准”，AI 完成的是大部分“答题过程”。

这种分工解释了为什么工程师依然关键。只要需求本身含糊、验收标准不完整，智能体就可能非常高效地实现一个错误目标。代码生成越快，错误假设被复制到更多模块的速度也越快。

Anthropic 的 AI 编码比例已经从 80% 走向局部 100%

Anthropic 平台团队此次披露的“全部代码由 Claude 生成”，是该公司过去一年内部 AI 编码趋势的进一步延伸。

Anthropic 在 2026 年 6 月公布的技术报告中称，截至当年 5 月，Claude 编写的代码已占公司合并至生产代码库代码行数的 80% 以上。2026 年第二季度，工程师日均合并的代码量达到 2024 年的 8 倍。现在，平台工程团队进一步将实际编码比例推至接近 100%，但范围仍限定于该团队负责的系统开发与维护。

| 指标 | 2026 年 5 月前后 | 2026 年 10 月最新披露 | 应如何理解 | |---|---:|---:|---| | Claude 生成代码占比 | Anthropic 全公司合入生产代码超过 80% | 平台工程团队开发维护代码为 100% | 统计口径不同，不能直接视为全公司达到 100% | | 工程代码吞吐量 | 2026 年第二季度约为 2024 年的 8 倍 | 未披露平台团队单独增幅 | 代码量增加不等于业务价值同步增加 | | 智能体权限 | 可编写文件、执行任务并参与工程流程 | 已可自主修复测试 | 自主修复测试不代表可任意部署生产代码 | | 人类主要职责 | 设定目标、指导和审查 | 架构设计、验证、质量把关 | 瓶颈从输入代码转向判断结果 | | 下一步探索 | 更长时间、更复杂的工程任务 | 直接修改实际代码库 | 权限和审批边界仍在讨论中 |

代码行数不是一个足够可靠的生产力指标。一个重复生成的适配层可能包含数万行代码，却不一定比修复一个关键并发缺陷更有价值；模型也可能用更多抽象和样板代码完成原本简单的任务。因此，“80%”和“100%”说明代码生产主体正在变化，却不能单独证明软件质量提升了多少。

真正有含金量的数据是“8 倍吞吐量”。这个数字说明 Anthropic 已经越过了 AI 编程的试用阶段：当每日进入审查、测试和集成环节的变更量达到过去的数倍时，团队不可能继续沿用完全依赖人工逐行阅读的流程。

软件工程的新瓶颈叫“验证”

验证是通过测试、静态分析、行为对比、监控指标和人工评审，确认软件实现符合预期约束的过程。 在 AI 原生研发流程中，验证不是生成代码后的附属步骤，而是决定智能体能获得多大权限的核心基础设施。

传统团队往往把工程效率理解为“工程师一天能写多少代码”，而 Anthropic 的实践表明，代码供应开始接近过剩。一个智能体可以同时修改多个文件，多个智能体又可以并行处理不同任务，最终限制交付速度的会变成以下环节：

• 产品和工程负责人能否把目标描述清楚；
• 测试是否覆盖真正重要的行为，而不只是提高覆盖率数字；
• 代码审查是否能发现跨服务、跨权限边界的问题；
• 监控系统能否判断线上行为发生了语义偏移；
• 出现事故时，团队能否还原智能体做出修改的完整轨迹；
• 最终批准者是否理解自己正在批准什么。

Anthropic 已允许智能体自主修复测试，但这件事同时存在一个经典风险：如果智能体既能改实现，也能改测试，它可能通过降低测试标准让流水线重新变绿。真正可靠的自主修复系统必须区分实现代码、验收规则和高风险配置的权限，并为关键测试建立不可被任务智能体随意改写的信任边界。

因此，让智能体直接修改代码库并不是简单增加一个写权限。企业需要回答“它能改哪些目录”“能否修改测试”“能否更新依赖”“谁可以触发部署”“高风险变更是否必须人工批准”等问题。权限范围越大，审计日志、沙箱隔离和回滚机制的重要性就越高。

AI 生成代码越多，安全体系越不能只盯代码

AI 智能体正在成为软件供应链中的新参与者，而不再只是工程师使用的一项编辑器功能。

传统软件供应链主要保护源代码、依赖、构建系统、凭证和生产环境；智能体进入流程后，企业还要保护智能体的上下文、工具权限、身份、调用链和行为轨迹。例如，代码库中的恶意文档或第三方依赖说明可能包含提示注入内容，诱导智能体执行偏离任务目标的命令。

这类风险无法仅靠传统的“某次调用是否有权限”来解决。单独看，每次读取文件、运行测试和创建提交都可能是合法操作；组合起来，它们却可能把敏感信息带出隔离环境，或者生成表面通过测试、实际削弱安全边界的修改。

Anthropic 管理层对直接修改真实代码库依然谨慎是合理的。平台工程掌握的往往是高权限基础设施，一次错误配置可能影响多个产品和研发团队。越靠近身份认证、部署系统、密钥管理和生产控制面，越不适合仅凭“模型最近表现不错”就扩大自治范围。

初级岗位首先受到冲击，但高级工程师也不能只做审查员

Anthropic 的招聘数据已经显示，AI 编程正在改变技术团队的人员结构。

该公司 10 月 16 日发布的报告显示，2025 年初至 2026 年，初级员工在技术部门中的占比从 21% 降至 14%，减少 7 个百分点，相对降幅约为 33%；初级技术岗位在技术部门招聘中的占比则从 27% 降至 9%，减少 18 个百分点，相对降幅约为 67%。

| Anthropic 技术组织指标 | 2025 年初 | 2026 年 | 变化 | |---|---:|---:|---:| | 初级员工占技术部门比例 | 21% | 14% | 下降 7 个百分点 | | 初级岗位占技术招聘比例 | 27% | 9% | 下降 18 个百分点 | | 初级招聘占比相对降幅 | — | — | 约 67% |

初级岗位减少的直接原因，是模型率先覆盖了边界清晰、容易验收的工作，例如编写常规业务逻辑、补充测试、迁移接口、排查常见漏洞和修复明确的缺陷。企业因此更愿意招聘能够独立定义问题、判断优先级并承担结果责任的人。

但把未来工程师简单描述成“只负责审查 AI 代码”同样过于乐观。长期脱离实现细节，可能让工程师逐渐失去判断模型输出是否合理的能力；如果初级岗位持续收缩，企业还会面对人才梯队断层——今天负责架构与验证的高级工程师，本身正是从大量基础编码和故障处理中成长起来的。

更可持续的做法，是把新人训练从“多写样板代码”转向“在 AI 参与下完成完整闭环”。新人仍然需要阅读代码、调试系统和处理事故，只是训练重点应从记忆语法转向建立系统模型、设计测试、分析日志以及解释失败原因。

这不是“程序员消失”，而是软件生产方式换挡

Anthropic 的案例证明，编码本身正在从稀缺能力变成可批量调用的生产能力，但软件工程并没有因此被完全自动化。

软件开发至少包含五层工作：选择问题、设计系统、实现代码、验证行为、承担后果。Claude 已经大量接管第四层之前的具体执行，甚至开始参与测试和故障修复；但“哪些问题值得解决”“哪些约束不能突破”“结果是否可信”仍然主要由人类决定。

这次披露真正重要的地方，不是“100%”这个容易传播的数字，而是 Anthropic 已经围绕 AI 生产代码重新设计团队职责。工程师不再以亲手敲入多少代码证明价值，而是以能否构建清晰约束、可靠验证和可控交付流程证明价值。

对于普通研发团队，这套模式暂时不能照搬。Anthropic 既是 Claude 的开发者，也是最了解其能力边界、最有条件投入内部工具与安全设施的公司之一。缺少高质量测试、可观测性、权限隔离和快速回滚能力的团队，如果直接追求“100% AI 编码”，得到的很可能不是 8 倍生产力，而是 8 倍等待审查的变更和更难定位的线上故障。

我们的判断是，软件工程的竞争重点正在从“谁能生成更多代码”转向“谁能更便宜、更可靠地验证代码”。模型能力会继续趋同，代码生成价格也会继续下降，但高质量测试集、真实生产反馈、内部架构知识和清晰的责任边界不会自动出现。下一阶段最值钱的工程资产，可能不是代码本身，而是证明代码正确的整套机制。

参考来源

• IT之家：Anthropic 平台工程团队全面采用 Claude 编码——整理 Katelyn Lesse 在 ObservabilityCON 上的发言，以及 Anthropic 内部代码生成比例和招聘结构变化。
• GitHub：Anthropic Claude Code 官方仓库——Claude Code 的官方公开仓库，可用于了解其产品定位、命令行工作方式及相关更新。