1周半写64个PR、完成30%项目重构：一家成熟SaaS公司把Agent塞进研发全流程后

作者 | Jackie Calapristi 编译 | 蔡芳芳 编者按： 当 AI 编程工具从“帮工程师写代码”进一步走向能够自主规划、实现、测试和排查问题的 Agent，软件工程真正发生的变化，可能已经不只是“写代码更快了”。Calendly 最近公开了其内部正在运行的一套 Agentic Engineering 实践：Agent 会先审查 Jira 需求、拆解任务，再并行写代码、跑测试、做 QA，最终由人类完成 Review 和 Merge；在 IAM 团队，仅一周半时间，Agent 就生成了 64 个 PR，完成了一个大型解耦项目约 30% 的工作。更值得关注的是，随着执行能力被进一步自动化，Calendly 发现工程研发的瓶颈再次发生了转移——从写代码，到需求对齐，再到如今的“判断力”。Calendly 是一家成立于 2013 年的日程安排 SaaS 公司，核心产品通过连接用户日历，自动处理会议时间协调、预约和工作流等问题，被大量企业和个人用于销售、招聘、客户服务等场景。正因为它本身是一家拥有成熟产品、工程体系和生产环境的 SaaS 公司，Calendly 团队这次分享的 Agentic Engineering 实践，比单纯展示“AI 能写多少代码”更值得关注：他们讨论的是，当 Agent 真正进入一家成熟软件公司的 Jira、GitHub、CI 乃至生产运维体系之后，研发流程究竟会发生什么变化。当代码越来越便宜，什么值得做、任务该如何定义、哪些工作可以交给 Agent、哪里必须由人接管，反而成为更稀缺的工程能力。这篇文章没有停留在“Agent 能不能写代码”的讨论上，而是给出了一家公司真正把 Agent 塞进研发生产流程之后，工程组织正在发生什么变化。以下是全文翻译： 引言 几个月前，我曾写过 Calendly 工程团队正在发生的一种转变：AI 编程助手每周都能为工程师节省数小时，而这些省下来的时间正在被投入到更好的产品思考、更快的验证，以及与产品和设计团队更紧密的协作中。我们把这种模式称为 Product-first Engineering（产品优先工程），它背后的逻辑很简单：随着代码的生产成本越来越低，价值会逐渐转移到那些更难自动化的事情上——理解问题、进行权衡，以及真正把正确的东西做出来。第一波变化，包括减少样板代码、更快制作原型、更快完成验证，如今已经成为许多工程师默认的工作方式。但现在，情况又发生了变化。我们讨论的已经不再只是个人如何使用 AI 加快工作速度，而是开始真正把 Agent 嵌入工程研发工作流，让它们充当规划者、实现者、审查者和问题调查者，直接接入我们原本就在使用的软件交付系统。这篇文章要讨论的，就是这一切在真实实践中究竟是什么样子，而不是停留在理论层面：Agent 应该放在哪些环节？它们实际上承担并自动化了哪些工作？它们运行在哪些系统里？同样重要的是，哪些地方必须始终让人参与其中？事实上，人的参与现在比以往任何时候都更加重要，而且在可预见的未来都不会消失。 重新应用 Calendly 的「摩擦消除模型」 Calendly 最初的产品洞察就是消除摩擦。过去安排一次会议，通常意味着双方反复提出可选时间、查看日历，然后在一串“回复所有人”的邮件中来回沟通。我们打造了一款产品，把这些摩擦消除掉，让协调一次会议的成本几乎降到零。现在，我们开始对自己的工程研发流程提出同样的问题：从一个想法，到最终得到经过验证、真正可以工作的软件，这中间存在多少协调成本？其中又有多少可以被消除？两者之间的对应关系非常直接。对于用户而言，Calendly 降低的是最终安排好一场会议的协调成本；对于我们的工程团队来说，Agentic 系统正在降低从一个已经定义清楚的问题，到一个经过验证的实现方案之间的协调成本。我们现在希望消除想法、需求、实现、评审和最终可运行代码之间的所有摩擦。 我们并不是为了自动化而自动化，我们的目标是自动化那些重复性高、严重依赖上下文、又容易造成等待和延迟的工作，让优秀的人才能够把更多时间投入到真正能够创造价值的地方：判断、权衡、架构、产品思考以及用户体验。这个出发点非常重要，因为它决定了后面所有安全护栏应该如何设计。 当 AI 从「工具」变成「工作流」，发生了什么变化？ 我们有必要准确解释一下 Calendly 所说的 Agentic Engineering 究竟是什么，因为这个词现在在整个行业里已经被用得非常宽泛。 从实践层面来看，工程师和团队首先定义目标、约束条件、上下文、验收标准和安全检查机制，然后，Agent 会进入人类原本使用的同一套系统，推动这些工作以一种摩擦更少、自动化程度更高的方式继续向前执行。执行过程发生在一套能够限定范围、接受审计、接受评审，并随着时间不断改进的系统中，而不是存在于一个会话结束就消失的聊天窗口里。 同样重要的是，我们必须明确 Agentic Engineering 不是什么。它不是“AI 把所有代码都写了”，不是不受限制的自主运行，也不是用 AI 替代真正的工程责任。任何一个名字出现在 Agent 辅助完成的工作上的工程师，仍然必须对这项工作负责，没有例外。 我们的核心判断是：真正发生的变化，不只是代码生成得更快了，而是我们开始拥有一个更加自动化的工程闭环，这个闭环拥有持久状态，并且在真正关键的节点内置了人工检查点。 Calendly 的 Agentic Engineering 闭环内部是什么样的？ 新的工程闭环 Calendly 内部已经有多个团队各自独立探索，但最终逐渐形成了非常相似的工程闭环。通常情况下，团队会从一份 one-pager 或 Jira Ticket 开始，其中定义问题、约束条件、验收标准和已知风险。在任何代码真正被写出来之前，一个 Agent 会先审查这个 Ticket，寻找其中存在的歧义、遗漏的边界情况或缺失的实现细节。然后，一个规划 Agent（Planner Agent） 会把已经批准的工作拆解成适合单个 PR 大小的任务。接下来，实现 Agent（Implementer Agent）会执行这些已经明确限定范围的任务，而且通常可以并行执行，运行在彼此隔离的 Worktree 或自托管 Worker 中。之后，一个 QA Agent 或 Reviewer Agent 会根据需求、测试套件以及 Repository 级别的指令验证输出。只有到了这一步，人才会进行最终的 Review、Approve 和 Merge，并决定哪些东西真正安全，可以发布到生产环境。这些工作并不存在于某一个临时聊天会话里：Jira 保存需求，GitHub 保存代码评审和修改历史，CI 保存验证结果，Repository 指令和共享规则保存 Agent 必须遵守的行为约束。所以，这是一套拥有持久记忆的闭环系统，而不是一个聪明的 Prompt。 Calendly 不同工程团队已经在如何使用自动化？ 这并不是某种假想的未来状态。不同形式的 Agentic 工作流已经在整个 Calendly 组织内部真实运行。 CalTown：扩大「能够真正交付代码的人」的范围 Agentic 工作流改变工作方式最清晰的案例之一来自我自己的团队——Con