Google 为了把 Abseil 开源出去，必须先清理约 2 亿至 2.5 亿行第一方 C++ 代码里对旧基础设施的依赖。难点不在改代码，而在同步——几千名工程师每天都在往这堆代码里提交新改动，任何『先冻结再替换』的做法都会让整个公司停摆。解法是让新旧 API 长期共存、用确定性工具批量生成修改、分批迁移，最后才删旧接口。这也是『大规模重构』与『单文件重构』根本不同的地方。

Winters 把团队学习放进软件工程的因果链：成员敢承认不知道、敢分享失败，才能让代码惯例跨团队传播。这套逻辑成立的假设是——组织愿意为长期学习付成本。一旦裁员和内部竞争让工程师把『暴露问题』等同于『显得可替代』，心理安全崩塌，readability 之类的辅导机制就退化成形式。已被独立验证的是心理安全与团队学习能力、团队绩效的正相关（Edmondson 一脉的实证研究），尚未被独立验证的是 Winters 关于裁员造成效率损失的因果估计。

一边是 Science 论文和多项调研：AI 让资深开发者的优势被放大，交付代码中 AI 生成占比、效率感知都明显高于新手，经验似乎更值钱了。另一边是审核端数据：LinearB 分析 810 万个 PR 发现 AI 写的代码要等 4.6 倍时间才被接手，GitHub 每月 AI Agent 发起的 PR 半年内从 400 万涨到 1700 万，Xavier Portilla Edo 直言『AI 发的 PR 只有十分之一合格』。同一场效率革命，产出侧和验收侧给出完全相反的账单。

Anthropic 内部用 Claude Code 把 Bun 从 Zig 重写到 Rust，53 万行仅用 11 天且测试全绿；另一个案例一个周末把 Python 项目迁成 16.5 万行 TypeScript，全平台构建从 30 分钟降到约 2 秒。关键变量不是模型多强，而是工作重心从『改代码』转成『修规则手册』——发现 AI 反复犯同一类错，就去改规则，让后续所有翻译不再犯。这条路径能否推广，要等几万行以上、有复杂外部依赖的项目给出更多复现结果。

Winters 主张教育应考查提示词、测试与过程证据，而不是只看最终代码。顺着想下去有个更尖锐的追问：当 AI 能稳定生成可运行的代码片段时，稀缺的能力究竟是把模糊业务需求翻译成精确技术问题，还是判断 AI 输出里哪行注定要回头改？现有证据偏向后者——研究显示高经验开发者能把需求描述完整度做到 95%，生成代码缺陷密度约 0.3 个/千行，新手在调试环节耗时和误诊率都高一个量级。但『问题定义』能否被系统训练、还是只能靠实战泡出来，仍无定论。