敏捷不够用了：在 agent 速度下开发软件
几周内，作者的独立开源项目积累了 100+ 个开放 issue；与此同时，一个 AI agent 团队产 PR 的速度比他认真评审的速度还快。"我自动化了实现，但没有自动化交付。我提高了系统错误部分的容量。"——这让他意识到：agentic development 不是更快的敏捷，它改变了整个开发过程必须围绕其建立的瓶颈。
敏捷解决的是另一个问题
瀑布式开发让变更慢而贵。Scrum/Kanban/敏捷缩短了规划视野、减小了批量、让开发进行中能反应——这是必要的一步。但这些方法围绕以人类速度运转的人类团队长出来。实现曾是时间与容量的主要消耗者：一个 sprint 里团队只能实现这么多。规划、实现、评审、验收以大致兼容的速度运转。
Agent 打破了这个容量模型。人可以同时把几个 agent 派进同一代码库，或编排一个专职团队（规划、实现、测试、评审、返工）。执行可以并行、只要有活就继续。填满一个 sprint 的活在几小时内完成。sprint 积压可以在人还在评审第一批结果时就过时——节奏不再控制执行，完成的工作以连续流抵达。人的注意力不随之扩展。结果不只是更短的 sprint，是不同的生产系统：实现变得便宜而有弹性，而意图、判断、评审、责任保持稀缺。Scrum 不为这种情况设计。
系统的失控方式
作者搭建了 agent 编排工具，工作流：人提交 issue → agent 团队实现、开 PR、评审返工 → 人批准合并。它工作了，然后速度糊了他一脸。更多输出不等于更多交付：功能实现太快，他跟不上评审。再加 agent 只是让队列更长。人是瓶颈——不是要消除的问题，人仍拥有产品、决策与后果。但流程一直在优化 agent 输出，即使被接受的变更受限于人的评审容量。更多 agent 吞吐产生的是等待人判断的库存，不是交付。
规划端同样崩了：用 LLM 讨论想法、规划特性、拆解工作、识别后续任务——agent 实现一个 issue 的同时能发现几个并立即归档。创建 issue 很便宜，于是几乎所有合理观察都变成一条。几周后 100+ 开放 issue。每个 issue 单独看都有用，合起来不再是能监督的计划——积压变成了规划与实现的尾气。 创建 issue 便宜，拥有它不免费：仍要有人理解它、与其他比较、判断是否重要、保持上下文新鲜、最终接受或拒绝。Agent 把两边都变快了：产出软件，和产出对更多软件的需求。中间的人没有变。
为什么更短周期不是答案
限制列上的 WIP 不回答新问题：agent 可以把发现变成承诺的工作吗？agent 被允许开始前必须知道什么？怎么防止 agent 干活时扩大范围？人类评审前它必须产出什么证据？它能有多少自主而不获得权威？控制流的是 agent 执行还是人的验证容量？危险不是 agent 完不成模糊 issue，而是它能完成——把模糊请求变成令人信服的代码，却从未解决其背后的歧义。
可用的方法
任何人都可以捕获，只有人能承诺：想法/缺陷/风险随时可捕获（记录观察、位置、为何可能重要、足够上下文）。它还不是实现 issue，没有里程碑/估算/详细规格，可能被合并、重写、丢弃、过期。agent 必须被允许注意到东西而不获得扩展产品的权威。承诺不同：人明确把一个捕获拉进承诺工作——那不只是请 agent 实现，是分配规格、评审、接受所需的注意力。Agent 可以提议工作，不能自己承诺。
承诺的工作需要可执行规格：至少含预期结果与原因、相关上下文、范围与明确非目标、技术与产品约束、验收标准、所需测试或证据、已知风险。"改进错误处理"不可执行——没说哪个失败、行为怎么变、谁能证明完成。agent 快到歧义几乎立即变代码，准备比以前更重要，不是更不重要。
执行受验证容量限制：关键问题不再是 agent 能并行执行多少 issue，而是人能理解评估多少完成变更而不失去控制。承诺工作按下游评审容量限制。agent 不该因为有执行槽空闲就开始下一个 issue，而应存在通过评审验收的现实路径时开始。让 agent 闲置是有意的——闲置的 agent 比没人能好好评审的 PR 便宜。
发现不扩展活动范围：agent 干活时发现的邻近问题（缺校验、弱抽象、过期文档）记录为捕获，而不是当场实施——否则 scope 无限膨胀。
实践建议
把开发流程从"sprint 容量"改到"验证容量"：捕获与承诺分离、可执行规格成为 agent 开工门槛、按评审容量限并发、发现一律进捕获池。这是与"更快 Scrum"不同的运行模型——它把稀缺的东西（人的意图、判断、评审、责任）放回控制位。
来源：When Agile Is Not Enough: Developing Software at Agent Speed - DEV Community