不，那不是软件工厂 —— Ryan Cooke (WorkOS)
원제 · No, That's Not a Software Factory — Ryan Cooke, WorkOS
핵심 요약
软件工厂的真正价值并非提高代码 PR 生成数量，而是通过将 Linear 依赖关系、需求文档管理和内部 MCP 网关编排进自动化流程，实现端到端的功能快速交付。
하이라이트
评估软件工厂成效的指标应从 Pull Request 数量与合并率等产出数据，转向功能交付速度等成果指标。
WorkOS 建立由 TARS 与 Horizon 构成的自动化架构，将 Linear 工单依赖关系与 GitHub 流程直接接入 AI 智能体。
TARS 通过分析需求文档初稿与 Linear 阻塞工单，自主按顺序执行项目拆解与跨任务调度。
内部上下文引擎扮演 MCP 网关角色，对 Snowflake 数据湖的语义表与组织信息进行统一抽象并暴露给智能体。
通过在 Slack 与共享频道中嵌入 AI 智能体，TARS 能够直接分析项目代码并自动分诊客户支持请求及 Bug。
타임라인
软件工厂评估维度的转变
业内普遍采用在 Cloudflare 等沙箱环境中部署 Open Code 或 Cloud Code 智能体来自动提交代码修改。这种模式容易陷入追求 PR 合并数量的误区，难以区分代码量的增加是否真正推动了业务进展。将衡量标准转向功能构建效率，才能确保投入专职工程团队研发的自动化系统带来实质回报。
- 生成式 AI 推动了沙箱加智能体自动产出 PR 的标准配置。
- PR 总数量与代码生成量等产出指标会掩盖软件工厂的实际效能。
- 工程组织应以功能交付速度和成果质量来定义软件自动化成果。
TARS 与 Horizon 架构体系
单纯为工程师提供沙箱并不能形成线性或指数级的产出增长，关键在于将日常工程流程直接嵌入工厂。WorkOS 搭建了双层架构：TARS 作为交互终端接收各类工具的 Webhook 回调，负责监控工单状态与评估缺失任务；Horizon 则作为基础设施编排层协调底层运行环境。这种设计使智能体能够在上游任务完成后自动接手依赖工单，完成产品规划的自主推进。
- 仅在沙箱中运行模型无法带来超越本地开发的生产力提升。
- TARS 负责对接 Slack、Linear 及 GitHub 的 Webhook 信号并追踪进度。
- Horizon 构成了基础设施编排层，并置于 MCP 网关前端。
- 智能体通过读取工单阻塞关系自主顺序执行规划路线图。
产品工程流程的文档与任务拆解
在无专职产品经理的组织架构中，工程师需承担需求定义职责。通过将规范文档（山顶文档）格式标准化，PM 智能体可根据简短描述自动生成包含竞争分析、设计界面和里程碑的草稿，解决了工程人员面对空白页的写作阻碍。文档经审查批准后，系统会自动触发后续的工单拆解与代码构建，人类工程师仅需对超出范围的预估进行裁剪与微调。
- 专门的 PM 智能体负责生成需求文档初稿并整理上下文。
- 通过简单文本描述即可自动创建 Linear 项目与 Notion 决策日志。
- 人类工程师在流程节点中参与评审并修正智能体设定的项目范围。
基于 MCP 网关的统一上下文引擎
WorkOS 建立了名为上下文引擎的内部 MCP 网关，将内部工具、 Snowflake 数据湖中的客户对话与使用率表格进行抽象描述。智能体可依据这些工具描述自动编写 SQL 查询。该网关随后被推广至非工程团队，员工可直接在 Slack 中进行数据分析，成为了全公司共享的技术杠杆。
- 上下文引擎将 Snowflake 数据湖映射为可供智能体使用的语义表工具。
- 统一的 MCP 服务器在支持编码智能体之外，扩展至 Slack 内部查询。
- 搭建专有 MCP 网关能显著提升跨系统数据的调用杠杆效率。
自动化演进与系统自我完善
除代码生成外，系统通过 Webhook 监测 Slack 中的 Bug 汇报与客户支持请求，利用代码库理解能力完成初筛与修复提案。为了实现自动化基础设施的自愈与自增，团队逐步转向自主掌控沙箱与内存层，利用全量上下文追踪工程师的编码行为。系统借此识别能力短板，自动更新因代码库演进而失效的技能模块。
- TARS 承担了第一轮错误分诊与共享频道客服支持响应。
- 自建沙箱基础设施能够提供深度的会话控制与上下文记忆。
- 通过分析智能体运行日志可动态更新与淘汰过时的开发技能。
설명
The standard software factory puts an agent in a sandbox, prompts it and merges the PR. When WorkOS built one, the results were hard to tell apart from engineers running Claude Code on their laptops. Ryan Cooke, an engineer at WorkOS, argues that counting PRs or lines of AI code is the wrong measure. What matters is outcomes: are you actually shipping more to customers? WorkOS's answer is to build its engineering process into the factory itself. TARS, its agent, lives in Slack, Linear and GitHub and uses webhooks to track projects and pick up the next ticket on its own. A PM agent drafts the "Hilltop" product doc and breaks approved work into tickets, which solves the blank-page problem. Horizon, the orchestration layer, sits in front of an internal MCP gateway that connects every tool, including Snowflake. Cooke calls that gateway the single best investment for any team starting a factory. He also covers bug and support triage, why WorkOS is building its own sandboxes and a company-wide memory layer, and how it measures success with defect rates, recovery time and adoption. Related links: WorkOS: https://workos.com Timestamps: 0:00 Intro: the standard software factory 1:17 Output metrics hide what's working 2:37 Measuring outcomes instead 3:12 Why a basic sandbox wasn't enough 4:07 TARS and Horizon 5:22 Webhooks: from code work to product work 6:32 Building the Hilltop doc into the factory 8:07 The PM agent 8:52 Demo: kicking off a project from Slack 10:17 Solving the blank-page problem 11:02 Works with Devin and Claude Code too 11:57 The MCP gateway: a context engine 13:37 Why every factory needs an MCP gateway 14:07 Bugs, support triage and our own sandboxes 15:27 Next: a company-wide memory layer 15:57 How we measure success 17:02 Owning the infrastructure to self-improve 18:02 Wrap-up