Why AI hasn't replaced software engineers, and won't
收录判断
这篇文章值得进入主线。它不是泛泛讨论“AI 会不会抢工作”，而是以软件工程这个 AI coding 渗透最快的职业为样本，结合裁员叙事、WARN Act 披露、就业趋势、代码生成与发布转化数据，解释为什么 AI 首先压缩的是执行层，而不是自动消除决策、验证和责任层。
编译摘要
1. 浓缩
- 核心结论 1: “AI 导致软件工程师大规模裁员”的叙事目前证据不足，很多案例更像是 AI-washing。
- 关键证据: Block、Snap、Intuit 等案例中，公开叙事把 AI 放在前台，但后续信息显示财务压力、激进投资者施压、管理层级收缩和疫情期扩张回调才是主要背景。
- 关键证据: 多项调查显示，企业更愿意用 AI 解释 hiring freeze 或 layoffs；HBR 调查中，因“预期 AI”而做出裁员的高管比例远高于因实际 AI 实施而裁员的比例。
- 关键证据: 纽约州 WARN Act 在新增 AI 披露 checkbox 后，首年 160 多家公司中几乎没有企业勾选 AI；截至 late May，只有 Nespresso 一例，约 46 / 25,000 被裁员工被标记为受 AI 影响。
- 核心结论 2: 软件工程可以被看作 decide-execute-deliver sandwich；AI 已明显压缩 execute 层，但 decide 与 deliver 层仍由人类理解、验证和问责支撑。
- 关键证据: 原文引用 “Writing Code vs. Shipping Code” 研究：AI agents 让代码行数增加 8 倍，但 releases 只增加约 30%，说明代码生成量与交付结果之间存在强转换瓶颈。
- 关键证据: 开发者时间研究显示，coding 本身并不总是主要时间占用；真实瓶颈集中在决定做什么、验证交付是否正确，以及理解代码库、业务和环境。
- 关键证据: SWE-chat 数据显示，agent 生成代码只有 44% 留到用户 commits；vibe-coded commits 引入漏洞的比例是纯人工 commits 的 9 倍；最常见意图是理解既有代码，而不是生成新代码。
- 核心结论 3: AI 更可能改变软件工程师的工作结构，而不是简单消灭整体需求；纯执行型 programming 被继续压缩，工程师价值上移到判断、监督、验证和领域责任。
- 关键证据: 文章区分 programmer 与 software engineer：前者更偏执行层，长期已经萎缩且薪资更低；AI 加速的是这个既有趋势。
- 关键证据: Federal Reserve 相关研究显示，post-ChatGPT 软件工程就业仍增长，但相对无 AI 反事实每年约慢 3 个百分点；文章也提醒该研究无法捕捉自雇和创业吸收。
- 关键证据: 文章用软件需求价格弹性解释可能的需求扩张：当软件创建成本下降，更多一次性工具、内部流程和业务场景会变得值得软件化。
2. 质疑
- 关于样本选择的质疑: 软件工程确实是 AI coding 进展最快的职业，但“软件工程尚未被替代”不能直接外推到所有知识工作。不同职业的合规、任务可验证性、责任边界和需求弹性差异很大。
- 关于 WARN Act 数据的质疑: 纽约 WARN AI checkbox 是强证据，但它覆盖的是特定地区、特定规模裁员和企业自报字段。企业也可能把 AI 影响归入其他原因，或者尚未到需要披露的阶段。
- 关于 sandwich 模型的质疑: decide 与 deliver 层现在抗自动化，不等于永远不可压缩。更好的 eval、产品遥测、需求管理、形式化规格和组织流程改造可能继续压缩部分边界任务。
- 关于需求扩张的质疑: 软件需求增加不等于每个软件工程师都更安全。岗位稳定性还受公司规模、工资结构、技能迁移、地理分布和“更多软件由非工程师完成”影响。
- 关于价值判断的质疑: 文章主张通过规范、法律和政策保留人类问责，这是可辩护的治理选择，但不是单纯由技术数据推出的事实结论。
3. 对标
- 与 AI-Labor-Bottleneck-Shift 对标: 文章给出软件工程场景的具体样本：AI 放大代码生成后，瓶颈迁移到需求决定、验证、accountability 和系统理解，而不是简单消失。
- 与 Input-Output-Outcome 对标: “代码行数 8 倍增长但 releases 只增加 30%”是 input 与 output 不同步的直接证据；代码生成量不能被当成业务结果。
- 与 Agentic-Engineering-vs-Vibe-Coding 对标: 文章用 SWE-chat 数据强化了两者边界：vibe coding 低监督、高风险；agentic engineering 则要求人保持控制、审查和责任。
- 与 Essential-Complexity 对标: Fred Brooks 的 essential complexity 被用来解释 decide 层为什么厚：指定正确行为、理解领域约束和承担后果，不能靠更快代码生成自动消除。
- 与 Jevons-Paradox-for-Knowledge-Work 对标: 文章为软件领域提供了一个更谨慎的 Jevons 版本：软件更便宜可能带来更多需求，但就业收益仍取决于需求弹性、替代弹性和分配机制。
- 与 Decision-Quality 对标: 当 execute 层被压缩，人类价值上移到“什么值得做、如何验收、谁为失败负责”；这正是决策质量在工程场景中的落点。