No, That's Not a Software Factory — Ryan Cooke, WorkOS

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