ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial3 min readDisconfirmAI Editorial

WorkOS Engineer Ryan Cooke: Unlocking the Software Factory Is Not Infrastructure, But Encoding Engineering Workflows into Executable Automation

Product engineer Ryan Cooke reported at the 2026 AI Engineer World's Fair that an initial software factory setup combining a sandbox, model routing, and repository produced results nearly indistinguishable from engineers running coding tools locally. He argued the industry is optimizing for the wrong variables—PR count and AI code share measure production rate, not value delivery rate—and demonstrated how WorkOS encodes planning (Hilltop documents and PM agents), coordination (ticket dependencies and completion webhooks), and context (an internal MCP gateway) into automation, enabling agents to participate in the engineering workflow itself rather than merely generating code.

2026-09-27 23:30 GMT+8

The software factory WorkOS initially built placed code in a Cloudflare sandbox, connected it to model routing, fed in prompts, and generated pull requests—the results were hard to distinguish from engineers running Claude Code on their laptops. Product engineer Ryan Cooke described this disappointing finding at the 2026 AI Engineer World's Fair and proposed an argument: sandboxes, models, and repositories are necessary conditions, but not sufficient ones; a true software factory must encode the organization’s own engineering workflows into automation.

Cooke argues the industry is optimizing for the wrong variables. Ramp reports over 50% of merged PRs come from AI, Spotify reports more than 1,500 AI-generated PRs merged, and Stripe merges over 1,000 PRs per week—these numbers describe production rates, not value-delivery rates. When building the factory itself consumes engineering time or requires dedicated teams, judging success by PR count alone obscures a harder question: did features reach customers faster? His alternative measurement directions are feature delivery time, defect rate at ship, and issue resolution time.

WorkOS’s response is to break engineering workflows into executable automation units. They built two system layers: TARS is the user-facing interface, embedded in Slack, Linear, and GitHub, subscribing to project events via webhooks; Horizon is the infrastructure orchestration layer, managing sandbox pools and event loops. The key design lies in TARS not just generating code, but participating in the engineering workflow itself.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The specific mechanism works as follows: Linear tickets have dependencies, where one ticket blocks another. When TARS receives a ticket-completion webhook, it automatically picks up the next unlocked ticket to continue execution. Engineers can ask TARS to reevaluate the project plan between steps, uncovering omissions exposed during implementation. This autonomy comes from responding to project state, rather than treating each coding session as an isolated task.

At the planning level, WorkOS uses Hilltop documents—a product requirements document consolidating project purpose, customer needs, competitive analysis, early designs, and milestones. A PM agent reads the Hilltop document, breaking it down into tickets with dependency chains. Humans review and add context; after merging, Horizon automatically unlocks the next ticket. Cooke used his Vaults API project as an example: describing the goal in a few sentences in Slack, TARS created a Linear project, a Notion draft, and decision logs; he then added specifications, filled in ambiguities, and handed it back for execution. Cooke reported the team now does more project briefs and Hilltop work because the agent solves the blank-page problem; however, drafts often grossly overestimate project scope, requiring engineers to cut substantial portions.

Cooke calls the internal MCP gateway the "context engine," arguing it is the most worthwhile investment for any team starting a factory. It does more than connect tools; it encodes organizational knowledge into tool descriptions: telling agents which semantic tables exist in Snowflake, what they contain, and which tables to query for specific questions. WorkOS later opened this gateway to Slack queries for data and customer analysis, finding it equally applicable to non-coding scenarios. Cooke’s quote: "Agents can figure it out with minimal context, but it's slow; they spend tokens rediscovering conventions. We keep tightening that loop."

However, Cooke provided no numerical delivery or reliability results. His three proposed measurement areas are delivery and customer impact, reliability (defect rate and recovery time), and voluntary adoption (whether engineers proactively choose TARS and cloud sandboxes over local tools), explicitly noting that voluntary adoption is largely anecdotal. Two unresolved boundaries are notable: WorkOS has not yet determined the authorization model for this factory—who can authorize agents to execute actions on its connected systems; and a company-wide memory layer is a planned next step with no completed implementation described. Cooke directly posed the authorization question to peers at the end of his talk, expressing interest in how other teams handle it.

Sources

  • youtube.com↗
Continue researching →