瓶颈已转移：当代理编写代码时，技术团队如何保持快速

编码不再是缓慢的步骤。在四场最近的讲座中，同样的模式出现：代理可以快速起草更改，然后团队卡在质量、审查、信任和验证上。

这与自动化整个公司的论点不同，也与单个编码产品内的单一验证循环不同。它关乎一旦代理已经在编写大部分 diff 时，团队如何保持快速。

时间实际花在哪里

无人值守的代理会随时间让代码库变差。 Dexter Horthy 在 Beyond Coding 以及再次在 Agentic AI Foundation 上，走过了 SlopCodeBench：模型得到一个 greenfield 应用，然后是一系列功能，没有预先给出整个问题。失败的测试攀升。最好的模型仍然得分在十几分。他的警告是实用的：不要把代码库押在明年模型会清理它的希望上。瞄准 2-4 倍，而不是 100 倍。并行做更少的事情，并对任何改变架构的事情在研究-设计-计划循环中保留人类。

审查过程往往比模型更慢。 Amp 的 Dario Hamidi 也在 Beyond Coding 上说，团队每天大约部署到生产 50 次，使这成为可能的改变不是代理。它是放弃拉取请求和功能分支。他论证即使不使用 AI 的团队也可以通过合并到 trunk 获得两位数的生产力提升，因为人们然后检查自己的工作，而不是在为陌生人建造的队列中等待。匹配的约束是信任：构建代理无法「玩刀」的环境，使用短期凭证和你实际会批准的权限。

验证不会随生成扩展。 IBM 的 Prompt to Production 用一句话概括了新瓶颈：AI 规模下的人类验证。规划、影响和证据比第一行代码更重要，因为真正的更改也会触及测试、配置、流水线和监控。相关的 IBM 关于 IDE vs CLI 的文章从工具链侧提出了同样的观点：摩擦是协调代码周围的工作，而不是输入它。

规格和评估是团队接口。 Guillermo Rauch 在 David Ondrej 的采访中描述了一个建立在尝试许多模型、个人和公司评估，以及能从简短指令审查应用或交付函数的代理之上的代理工作流。对团队有用的部分不是名人设置。它是一个共享评估，这样「本周哪个模型」不会变成私人争论。

周一该改变什么

拆分工作。小的、可逆的更改可以交给后台代理。任何改变抽象的事情留在有人类的研究-设计-计划通道中。
停止用 token 或并行代理衡量速度。衡量没有引发事故的部署，并保持一个优先级在飞行中。
把审查左移。自动检查和可信环境击败长 PR 队列。如果你放弃拉取请求，说明什么取代它们：trunk、测试，以及仍然阅读 diff 的人。
写代理能看到的反垃圾规则：你不会合并的模式，以及用户反馈重新进入工厂的地方。
把验证当作稀缺资源。在要求代理实现之前计划证据（测试、标志、简短手动检查）。