原来的敏捷模型里，stakeholder（提出需求的一方，比如产品经理或业务负责人）描述需求，开发者写代码。反馈循环在两组人之间转：站会、sprint review、回顾会议，都为了让两边保持对齐。

现在这个循环里嵌套了一个新循环：人告诉 AI agent 写什么，agent 产出代码，人审查结果。原来的 stakeholder-author 循环还在，但 author 这边的角色从"作者"变成了"编辑"。你不是在写代码，你是在审查别人写的代码，确保它符合意图。

敏捷一直强调同步点：站会、sprint review、PR review。这些节点让大家停下来看看做了什么、接下来做什么。变化太快的时候，人容易跟不上节奏，同步点就是为了让大家重新对齐。

问题是 AI 让变化速度暴增。一个 agent 能在几分钟内产出一个上千行的 diff。如果你让这个 diff 作为一个 PR 提交，等于你安排了一个议程上有一百个议题的会议。没人能同时处理这么多内容。结果是审查者会简单浏览一遍，看懂大概 5%，剩下的凭信任通过。

作者给了一个实用的判断标准：一个 PR 的大小，应该是你愿意在一次会议里讨论的量。如果审查者没法把整个变更的资料装进脑子里，这个 PR 就太大了。

作者从其他团队听到一个普遍现象：PR 提交得太快了，人类根本来不及认真审。AI 生成、人类盖章、循环往复。审查步骤变成了形式。

AI 审查工具越来越强，但 Evan Phoenix 仍然坚持人类审查。原因在于审查本身是一个同步点：它强制团队对"做了什么"和"为什么这么做"形成共识。软件从来不是一个人的事，即使代码是一个人写的，它也活在一个系统里，由一个团队维护，服务的是不在房间里的用户。审查的真正价值在于建立共享理解，抓 bug 只是附带效果。

作者分享了一个个人经验：他能舒适地管理大约三个并行 AI agent。超过这个数，他就开始搞混哪个 agent 在做什么、每块工作到什么状态了、不同 agent 的产出有没有冲突。这使他变得焦虑，决策质量下降。

有人把同时管理二十五个 agent 当成目标来追求。作者认为这不可持续。人能同时有效指挥的并发工作量有上限，无视这个上限只会让你变成瓶颈，而你自己还浑然不觉。

还有一个相关的问题很少有人问：往一个问题上砸两千美元的 token 费用来让 agent 迭代出一个方案，值得吗？产出多不等于价值大，忙了一天可能没什么价值。

因为 AI 可以全天候工作，有一种越来越常见的观点是人应该跟着 AI 的节奏走。省下来的时间应该填上更多工作。如果工具让你快了五倍，你应该产出五倍的东西。

作者认为应该抵制这种想法。更好的工具应该带来更好的结果，而不是更多的工时。敏捷宣言原文专门提到这一点："敏捷过程提倡可持续开发。赞助者、开发者和用户应该能够无限期地保持恒定的节奏。"关键词是"无限期"。不是"撑到下个 sprint"，不是"撑到上线"。

作者分享了自己的节奏规律：把精力放在百分之七八十的水平，他可以保持状态。如果某件事要求他跳到百分之百的水平，他大概能撑两周，然后会陷入崩溃，需要几周恢复到可持续的基线。

AI 工具的危险在于，它让全速运转的节奏感觉上是可持续的，直到你发现不是。工作推进得很快，快到你觉得自己还撑得住，直到突然崩溃。指挥 AI 工作带来的认知负荷跟以前不一样，你得同时跟踪多条并行的生成任务。"机器不睡觉所以人也不该睡"这种文化，只是加班文化的另一个翻版。

Evan Phoenix 所在的 Miren 团队有四条日常实践：

1. 先定义"完成"再动手 。每个任务对应一个 issue，哪怕只有一句话。写清楚这个变更要做什么，给工作一个锚点：知道什么时候做完了，也知道什么时候该停。
2. 工作粒度要对 。一个 PR 应该是你愿意在一次会议里讨论的大小，有实质内容但连贯。
3. 审查不可妥协 。每个变更都要过人类眼睛，当作协作节点，不是关卡。
4. 节奏优先于产出 。问一下我们自己：我们能以什么样的工作节奏持续一个月？如果今天的工作中午就做完了，今天就结束了。

敏捷的原则没有过期。沟通循环、共享上下文、可持续节奏、合适的工作粒度，这些原则仍然有效。只是现在循环里有一个永远不会累的参与者，而我们自己会累。