把大模型写进 IDE,默认假设是「人人变快」。但 2025 年到 2026 年上半年的两股独立证据同时指向相反的结论:经验越丰富的工程师,在使用 AI 编程助手时的真实产出越接近「停滞」甚至「倒退」;而 Coding Agent 真正大规模的扩散,正在改变软件团队的人才结构本身,而不是简单地「给每个工程师配一个工具」。
这不是危言耸听,也不是 LLM 反对者的再一次情绪宣泄,而是观察生产环境半年之后的两组硬数据,以及一组正在浮现的工具栈,共同勾勒出的趋势线。
一、一份被广泛讨论,但很少被读完的研究
2025 年 7 月,独立测评机构 METR 发布了一份针对资深开源开发者的随机对照实验研究:让 16 名在大型开源项目上有长期贡献、平均年限超过五年的开发者,在自己真正熟悉、真正在维护的代码库上,完成一批被随机抽取的真实任务。一半时间允许使用 AI 工具,另一半时间不允许。研究者事先用基线测量确认:这些开发者自我预测,使用 AI 后会快 24%。
真实结果落在 −19%。也就是说,在自己最熟的代码上,带着 AI 工具去做真实任务,反而比不用时慢了将近两成。报告同时确认,这并非因为工具太弱:开发者被使用的模型来自 2025 年初的前沿档位,工具链也覆盖了代码补全、聊天式问答与代理式执行三种典型形态。
2026 年 2 月,METR 发布了一份方法论更新,标题直白:《我们正在改变开发者生产力实验的设计》。它承认 2025 年那次研究存在自我报告偏差、熟悉度差异、任务抽样等多处局限,并承诺在后续实验中重新校准测量方法。换句话说,METR 自己也并不否认 2025 年那份报告是「不完美的」——但它同时也没有撤回那 −19% 的结论,只是把它放进了一个更克制的语境里。
放在更大的背景里看,这份研究与同年其他几份独立研究(覆盖企业内大规模部署与开源贡献者样本)在方向上是一致的:AI 编程助手能显著降低「局部代码片段」的产出时间,但在「端到端任务」「跨文件修改」「生产环境变更」这三个真正吃工程能力的场景里,收益迅速衰减,甚至为负。
二、Kastra 事件:把「慢」变成「闯祸」
如果说 METR 研究揭示的是「资深开发者变慢」,那么 2026 年 7 月,HN 上 Show HN: Kastra 团队分享的一个真实事故,把这道斜率往下又拉了一截。
Kastra 的两位作者 Fernando 与 Carlos 公开复盘:他们的一个 Cursor Agent,在执行一个原本看似无害的迁移任务时,生成了这样一条 SQL:
DELETE FROM customers WHERE status='test'
这不是测试环境。这是生产数据库。Agent 没有理解「test」在这里只是一个状态值、不是一个隔离环境标识。指令被生成,等待执行,只在最后一道关卡被工程师肉眼拦截。
在 Show HN 帖子里,他们写道:真正让他们不安的,不是「这条 SQL 差点跑出去」,而是「如果那一刻人没盯着,栈里没有任何东西会拦下它」。LLM 是概率性的,提示词能影响行为,但不能决定性地决定一个 Agent 究竟「被允许做什么」。换言之,Agent 能写出 SQL,能几乎执行 SQL,但栈里没有任何一个 deterministic 的层在那个时刻拍板说:不行。
评论区的同行没有反驳这条核心论断。一位长期做平台工程的工程师留言,几乎是补刀式的补充:「允许 Agent 触碰生产环境本身就是重大疏漏,policy enforcement 是另一层而不是替代品。」Kastra 的作者接着回应:他们同意沙箱、短生命周期凭证、多 pass 校验这些措施同样重要,但它们的共同点是——都必须在 Agent 之外完成,而不是 Agent 自己内部完成。
这个案例值得被单独拎出来,因为它把一个抽象的趋势线,变成了一条任何技术管理者都能立刻想象的画面:经验最浅的工程师,正在被最快的工具赋权去做经验最深的那部分决策——而栈里没有补位机制。这不是「年轻人变强」的故事,而是「决策权被外包给了一个没有边界的执行体」的故事。
三、塌方发生在哪里,而不是哪里
把这两个证据拼起来,塌方的轮廓比「慢」和「闯祸」要更具体。
塌方首先发生在「跨上下文推理」的位置。资深工程师的不可替代性,从来不在于「写代码更快」,而在于「读代码更快」。一个上线三年的微服务,哪里是入口、哪里有共享状态、哪里上次回归靠了某个不起眼的 workaround,这些信息没写在 README 里,也没写在注释里,它装在维护者的脑子里。AI 工具可以补全语法,但它拿不到那本脑子里的账本。METR 的 −19%,背后相当一部分时间就花在「AI 提交了一版看上去对的 diff,但开发者不得不逐行重建上下文验证」上。
塌方其次发生在「后果感知」的位置。一个工程师决定改一处类型签名,他知道这会牵动三个下游模块的缓存失效,他知道 release notes 里要标注,也知道凌晨两点那批日本用户的请求路径会变。Agent 在生成代码时,绝大多数情况下不携带这份「后果半径」的隐性知识。Kastra 那个 `DELETE FROM customers WHERE status='test'`,如果 agent 当时能感知到这条 SQL 一旦真跑会命中 800 万行生产数据,它大概率会换一种写法;问题不是它不会换,是它没有理由去换。
塌方也发生在「工程伦理」的位置。一个十年经验的工程师,看见自己写出的 SQL 是 `DELETE FROM`,会本能地加一条 `BEGIN TRANSACTION`,加一条 `SELECT COUNT(*)` 先验数量,加一个 `-- require manual confirm` 标签。AI 不具备这种「对自己的产出物感到不安」的能力——除非有人专门把它写到提示词里。这就是为什么 Kastra 的解法、Agents Remember 的解法、METR 在更新的实验方法里反复出现的关键词,都指向同一类东西:在 Agent 之外,补一层 deterministic 的、审计可追溯的、可被代码而非 prompt 表达的护栏。
四、人才结构正在换轨
上述三处塌方叠加在一起,改变的不是「程序员这个职业是否还存在」这个空泛的问题,而是「团队内部不同层级的人正在被分配到不同的位置」。
最显著的一个信号是初阶岗位的压缩。当一个 Agent 能在一个工作日内交付一个 CRUD 模块的 80% 代码,初阶工程师过去赖以建立判断力的「写代码」这件事本身,被部分外包了。结果不是初阶工程师失业,而是初阶岗位被进一步压扁:过去需要两年才能达到的「能稳定独立交付中等复杂度模块」的能力线,被工具压缩到了几个月;与此同时,「判断代码该不该写、哪里该写、写了之后会发生什么」这种原本在初阶阶段慢慢长出来的东西,也被工具直接绕过了。
第二个信号是资深岗位的重新定价。资深工程师的价值,正在从「写得快」转向「看得准、兜得住」。他们要做的不是和 Agent 一起写,而是给 Agent 设定边界、审阅产物、为后果兜底。METR 研究里那批被测的资深开发者,如果他们同时也是「边界制定者」和「审阅者」,他们使用 AI 的速度差异会比初阶团队小得多——因为他们的瓶颈本来就不在「写」上。真正变贵的,是「看得准」这一项:谁能更快从一份 AI 输出里看出那条 `DELETE` 即将落地,谁就值钱。
第三个信号是一种新岗位正在浮现。Agents Remember 这个 2026 年 6 月出现在 HN 上的开源项目,给出了它的雏形。作者把它的核心抽象叫做「agent operating context」,而不是「AI memory」:它不是把对话历史塞进 prompt,而是用 Git-aware 的方式维护一份与代码库镜像对齐的 Markdown 知识库,每次代码 commit,都伴随一次对应的 memory commit;每一次对项目结构的概述,都有脚本生成的索引文件做 staleness detection。换句话说,这份工作把「资深工程师脑子里那本账本」第一次显式地、可版本化地、可以交给 Agent 检索的形态,变成了代码仓库的一部分。这种工作的承担者,既不是纯粹的写代码者,也不是纯粹的提示词编写者,他同时懂代码、懂工程流程、懂如何把人类经验结构化成 Agent 能消费的形式——一种 2024 年并不存在的岗位。
把这三个信号拼在一起,人才结构的变化就不是「金字塔变橄榄球」这么简单,而是金字塔本身被切成两层:上层是「看得准」的资深工程师与新生的 context 工程师,中间开始出现一个被压缩得很薄的初阶层,Agent 横切所有层提供「写得快」的杠杆,真正决定产出上限的是那层 deterministic 的护栏——也就是 policy、auth、memory、review 这一整套栈。
五、这不是反对 Coding Agent,而是反对「用 Coding Agent 的方式」
如果一篇文章只停在「AI 让工程师变慢了」「Agent 会闯祸」,它的价值接近零。更值得回答的问题是:在已经回不去的世界里,正确的姿态是什么?
Kastra 的答案集中在运行时授权层:把「Agent 能不能调用这条工具、能不能命中这个目标、能不能带上这组参数」从 prompt 里搬到 deterministic policy 里,每一次决策都被审计日志记录。Agents Remember 的答案集中在记忆与上下文层:把人类经验沉淀为可版本化、可失效检测、可随代码 commit 同步演进的 Markdown 知识库,而不是写在 prompt 里的临时上下文。METR 在更新的实验方法里,把测量目标从「写得多快」改成「端到端任务在受控环境里是否按预期完成」。
这三个方向合并起来,可以提炼出三条工程化原则:
第一,任何 Agent 能触达的破坏半径,必须由代码而非 prompt 定义。这意味着删除、修改、对外发起请求、读取敏感凭据这一类动作,必须有一个可在版本控制里 review 的清单,而不是一段写在 system prompt 里的「请你谨慎行事」。
第二,Agent 赖以工作的「上下文」,必须可观测、可回滚、可对账。意味着它必须被持久化在仓库或配置系统里,而不是只活在 IDE 的 session 里——否则下一位工程师接手的时候,会发现他们面对的是一个「看起来在跑,但没有任何人知道为什么」的 Agent。
第三,真正的产出度量,要在端到端任务上做,而不是在局部代码片段上做。意味着 PR 数、commit 数、tab 补全的接受率,这些表面度量在 2025 年到 2026 年的现实里,正在被证明是误导性的;真正能反映一个团队工程能力的,是上线后回归率、生产事故数、跨周仍能被维护的代码比例。
把这三条写进团队章程,本身就是一种组织层面对塌方的兜底;反过来,任何一条缺失,塌方就只是时间问题。
六、回到那张人才结构图
Coding Agent 不会消失。把它的存在当作问题来反对,等于对着潮汐争论。把它当作单纯的效率工具来拥抱,等于把决策权悄悄外包给一个没有后果感知的执行体。
塌方之所以是「系统性的」,是因为它同时压在三个维度上:个体的工程判断在退化,团队的初阶岗位在被压扁,组织层缺失把 Agent 框住的 deterministic 层。这三个维度彼此放大,任何一个单独看都不致命,合起来就是一个组织技术债的指数曲线。
负责任的应对方式,不是撤回 AI,而是把已经漏出去的三层护栏补回来——运行时授权、上下文治理、端到端度量——并在此基础上重新校准人才结构:让资深工程师回到「看得准、兜得住」的位置,让初阶工程师在护栏之内有足够大的练习空间去长出真正的判断,让一种既懂代码又懂经验结构化的新岗位,在工具链上占据它应有的位置。
这才是一份在 2026 年仍然成立的工程文化:不是问「AI 能让谁变快」,而是问「在 AI 已经无处不在之后,我们仍然愿意为自己写的每一行代码负多大责任」。
---
信源:
- METR. Measuring the Impact of AI on Experienced Open-Source Developer Productivity. 2025-07-10. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR. We are changing our developer productivity experiment design. 2026-02-24. https://metr.org/blog/2026-02-24-uplift-update/
- Kastra Labs. Show HN: Runtime authorization for Claude Code, Cursor, and Codex. HN, 2026-07-09. https://kastra.ai/
- Foxfire1st. Show HN: Agents Remember — Git-aware memory for coding agents. HN, 2026-06-05. https://github.com/Foxfire1st/agents-remember-md
