2026年8月12日，独立开发者Simon Willison在博客上转引了工程师Florian Herrengt的一段场景。团队第四次让AI修复同一个漏洞，去问最初写这个功能的人数据从哪来，对方说"我也不知道，我问问Claude"。两人盯着屏幕上一长串文字，谁都判断不出哪句是真的，但Claude看起来很自信。
这段场景出自Herrengt那篇《AI is removing the middle class of software engineering》，Willison只是转引了其中一段，本身不构成统计或调查结论。真正值得关注的不是AI会不会写代码，而是团队有没有能力验证AI写的东西对不对——理解系统这件事，正在被悄悄外包给一个不需要为错误负责的工具。
修了4次的bug，暴露的是系统没人懂
场景里的Fable和Claude只是团队用的工具名。材料没给出两者具体能力、故障率或市场表现的数据，不能把它们读成"AI编程工具不靠谱"的证据。
真正的信息是团队的处境：漏洞报了四次、修了四次，说明没人能定位问题根源，只能不停地"再问一次"。
"AI正在挤压软件工程师中间层"这个判断，目前更像一种风险预警，不是已经被证明的行业结论。材料没有岗位数据或裁员规模，讨论止步于一个具体、令人不安的假想案例。
责任链断在哪：传统开发和AI辅助开发的差别
传统开发流程慢，但通常留着一条责任链：人工写、人工审、留文档、出了问题能找到负责人。这条链子能不能撑住，取决于团队本身的流程和文档习惯，不是自动成立的。
AI辅助开发的速度优势，换来的往往是审查跟不上生成速度、文档没人补、责任划分变得模糊。这不是AI单方面造成的，组织流程混乱、文档一直没补、责任划分本来就不清晰，这些老问题在AI辅助开发之前就存在，AI只是让问题暴露得更快。
| 维度 | 传统开发 | AI辅助开发 | 前提/风险 |
|---|---|---|---|
| 代码来源 | 人工写 | AI生成 | 团队原有审查习惯是否保留 |
| 审查节奏 | 人审人 | 生成快于审查 | 复核流程有没有跟上 |
| 系统知识 | 靠文档和口述沉淀 | 容易散在对话记录里 | 有没有人专门整理 |
| 出错追责 | 通常能定位到人 | 容易变得模糊 | 团队是否明确谁签字负责 |
下面这张图是简化对比，实际情况取决于团队自己的流程和文档习惯，不是AI辅助开发天然就没有责任人：
LLM的固有限制是，它能流畅组织语言、给出看起来完整的答案，但无法自动保证内容真实。它更不可能替团队理解跨多个服务的数据流向、历史遗留决策，以及从没写进文档的隐含业务规则。自信和正确不是一回事。材料里也没有任何数据支撑"AI输出的错误率有多高"，只能说这是当前语言模型公认的边界。
工程师和技术负责人接下来该怎么做
对普通工程师来说，用AI写代码之后，最少要做三件事：追踪数据到底从哪张表、哪个服务来；自己写测试验证AI给的答案；把AI输出当草稿看，不当结论用。
对负责交付和质量的技术负责人来说，问题落在治理上：哪些模块允许AI辅助生成、谁签字审查、文档更新算不算完成标准的一部分。这些规则如果没有，AI辅助开发的速度优势会变成看不见的维护成本。
买不买某个AI编程工具从来不是核心问题。团队有没有审核能力，才是真正的约束条件。接下来值得盯的，是有没有更多同类场景被公开报出来，以及有团队开始把"AI生成代码必须配数据来源说明"写进流程——目前这些都还看不到规模化的证据，只能算一个正在浮现的信号。