# No, That's Not a Software Factory

Ryan Cooke, WorkOS | AI Engineer | 19:00

Source: https://www.youtube.com/watch?v=HvboD89DyQ8
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/no-thats-not-a-software-factory
Published: 2026-09-27
Tags: agents, coding-agents, mcp, software-factories

## TL;DR
- WorkOS found that a sandboxed coding agent produced results that were hard to distinguish from engineers using Claude Code on their laptops.
- TARS connects Slack, Linear, and GitHub so it can follow product work, create resources, pick up dependent tickets, and revise plans as it learns.
- WorkOS measures the factory through customer delivery, defect rate, recovery time, and engineer adoption instead of counting pull requests or lines of generated code.

## Summary
Ryan Cooke argues that a software factory should automate the product engineering process around code, rather than simply place an agent in a sandbox and merge its pull requests. WorkOS first built that basic setup and found little difference from engineers running Claude Code locally. Its revised system combines TARS, which interacts through Slack, Linear, and GitHub, with Horizon, an orchestration layer in front of an internal MCP gateway. TARS can create project documents, break approved work into tickets, follow dependencies, triage bugs and support requests, and use webhooks to continue work without someone directing every step. A PM agent drafts WorkOS's Hilltop product document to solve the blank-page problem. Cooke recommends building an MCP gateway early because it gives agents descriptions and context for internal tools such as Snowflake. WorkOS plans to own more sandbox infrastructure and build a company-wide memory layer. It judges success through customer impact, delivery speed, defects, recovery time, and whether engineers choose to use the system.

## Key ideas
### Counting pull requests can hide whether the factory helps customers
[01:18](https://www.youtube.com/watch?v=HvboD89DyQ8&t=78s)
Cooke says software factory discussions often focus on the percentage or number of pull requests produced by AI and the amount of generated code reaching production. Those figures can rise while the underlying results remain unclear. WorkOS therefore asks whether engineering can deliver features faster, build more complex work in less time, and ship more to customers. The intended effect is that each engineer gets something like a small engineering team. The factory has to improve the organization's outcomes, not simply increase its code output.

### A basic coding sandbox was no better than local agent use
[03:12](https://www.youtube.com/watch?v=HvboD89DyQ8&t=192s)
WorkOS began with a setup similar to other factories: a Cloudflare-based sandbox, an OpenCode model router, and prompts that led to pull requests. Cooke says the result did not create an incremental or exponential improvement over engineers running Claude Code on their laptops. That finding changed the project's direction. WorkOS started embedding its engineering processes into the factory so it could automate the planning and product work around implementation, rather than only produce code.

### TARS uses project events to continue work without constant supervision
[04:07](https://www.youtube.com/watch?v=HvboD89DyQ8&t=247s)
TARS is the user-facing system for WorkOS's coding agent, and it is embedded in Slack, Linear, and GitHub. Webhooks let it track project progress as well as code output. When Linear tickets have dependencies, TARS can see that one ticket is complete and pick up the next one in the cycle. It can also reevaluate the project after a ticket is finished and suggest missing tickets. Horizon handles infrastructure orchestration and sits in front of the MCP gateway.

### The Hilltop document gives the factory a product plan to execute
[06:32](https://www.youtube.com/watch?v=HvboD89DyQ8&t=392s)
WorkOS engineers write a Hilltop document that describes a project's purpose, customer needs, competitive context, early design screens, and major milestones. The company can give that document to an agent, which breaks it into units of work. Once the document is reviewed and approved, TARS can start the project without a person shepherding every stage. A PM agent writes the first Hilltop draft from a brief, adds context from human reviews, and turns the approved work into tickets. Humans can still comment on and refine each generated resource.

### Starting from an imperfect draft is easier than facing a blank document
[10:17](https://www.youtube.com/watch?v=HvboD89DyQ8&t=617s)
From Slack, a WorkOS engineer can describe a project in a few sentences and ask TARS to create the Linear project, a draft document, decision logs, open questions, and initial milestones. The lead engineer then fills in missing details and removes scope that the agent has overestimated. Cooke says this gives engineers something concrete to edit instead of requiring them to create every planning primitive from scratch. The resulting documentation can also provide context to Devin, Claude Code, or engineers working in local tools.

### An internal MCP gateway gives agents instructions for using company data
[11:57](https://www.youtube.com/watch?v=HvboD89DyQ8&t=717s)
WorkOS's MCP gateway, called its context engine, connects internal systems and supplies descriptions of how to use them. It connects to Snowflake, including semantic tables describing product use and customer conversations. Tool descriptions tell an agent which tables contain particular information and how to query them. WorkOS also lets people query the gateway from Slack for data and customer analysis. Cooke recommends this investment to teams starting a factory because the gateway can support many internal uses beyond connecting a coding agent to company systems.

### The factory also handles bugs, support work, and its own infrastructure
[14:07](https://www.youtube.com/watch?v=HvboD89DyQ8&t=847s)
TARS listens for bug reports in Slack, makes an initial triage, and can open pull requests to fix issues. In customer-shared Slack channels, it can inspect the code and help triage support requests. WorkOS is also using TARS to build its own sandbox infrastructure instead of depending entirely on sandboxes as a service. The company wants deeper control over session information and the ability to move workloads across its infrastructure.

### WorkOS plans a company-wide memory layer and measures adoption
[15:27](https://www.youtube.com/watch?v=HvboD89DyQ8&t=927s)
The planned memory layer would keep current context about people, teams, products, and how WorkOS works as an organization. The company wants to use that context in the factory and in other AI tools. Its measures include customer delivery, defect rate, and time to recovery. Engineer adoption is another signal: WorkOS wants engineers to choose TARS and move from local harnesses into cloud sandboxes when those provide value. Owning the infrastructure lets the team inspect sessions, find agent mistakes, update skills, and remove skills that have become obsolete.

## Notable quotes
- "It was actually pretty indistinguishable for us." (03:39)
- "We actually want it to take a lot of the other work that our engineers do to produce products and automate that as well." (03:41)
- "If you're just getting started with thinking about a software factory, it's well worth your time to invest in an internal MCP gateway server." (13:40)
- "We think about our software engineering practices and processes and we want to encode those in automation." (18:13)

## Tools & references mentioned
- WorkOS
- Ryan Cooke
- TARS
- Horizon
- Claude Code
- OpenCode
- Devin
- Linear
- GitHub
- Slack
- Snowflake
- Cloudflare
- MCP

## Who should watch
- You are building an agent sandbox and need a way to tell whether it improves customer delivery rather than simply increasing pull requests.
- Your engineering process includes planning documents, ticket dependencies, support requests, or other work that coding agents currently do not see.
- You want practical guidance on connecting agents to internal systems, especially through an MCP gateway and shared company context.

## Related talks

- [Building your own software factory](https://aietalks.com/talks/building-your-own-software-factory) (Eric Zakariasson, Cursor, 1:23:37)
- [Software Engineering Is Becoming Factory Engineering](https://aietalks.com/talks/software-engineering-is-becoming-factory-engineering) (Zach Lloyd, Warp, 20:37)
- [What It Actually Takes to Build a Software Factory](https://aietalks.com/talks/what-it-actually-takes-to-build-a-software-factory) (Tereza Tížková, Factory, 22:49)
- [Orchestras, Not Factories: How the Fastest Builders Work](https://aietalks.com/talks/orchestras-not-factories-how-the-fastest-builders-work) (Charlie Holtz, Conductor, 17:45)
- [Software Development Agents: What Works and What Doesn't](https://aietalks.com/talks/software-development-agents-what-works-and-what-doesnt) (Robert Brennan, OpenHands, 16:46)