先看证据
一则引述，指向一种工作制度
Simon Willison 在 2026 年 9 月 20 日的博客中收录了一名工程师的引述。引述者说，自己加入一家大公司半个月后发现，规格、代码、测试、PRD、工单、工单解决方案和报告，几乎所有工程产物都由 Claude Code 生成。团队成员并不喜欢这种方式，却被要求尽可能多地交付，工程师从 L1 到 L7 都在做同一件事：和模型对话，然后让生成结果继续向前流动。
这段材料不是一份经过审计的组织调查，也没有给出公司名称、事故记录或代码质量数据。它的价值不在于证明所有企业都已经如此工作，而在于它把一种容易被管理话术遮蔽的冲突说得很具体：管理层认为“推代码不是瓶颈”，团队却每天工作 12 至 13 小时，几乎只是按下回车。代码提交变快，并没有带来工作时间下降，反而可能让人更长时间地维持一种低理解度的生产状态。
瓶颈没有消失，只是换了位置
把 Claude Code 看成一个更快的代码编辑器，会低估这段引述描述的变化。材料明确提到的不是单一代码片段，而是一条从需求表达开始、经过实现与测试、再延伸到工单和报告的产物链。当模型参与每个环节时，组织获得的不是某一个岗位的局部加速，而是一种可以持续生成下一份工程文件的流水线。
知识图谱中关于 Claude Code 的既有记录也显示，它可以执行插件评测，压缩后重新阅读最近修改的文件，提交、监控和调试 OSMO 流水线，并通过 Agent SDK 接入更广泛的工程操作。这些能力本身并不说明工具必然失控，但它们改变了错误的传播方式。过去一个含糊的判断可能停留在某个人的草稿里，现在它可以被模型扩展成规格、代码、测试、工单和报告，看起来完整，却未必经过任何人的真正核对。
从 L1 到 L7，问题不再是初级工程师
引述中特别值得技术负责人注意的一点，是从 L1 到 L7 的工程师都被置于同一种工作方式中。这里没有出现“模型替代初级工程师、资深工程师负责把关”的分工，反而是所有人都在和 Claude Code 对话，几乎没人阅读生成内容。于是，级别差异不再自然地转化为理解系统的机会，而可能只转化为承担更多任务和推动更多提交的压力。
这也解释了为什么“代码不是瓶颈”会成为危险的管理判断。代码当然可以很快地产生，但工程交付并不只包含产生代码。团队还必须确认需求到底表达了什么，测试是否覆盖了关键边界，变更会影响哪些依赖，以及出现问题时谁能解释当初的决策。如果这些判断被推迟到上线之后，它们并没有消失，只是以返工、排障和事故响应的形式变得更昂贵。
提交量会制造一种进展幻觉
当管理层把提交代码视为进度信号，生成能力就会被组织自动翻译成更多提交。这个指标有一个明显优势：它容易统计，也容易在不同团队之间比较。但它无法回答最重要的问题。提交的内容是否解决了正确的问题，是否引入了新的复杂度，是否有人能够解释它的边界和失败方式，都不会从提交数量中自然显现出来。
在这则现场记录里，指标和工作体验已经发生了直接冲突。团队成员不喜欢这套方法，却每天工作 12 至 13 小时。更高的自动化覆盖率没有释放人的时间，因为人的任务被改写成维持模型输出、处理下一份生成物和满足交付压力。只要“更多代码”仍然被当成“更多进展”，Claude Code 越能连续执行工程动作，组织就越容易把未经理解的复杂度当成产能。
技术负责人要把交付重新定义为可解释
实际治理的起点，不是禁止使用 Claude Code，也不是要求每个人重新手写所有代码。更关键的判断是：哪些产物可以由模型生成，哪些决策必须由人明确说明，哪些变更需要在进入关键路径前验证意图、边界条件和后果。对生成物做抽样审查可以发现部分问题，但抽样不能替代关键路径上的责任确认，更不能让“模型已经做过”成为审查结束的理由。
这则引述没有提供事故样本，因此不能据此断言某家公司已经造成了具体损害。但它已经给出一个足够明确的管理信号：如果组织发现所有级别的人都在工作更久，却没人阅读系统正在增加什么，就不应继续把问题定义为执行不够快。此时更可执行的做法，是暂停单纯追逐提交量，建立能够说明需求、变更理由、验证范围和责任人的交付记录。自动化可以扩大生产能力，却不能替组织承担理解和负责的义务。