Claude 承担编码后，平台工程师做什么

Anthropic 平台工程团队负责人 Katelyn Lesse 在 ObservabilityCON 上表示，团队开发和维护系统所需的代码已经全部交给 Claude 编写，工程师更多负责系统设计、验证和质量把关。真正值得关注的，是编码交出去之后，人还要控制哪些环节。

原文给出了 Python 迁移到 Rust、自主修复测试和招聘结构变化几个线索。不过，它没有提供交付速度、故障率或成本的对照数据。「全部代码由 AI 写」能说明工作分工变了，还不能证明效果全面更好。

代码全由 Claude 写，工程师还负责什么

据原文，Lesse 负责的平台工程团队覆盖核心服务、开发者工具和产品基础设施。《商业内幕》报道，该团队今年夏季约有 200 人。她所说的「全部」，限定在这个团队及其系统开发、维护工作中。

公司整体还有另一个统计口径：Anthropic 于 2026 年 6 月发布的技术报告称，截至当年 5 月，Claude 编写的代码占公司合并至生产代码库的代码行数的 80% 以上。

这两个数字不能混用。前者是团队负责人的描述，后者按全公司生产代码库的合并行数统计。代码行数也无法直接代表任务难度、工程价值或节省的人力。

作者引用的 Python 迁移到 Rust 案例，更能解释新的分工：团队成员先设计验证机制，确认迁移后的产物符合预期；代码组件开发、监控，以及验证过程中的大量具体工作，则交给 AI 智能体执行。

工程师的责任正在向「定义正确结果，并证明结果正确」集中。

但报道没有交代验证机制的细节。它如何检查行为一致性、覆盖哪些边界、是否包含性能要求，都不能从这篇报道中得出答案。

自主修复测试，距离自主改生产代码还有多远

Anthropic 已允许 AI 智能体在没有人工干预的情况下自主修复测试，同时正在探索让智能体直接修改实际代码库。

这里有一条明确的权限边界：已经开放的能力是自主修复测试，直接修改实际代码库仍处于谨慎探索阶段。不能把「代码全部由 Claude 生成」理解成「从提出需求到上线都无人参与」。

报道也没有解释「修复测试」具体指什么：是修复失效的测试脚本，还是根据测试失败修复业务实现？这一区别很关键。测试通过是否可信，取决于测试还在不在检查原来的要求。

招聘数据则展示了另一种变化。Anthropic 于 10 月 16 日发布的报告称，2025 年初至 2026 年期间：

• 初级员工在技术部门中的占比从 21% 降至 14%。
• 初级技术岗位在技术部门招聘中的占比从 27% 降至 9%。

公司表示，招聘更看重自主性和判断能力。但占比下降不等于人数减少，原文也没有提供足够信息，将变化全部归因于 AI 编程。

我的判断

我认同这篇报道传递的方向：当代码生成变得更容易，拆解问题、设计系统和判断结果的价值会更突出。Python 迁移到 Rust 的案例尤其说明，能否定义一套可信的验收办法，可能比能否快速生成实现更关键。

不过，报道展示的是 Anthropic 自身的实践和管理判断。它没有给出与人工编码团队的对照，也没有披露返工量、审查耗时、生产故障或总成本。拿它证明普通团队也应该追求「100% AI 编码」，证据还不够。

与要求工程师逐行手写相比，这种方式把更多执行工作交给了智能体；与直接放开自动修改相比，它又保留了人对设计、验证和权限的控制。一般团队能否采用，首先取决于有没有足够可靠的验收能力。

值得借鉴的是责任分工，代码生成比例不适合作为单独的成功指标。

能拿来做什么

• 给 Claude 分配代码迁移或重构任务前，先写清输入输出、必须保持的行为和验收条件，把「符合预期」变成可以检查的要求。
• 在日常 AI 编程中，把生成实现、修改测试和修改实际代码库分成不同权限，逐步开放，并检查每一步产生的变更。
• 评估 AI 编码效果时，同时记录审查耗时、返工情况和交付质量，避免只统计生成了多少行代码。
• 初级开发者可以刻意练习任务拆解、测试设计和代码审查，让自己能够解释实现为什么正确，而不只是运行生成的代码。