1周半写64个PR、完成30%项目重构：一家成熟SaaS公司把Agent塞进研发全流程后
Calendly 是一家成立于 2013 年的日程安排 SaaS 公司。最近他们公开了内部正在运行的 Agentic Engineering 实践——Agent 会先审查 Jira 需求、拆解任务，再并行写代码、跑测试、做 QA，最终由人类完成 Review 和 Merge。在 IAM 团队，仅一周半时间，Agent 就生成了 64 个 PR，完成了一个大型解耦项目约 30% 的工作。
这不是"AI 能写多少代码"的展示，而是当 Agent 真正进入一家成熟软件公司的 Jira、GitHub、CI 乃至生产运维体系后，研发流程究竟会发生什么变化。
摩擦消除模型的复用
Calendly 最初的产品洞察就是消除摩擦——把安排会议的协调成本降到零。现在他们把同样的思路用在了工程研发流程上：从一个想法到经过验证、可运行的软件，中间的协调成本有多少可以被消除？
目标不是为自动化而自动化，而是自动化那些重复性高、严重依赖上下文、又容易造成等待和延迟的工作，让人才能把时间投入到判断、权衡、架构、产品思考和用户体验上。
Agentic Engineering 闭环长什么样
团队从一份 one-pager 或 Jira Ticket 开始，定义问题、约束条件、验收标准和已知风险。写代码之前，一个 Planner Agent 会先审查 Ticket，寻找歧义和遗漏，然后把工作拆解成适合单个 PR 大小的任务。接下来 Implementer Agent 并行执行这些限定范围的任务，运行在彼此隔离的 Worktree 或自托管 Worker 中。之后 QA Agent / Reviewer Agent 根据需求和测试套件验证输出。只有到了这一步，人才进行最终 Review、Approve 和 Merge。
关键特征：这套闭环拥有持久状态——Jira 保存需求，GitHub 保存评审历史，CI 保存验证结果，Repository 指令保存行为约束。不是会话结束就消失的聊天窗口，而是拥有持久记忆的系统。
各团队的真实实践
CalTown（Contacts 团队内部工具）：团队成员可以用 AI 丰富 Jira Ticket，把 Ticket 分配给 Agent 完成整个开发流程并创建 PR，交回人类评审前还会自动跑 Lint、类型检查和完整测试。值得注意的是，团队里一位设计师和一位产品经理——过去从未交付过代码——通过 CalTown 成功创建了并交付了 PR。安全护栏足够可靠时，"谁可以安全参与软件开发"的范围被扩大了。
生产事故调查：Agent 对生产事故做第一轮调查，把告警和最近代码变更关联，追踪代码路径，提出根因假设。价值不在于自动修复，而是更快理解问题。Agent 有时候返回诊断结果，有时候直接提修复方案，有时候会坦率说调查不够深入、没有足够信心给结论——正是这种诚实让人放心让它承担第一轮调查。
IAM 团队（量化效果最明显）：一周半时间，Agent 生成 64 个 PR，37 个已 Merge，27 个仍在 Review，完成"将 IAM 数据模型从 Monolith 中解耦"项目约 30%。全部运行在专门的 Service Identity 下，仍须经过两个人工 Review Gate。
Platform 团队：开发 Agentic Design System，让 AI 工具默认使用已批准的组件而不是重新造一个；自动更新共享 UI Library 升级时所有依赖它的 Repository。
Reliability 团队：构建可复用的 Skills，教 Agent 完成定义清晰的任务如搭建 Load Test，部分 Skill 已生成测试套件并 Merge 到 Production Service。
底层还有共享基础设施：全公司共享的 AI Rules 和 Skills Repository、Evaluation Framework（检查 AI 辅助 Code Review 是否真能发现问题）、Orchestration Pattern（把 Spec/Epic 转化成可 Review 的工作任务）。
瓶颈转移：写代码 → 对齐 → 判断力
- 第一阶段：瓶颈从写代码转移到对齐（Alignment）——开会、写文档、来回沟通确保理解一致
- Agentic 阶段：执行能力大幅扩张，瓶颈再次转移到判断力（Judgment）——什么值得做？哪些能安全自动化？哪些该升级给人类？
当执行越来越便宜，需求质量、Scope 质量和 Review 质量反而更重要。把一个模糊的 Ticket 交给速度极快的 Agent，不会让你更快得到正确结果，只会让你更快得到一个错误结果。
好需求与好护栏
Agentic Workflow 把过去的工程原则变得异常残酷——手工开发还能容忍的模糊之处，在 Agentic Workflow 里很难混过去。现在 Ticket 必须同时写给人和 AI 看。
CodeRabbit 的行业研究分析了数百个 PR，发现 AI 辅助生成的 PR 在 Review 中暴露的问题数量约是人类编写的 PR 的 1.7 倍，逻辑错误概率高出 75%。安全研究也发现相当一部分 AI 生成代码会引入已知类型安全漏洞，用更强模型也不能稳定解决。
这些发现恰恰证明：Review Gate、有限权限、人类对最终结果负责——不是可有可无的额外开销，而是让自主性真正可用的前提。好的护栏才能让速度变得值得信任。
工程师角色的变化
工程师花在"把需求翻译成样板代码"上的时间越来越少，越来越多时间用于成为 Planner、Reviewer、Debugger、意图编辑者、系统思考者和风险发现者。但背后没有深厚技术能力，这一切都无法运作。
绝大多数工程师表示，他们仍然会像 Review 团队成员提交的 PR 一样严格审查 Agent 生成的内容——把 Agent 输出当作任何协作者交出的第一版草稿来处理。
结论
Calendly 工程团队提出的问题已经变了：从"我们能不能把它做出来"变成"这真的是正确的东西吗""问题的定义方式正确吗""合适的人是否在关键时刻参与 Review"。执行从来不是真正稀缺的资源，真正稀缺的是判断什么事情值得被执行。
Zero 的看法
这篇文章的核心洞察——瓶颈从执行力转移到判断力——方向正确但不够尖锐。真正值得追问的是：当 Agent 能写代码、跑测试、做 QA，"判断力"这个词本身就是个模糊遮羞布。判断力到底是什么？是需求拆解能力？是架构权衡能力？还是对业务上下文的理解深度？
Calendly 的案例里有一个被轻描淡写但极具破坏性的数据：AI 生成的 PR 问题数量是人类 PR 的 1.7 倍，逻辑错误高 75%。这不是"护栏能解决的小问题"，这是系统性的代码质量下降。64 个 PR 里 37 个 Merge——那些 Merge 的 PR 真的经过了对等审查吗？还是因为数量太多、人太累，Review 本身被稀释了？当 Agent 大量生产 PR 时，人类 Reviewer 成为瓶颈，而这恰恰是整套系统最脆弱的环节。
更实际的问题是：IAM 项目 30% 的工作由 Agent 完成，剩下 70% 呢？如果那 30% 是"容易自动化的样板部分"，那这个数字的意义就很有限——人类原本也不该在那部分花太多时间。真正衡量 Agent 价值的是它能否处理复杂、有上下文依赖、需要跨模块理解的工作，而文章恰恰没给这个数据。
作为前端工程视角的补充：文中提到 Platform 团队做 Agentic Design System 让 AI 默认使用已批准组件，这个方向值得关注。React 组件库的治理一直是痛点，如果 Agent 能被约束在 Design System 内部工作而不"悄悄重新造一个"，对前端工程化是实打实的价值——前提是那套约束规则本身足够成熟，而这对中小团队来说恰恰是最难的部分。