Não, isso não é uma fábrica de software — Ryan Cooke, WorkOS

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: No, That’s Not a Software Factory — Ryan Cooke, WorkOS · Canal: AI Engineer · 18:55 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Ryan Cooke explica por que uma fábrica de software não deve ser avaliada apenas pela quantidade de código ou de PRs produzidos, mas pelo impacto na entrega de funcionalidades e nos clientes. Na WorkOS, TARS acompanha projetos e automatiza etapas de engenharia de produto, enquanto Horizon coordena a infraestrutura de execução. Um gateway MCP conecta ferramentas e fornece aos agents contexto sobre como a empresa organiza seus dados e processos. A equipe também busca medir qualidade, segurança e recuperação de defeitos, além de usar dados das sessões para aprimorar continuamente a fábrica.

Pontos-chave

Métricas de produção, como quantidade de código e de PRs, não demonstram por si só que a automação está gerando resultados para a empresa.
O objetivo da fábrica de software da WorkOS é ampliar a capacidade de entrega de funcionalidades e acelerar projetos complexos.
TARS acompanha eventos de ferramentas como Linear e GitHub para avançar projetos e executar trabalho de engenharia de produto, não apenas gerar código.
Documentos de projeto chamados hilltop reúnem objetivos, necessidades de clientes, análise competitiva, telas iniciais de design e marcos.
Agents podem elaborar documentos iniciais e dividir projetos em tickets, com oportunidades para revisão e orientação humana.
Um gateway MCP interno conecta sistemas e explica aos agents como usar as ferramentas e localizar informações.
A WorkOS aplica TARS também à triagem de bugs e solicitações de suporte, e planeja construir sua própria infraestrutura de sandbox.
A equipe quer avaliar impacto nos clientes, taxa de defeitos e tempo de recuperação, além de usar dados de sessões para melhorar a fábrica.

Capítulos

Início	Capítulo	Resumo
00:12	Métricas de resultado para fábricas de software	Cooke argumenta que volume de código e de PRs pode ocultar se a automação realmente acelera entregas e gera valor.
02:54	TARS, Horizon e automação de processos	A WorkOS combina um sistema de interação com agents e acompanhamento de projetos com uma camada de orquestração de infraestrutura.
05:07	Planejamento de projetos com agents	TARS usa dependências entre tickets e documentos hilltop para executar etapas, identificar lacunas no plano e preparar trabalho para revisão humana.
08:49	Exemplo de projeto e colaboração	Cooke mostra como iniciar um projeto pelo Slack, gerar recursos de planejamento e compartilhar contexto com diferentes agents e equipes.
12:05	O gateway MCP como contexto compartilhado	O gateway conecta sistemas internos e orienta agents sobre dados e ferramentas, servindo também a outros usos das equipes.
14:11	Mais automações e infraestrutura própria	A equipe aplica TARS à triagem de bugs e suporte e planeja criar uma camada própria de sandbox e memória contextual.
15:46	Impacto, avaliação e melhoria contínua	Cooke destaca métricas de impacto e qualidade e o uso de sessões para identificar melhorias, lacunas de skills e mudanças necessárias na fábrica.

Citações

É muito difícil distinguir se o resultado está realmente impulsionando resultados. — 01:49

Não era suficiente para gerar mais resultados. — 03:27

Vale muito a pena investir tempo em um servidor de gateway MCP interno. — 13:38

Queremos codificar nossas práticas e processos de engenharia de software em automação. — 17:52

Conceitos e entidades

WorkOS (empresa): Empresa onde Ryan Cooke descreve a implementação de uma fábrica de software integrada aos processos de engenharia de produto.
Ryan Cooke (pessoa): Engenheiro da WorkOS que apresenta a abordagem da empresa para fábricas de software.
TARS (ferramenta): Sistema da WorkOS que permite interagir com um coding agent e acompanhar projetos por meio de eventos de ferramentas internas.
Horizon (ferramenta): Camada de orquestração de infraestrutura da fábrica de software da WorkOS.
MCP gateway (conceito): Gateway interno que conecta ferramentas da empresa e orienta os agents sobre como usá-las e encontrar informações.
Linear (ferramenta): Ferramenta de gestão de projetos cujos tickets e eventos são usados por TARS para acompanhar e avançar o trabalho.
GitHub (ferramenta): Plataforma na qual o trabalho automatizado pode resultar em PRs.
Devin (ferramenta): Coding agent que pode implementar tickets usando a documentação e o contexto dos projetos.
Snowflake (ferramenta): Plataforma de dados usada pela WorkOS como data lake e fonte de tabelas semânticas para informações de produto e clientes.
fábrica de software (conceito): Sistema que integra agents, infraestrutura e processos de engenharia para automatizar partes do desenvolvimento de produtos.
hilltop (conceito): Documento de planejamento da WorkOS que reúne o propósito do projeto, contexto de clientes, análise competitiva, design inicial e marcos.

Tradução completa (pt-BR)

00:12 Bem, obrigado por participarem do último dia da conferência aqui. Sei que foi uma semana longa. Mas estou animado para falar de um tema que é muito importante para mim: fábricas de software. Isso provavelmente não é um conceito novo para nenhum de vocês. Imagino que, se estão todos aqui, conheçam muito bem as fábricas de software. A Ramp publicou no blog sobre os Inspects há vários meses. Acho que talvez em dezembro do ano passado. Não lembro exatamente quando. Já faz um tempinho. E isso realmente empolgou todo o setor, que começou a pensar: “Ah, agora podemos desenvolver software de um jeito bem diferente, já que a IA é extremamente capaz de escrever código.”

00:45 Muitas outras empresas seguiram o exemplo. E há uma estrutura padrão aqui. Você tem um sandbox onde coloca seu código. Coloca um agent de IA ali dentro. Talvez uma sessão do Claude Code ou do OpenCode. E, com um prompt, ele gera um PR e você faz o merge. Talvez vocês já estejam construindo isso

01:17 por conta própria. Na WorkOS, adotamos uma abordagem um pouco diferente. A motivação para o que estamos construindo é que vemos muitas métricas de sucesso se concentrarem no volume de produção, certo? Você vê publicações no X e artigos em blogs falando sobre a porcentagem de PRs, o número de pull requests ou quanto código está sendo gerado por IA e chegando à produção. E essas são

01:49 apenas métricas de volume de produção que podem disfarçar o quanto esses sistemas estão funcionando bem. A porcentagem ou o número de PRs pode ser enganoso diante do aumento geral de PRs. É muito difícil distinguir se o volume produzido está realmente gerando resultados. E é aí que concentramos nossos esforços quando pensamos em uma fábrica de software. A questão é: se vamos investir tempo de engenharia na construção desse nível de automação, e

02:22 se é preciso investir algum trabalho nisso, com equipes em tempo integral dedicadas a isso, como queremos pensar no sucesso desse trabalho e se ele realmente está gerando valor para a nossa organização, para a nossa organização de engenharia? Por isso, em vez de medir apenas o código produzido, observamos métricas de resultados. A questão é: estamos acelerando nossa capacidade de entregar funcionalidades? Acreditamos que o sonho da fábrica de software é dar a cada um dos nossos

02:54 engenheiros uma pequena equipe de engenharia própria. Portanto, a consequência precisa ser desenvolvermos mais e lançarmos mais, e que, quando começarmos a trabalhar em funcionalidades complexas, elas possam ser desenvolvidas muito, muito mais rápido. Então, como isso realmente funciona? Bem, começamos mais ou menos com a mesma coisa que vocês viram em outras fábricas. Começamos com um sandbox construído sobre o Cloudflare. Colocamos nele um roteador de modelos do OpenCode. Alimentamos o sistema com

03:27 prompts. E bem rápido nos deparamos com uma situação em que isso não estava gerando mais resultados. Não havia um aumento incremental nem exponencial em relação ao que os engenheiros conseguiam fazer usando o Claude Code nos laptops. Para nós, a diferença era praticamente imperceptível. Então começamos a pensar: como podemos incorporar nossos processos de engenharia à própria fábrica? Não basta que a fábrica produza código. Queremos que ela também

04:00 assuma e automatize boa parte do outro trabalho que nossos engenheiros fazem para desenvolver produtos. Então, dividimos isso em duas partes. Uma delas é o sistema que chamamos de TARS. É uma forma de os usuários interagirem com o agente de programação. Ele está integrado às ferramentas que usamos. Não apenas ao Slack, mas também ao Linear e ao GitHub. Assinamos webhooks por meio do TARS para que ele possa acompanhar o

04:31 andamento dos projetos, além de gerar código. Também criamos um sistema separado chamado Horizon. Essa é a camada de orquestração da infraestrutura. É muito mais parecido com o Inspects, o Minions e alguns dos outros sistemas que outras empresas construíram. Mas ele fica diante de um gateway MCP. Vou falar um pouco mais sobre por que esse gateway MCP foi tão transformador para nós.

05:07 Ao alimentar o sistema com nossos webhooks e atividades que acontecem em outros sistemas de código-fonte e de acompanhamento de projetos, estamos chegando a esse nível de autonomia em que nossa fábrica realiza trabalho de engenharia de produto, não apenas trabalho de programação. Qual é um exemplo disso? No Linear, podemos definir tickets com dependências. Um ticket bloqueia outro. Isso é bastante comum quando se divide grandes blocos de trabalho em partes menores. Como

05:40 o TARS recebe webhooks quando um ticket é concluído, ele pode pegar automaticamente o próximo ticket de um ciclo. Assim, por meio do nosso processo de planejamento, podemos construir um mapa de como achamos que esse plano será executado, e o TARS pode começar a executá-lo de forma autônoma. Outra coisa que fazemos é, entre essas etapas, quando um ticket é concluído, perguntar ao TARS: “Você pode reavaliar o projeto no Linear e me avisar se agora estão faltando tickets?” Porque, conforme você trabalha, vai descobrindo onde estão as lacunas do seu

06:12 plano. E queremos manter nosso plano continuamente atualizado usando o próprio agent. Isso porque o agent determina que talvez faltem partes do que planejamos inicialmente para o projeto e do objetivo que temos em mente. Na WorkOS, seguimos essa cultura de engenharia de produto. Nela, os engenheiros são responsáveis por muitas das funções de produto. Hoje, não temos product managers nas equipes. E um dos rituais desse

06:45 processo de engenharia de produto é criar um documento Hilltop. É um PRD que tem o objetivo de definir a finalidade do projeto, mas também de incorporar o que os clientes estão dizendo. Onde percebemos a necessidade desse bloco de trabalho? Ele analisa a concorrência. Há produtos semelhantes no mercado hoje dos quais possamos tirar inspiração? Começamos a incluir telas de design preliminares. E descrevemos os

07:15 principais marcos. Ao consolidar e padronizar essas informações em um documento, criamos algo que nossos engenheiros de produto vêm fazendo em toda a empresa. Agora podemos entregar esse material a um agent, e ele pode dividi-lo em blocos de trabalho. Essa tem sido uma maneira muito poderosa de aproveitar processos existentes e incorporá-los às próprias fábricas. Como mencionei, o sistema fica atento aos webhooks. Vou mostrar um

07:46 exemplo de como isso funciona. Ele consegue perceber, por meio dos tickets no Linear, que o documento Hilltop foi revisado e aprovado e, por ter sido aprovado, pode começar a trabalhar automaticamente no projeto. Assim, não precisamos de uma pessoa conduzindo o agent em cada etapa do ciclo de vida. Criamos um agent especificamente para essa parte do processo. Nós o chamamos de PM. Ele prepara o primeiro rascunho do

08:17 Hilltop com base na especificação breve que fornecemos. Ele acrescenta contexto, além de ler as revisões feitas por pessoas, e depois inicia a implementação e divide o trabalho em tickets. As pessoas podem continuar envolvidas em cada etapa desse processo. É muito comum uma pessoa intervir ou comentar um ticket gerado por IA, dando orientações adicionais ou fazendo ajustes. Mas a questão é superar aquele problema inicial, em que podemos avançar na criação de todos esses recursos.

08:49 Certo, então como isso funciona na prática? Este é um projeto que iniciei no mês passado, há dois meses. Estamos adicionando uma nova API a um dos produtos que lidero, chamado Vaults. Com um comando aqui no Slack, posso iniciar esse projeto com uma descrição simples, geralmente algumas frases sobre o que estou tentando fazer. O TARS entra em ação e cria todos esses recursos para mim. Não preciso ir lá e

09:20 crie o projeto no Linear. Não preciso criar um rascunho do documento no Notion. Todos os registros de decisões e as perguntas em aberto. O Tars está criando uma primeira versão disso. E isso me dá uma estrutura fácil para eu assumir como engenheiro de produto líder e começar a especificar melhor, preenchendo as áreas que não estão bem definidas com o conhecimento que tenho sobre o que estamos tentando realizar com o projeto, e depois devolver para o Tars executar. Então, aqui está um exemplo do projeto.

09:57 E, como eu disse, isso estabelece esses primeiros marcos em torno do nosso processo de engenharia de produto. Ainda não fizemos a revisão Hilltop aqui. Quando ela estiver concluída, vamos marcar este ticket como concluído, e o Tars vai pegá-lo e passar para a próxima etapa da implementação do projeto. O que descobrimos é que muitas equipes estão fazendo mais trabalho de briefing de projeto e de Hilltop porque nosso agent pode

10:27 inserir todas essas informações. É o problema da página em branco na hora de escrever. Se você puder começar com um documento que já tenha informações — e, sabe, esses agents não são perfeitos. Às vezes, eles superestimam muito o que estamos tentando realizar com o projeto, e precisamos cortar boa parte do escopo que propõem. Mas tudo bem. É muito mais simples para um engenheiro acrescentar informações a isso do que gastar tempo configurando todos esses elementos básicos por conta própria. E então podemos continuar conduzindo esse trabalho, sabe, pelo Slack, pelo Linear,

10:59 e, no fim das contas, isso resulta em PRs no GitHub. Outra coisa que isso nos permite fazer é que nem sempre precisamos usar nosso agent de programação para implementar partes do trabalho. O Devin é muito popular. Temos muita gente que gosta bastante de usar o Devin. Elas podem direcionar o Devin a esses tickets e à mesma documentação para dar a ele o contexto necessário para implementar diferentes partes do trabalho. O mesmo vale para o Claude Code local, se você estiver usando o Opus em um harness local. Ele pode acessar, por meio de MCP, todas essas

11:34 partes da documentação e usá-las como contexto para o trabalho. E, claro, temos pessoas que colaboram nesses canais de projeto também. Você vai notar que nossa equipe de segurança aparece para analisar os novos projetos, avaliar as implicações de segurança e assim por diante. Eu mencionei que, bem no início do desenvolvimento da nossa fábrica, nós

12:05 criamos nosso próprio gateway MCP. Nós o chamamos de nosso mecanismo de contexto. Ele se conecta a todos os nossos sistemas internos, mas também cria system prompts e contexto sobre como navegar por essas ferramentas e quando usá-las. Ele está conectado ao Snowflake, que é nosso principal lago de dados. Criamos tabelas semânticas no Snowflake que descrevem o uso do produto ou as conversas com clientes.

12:35 Então, podemos fornecer a um agent, por meio do nosso servidor MCP, uma lista de descrições de ferramentas com as tabelas disponíveis e o conteúdo que elas contêm. Se você estiver tentando responder a perguntas sobre esse tipo de conteúdo, escreva uma consulta para estas tabelas. Isso dá ao agent um pouco de orientação para entender como usar nossas ferramentas, como organizamos o Linear no Snowflake e algumas indicações de onde encontrar informações. O que foi realmente

13:08 surpreendente nisso é que agora usamos esse servidor MCP em muitas outras ferramentas internas. Nós o disponibilizamos para que as pessoas façam consultas diretamente pelo Slack, para análises de dados ou de clientes. Então, embora inicialmente imaginássemos que isso seria apenas uma forma de conectar nosso agent, ou agent de programação, a todos os nossos sistemas, essa se tornou uma ferramenta extremamente poderosa para muitas das nossas equipes internas, e estamos criando várias outras ferramentas sobre esse gateway MCP. Então, se você está começando

13:38 a pensar em uma fábrica de software, vale muito a pena investir tempo em um servidor de gateway MCP interno que conecte todas as suas ferramentas e tenha descrições capazes de explicar ao agent como usá-las e como você organiza especificamente as informações nelas. Acho que você vai descobrir que isso acaba sendo útil em muitos outros casos de uso. Como mencionei, tentamos automatizar outras partes do nosso desenvolvimento de software.

14:11 Temos solicitações de bugs que chegam pelo Slack. O TARS pode ouvi-las por meio de webhooks e fazer uma primeira triagem, implementar correções e abrir PRs para corrigir os bugs. Também temos muitos clientes em canais compartilhados no Slack. Descobrimos que o TARS é bastante útil para fazer a triagem das solicitações de suporte que recebemos por esses canais, porque consegue analisar o código e muitas vezes entender onde o cliente pode estar tendo

14:42 problemas com nosso produto, do ponto de vista do código. Mostrei um exemplo de como organizamos os principais recursos em torno disso. E o último lugar que considero realmente empolgante é que todos estamos tentando chegar a um software que se aperfeiçoa sozinho, ou a um software autônomo. Então, estamos usando o TARS para construir nossa própria infraestrutura de sandbox. Queremos deixar de usar alguns sandboxes como serviço e assumir nós mesmos essa camada de infraestrutura.

15:13 Alguns dos motivos para isso são que queremos ter controle profundo sobre as informações da sessão e poder mover cargas de trabalho entre diferentes partes da nossa infraestrutura. Então, o que estamos construindo agora é nossa camada de memória, e queremos que ela seja um contexto sempre atualizado sobre o que cada pessoa da empresa está fazendo, em que equipe trabalha, por quais produtos é responsável e, no nível da organização, qual é a semântica da WorkOS e de como trabalhamos. E queremos poder

15:46 conectá-la tanto à nossa fábrica de software quanto extrair esse contexto da fábrica e levá-lo também para nossas outras ferramentas de IA. Então, acho que esse é nosso principal aprendizado sobre onde vimos muita gente investir esforço, concentrando-se apenas nos resultados, e sobre onde acreditamos que podemos obter esse valor exponencial humano da nossa fábrica. Será que podemos realmente entregar valor aos nossos clientes? Pensamos muito em

16:16 lançamentos e no impacto para os clientes, então queremos codificar isso na própria fábrica de software. Certamente nos preocupa introduzir instabilidade nos nossos produtos. Então, tudo bem, podemos medir a taxa de defeitos e outras métricas, como o tempo de recuperação? E há também muitos indícios anedóticos: queremos ver nossos engenheiros usando o TARS como sinal de que ele está agregando valor e acelerando o trabalho. Queremos ver que eles estão optando por sair do

16:48 harness local e passar para um sandbox na nuvem. E o verdadeiro objetivo é usar essas informações — como somos donos da infraestrutura, podemos ver o que está acontecendo nela — para aperfeiçoar a fábrica. Queremos que ela aprenda, que melhore na maneira como escreve código. Queremos identificar em que aspectos nossos engenheiros podem aprimorar suas habilidades. Há tanta

17:19 coisa acontecendo rapidamente na IA. É como uma corrida constante para acompanhar as dicas e técnicas mais recentes. Podemos direcionar agents às sessões e identificar onde estão as lacunas na maneira como as pessoas usam nossa fábrica. Que skill deveríamos criar porque o agent cometeu um erro? Quais skills já não são relevantes? Talvez o código tenha mudado a ponto de uma skill que escrevemos há seis meses estar obsoleta. Então, isso dá continuidade à verificação. É no modo semionline

17:52 que vemos uma grande vantagem em sermos donos de toda a infraestrutura. Então, vou dizer pela terceira vez, porque vale repetir: os sandboxes são ótimos. É legal executar um agent e vê-lo abrir um PR. Pensamos bastante nas nossas práticas e nos processos de engenharia de software, e queremos codificá-los em automação. Sou Ryan, um dos engenheiros aqui na WorkOS. Temos um estande bem ali

18:24 do lado oposto à área de apresentações. Se vocês estão construindo fábricas de software, adoraria conversar com vocês. Gostaria muito de saber como estão lidando com autorização. Não falo sobre isso porque ainda não descobrimos como resolver por conta própria, mas talvez vocês tenham algumas ideias. Então, por favor, passem pelo estande e venham conversar comigo. Vou adorar bater um papo. Obrigado.

18:55 >> [música]

Transcrição original

[00:12] Well, thank you for joining the final day of the conference here. I know it’s been a long week. But I’m excited to talk about a topic here that is very near and dear to me. Software factories. Um You this is probably not a new concept to any of you. I’m guessing if you’re all here, you’re very familiar with software factories. You know, Ramp blogged about their inspects several months ago. I think maybe December last year. I forget exactly when. It’s been a little while. And that really kind of like excited the entire

[00:45] industry of thinking like, oh, we can actually build software very differently now that AI is extremely capable of writing code. Um a lot of other companies have followed suit. Um and there’s kind of like a standard set up here. Uh you have a sandbox that you put your code into. Um you put a an AI agent in there. Maybe a Claude code section or an open code. Um and with a prompt, it generates a PR and you merge it. Um You might be building this already

[01:17] [clears throat] yourself. We have taken a slightly different approach at WorkOS. Um and the motivation for what we are building is that we see a lot of the kind of success metrics um really focusing on output, right? Like you’ll see posts on X and blogs talking about the percentage of PRs or the number of pull requests or how much code uh is being generated by AI moving into production. Um and this is

[01:49] just really output metrics that um you know, this can actually disguise how well these systems are working. Percentage of PRs or number of PRs may be lying in overall increase in PRs. It’s very hard to distinguish whether the output is actually driving outcomes. And so that’s kind of where we focus our efforts when we’re thinking about a software factory. It’s like if we’re going to go put engineering time into building this level of automations and

[02:22] there’s a bit of work that needs to go into this. Full-time teams dedicated to this. How do we want to think about the success of this and whether this is actually driving value for our organization, our engineering organization? And so we measure instead of just code output, we’re looking at outcome metrics. And that is really about like are we accelerating our ability to deliver features? We think that the dream of the software factory is that it gives each of our

[02:54] engineers a small engineering team for themselves. And so the consequence of that really needs to be that we’re building more and we’re shipping more and that as we embark on complex features, those can get built a lot more a lot more quickly. So what does this actually look like? Well, we kind of started with the same thing you’ve seen in other other factories. We start with a sandbox we built on top of Cloudflare. We put an open code model router in there. We’re feeding it

[03:27] prompts. Um, and we kind of very quickly kind of ran into this situation where this wasn’t driving more outcomes. This was not an incremental increase or an exponential increase over engineers just driving cloud code on their laptops. It was actually pretty indistinguishable for us. And so we really kind of started to think about, well, how can we embed our engineering processes into the factory itself? It’s not sufficient that the factory is producing code. We actually want it to

[04:00] take a lot of the other work that our engineers do to produce products and automate that as well. So, we kind of split this into two parts. One is we have the system we call TARS. This is a way for users to interact with the coding agent. And it is embedded into the tools that we use. So, not just Slack, but also Linear and GitHub. We subscribe to webhooks through TARS so that TARS can actually track the

[04:31] progress of projects in addition to generating the code outputs. And then we built a separate system called Horizon. And this is the infrastructure orchestration layer. This is a lot more similar to Inspects and Minions and and some of the other systems that other companies have built. But, it sits in front of an MCP gateway. And I’m going to talk a little bit more about why that MCP gateway has been really transformational for us.

[05:07] So, by feeding our webhooks, activities that are happening in other uh source code systems and project tracking systems, we’re starting to get to that level of autonomy where our factory is performing product engineering work, not just code work. So, what’s an example of this? In Linear, we can define tickets that have dependencies. So, one ticket blocks another ticket. Pretty common for, you know, breaking down uh large units of work into smaller ones. Because

[05:40] uh TARS is getting webhooks on ticket completion, it can automatically pick up the next ticket in a cycle. And so, we can do through our planning process construct like a map of how this plan we think this plan is going to get executed and TARS can start to execute on that autonomously. The other thing that we have is in between those steps when a ticket is completed, we can ask TARS “Can you reevaluate the linear project and let me know if it’s missing now tickets?” Because as you do work, you’re learning about where the gaps in your

[06:12] plan. And we want to continuously keep our our plan fresh by using the agent itself. Because the agent is determining that there may be missing pieces to what we initially planned for the project and the goal that we have in mind. So, we run this product engineering culture at WorkOS. This is where engineers are responsible for a lot of the product functions. We don’t have product managers on teams today. Um and one of the rituals as part of

[06:45] this product engineering process is we create a hilltop document. It’s a PRD and it is intended to both define what is the purpose of this project, but also incorporate um what are customers talking about? Like where are we seeing the need for this unit of work? Uh it looks at competitive analysis. Like are there similar products out in the market today that we can draw inspiration from? We start to bring design early design screens into this. Um and we outline like what are the

[07:15] major milestones. And so, by kind of consolidating and canonicalizing this information into a document, this is something our product engineers have been doing uh throughout the entire uh company. Um now we can ask give this resource to an agent and an agent can break this into units of work. Uh and so, this has been a really uh powerful way for us to take existing processes and encode them into the factory themselves. Like I mentioned that it’s listening for web hooks. I’ll show an

[07:46] example of what this looks like, but it it can see that the hilltop document through linear tickets has been reviewed and approved and by virtue of it being approved can start work on this project automatically. So we don’t need a human to be shepherding this agent through every single step of the life cycle. So we created an agent specifically for this part of the process. We call it the PM. And it is doing the first draft of the

[08:17] hilltop based on the brief specification that we give it. It’s adding context to that in addition to reading the human reviews and then it picks up the implementation and breaking that into tickets. And there’s an opportunity for humans to stay in the loop for each part of this process. I mean it’s very common for a human to intervene or comment on a ticket that’s generated by AI, give it further guidance or refinements. Um but it’s really about that like cold start problem where we can kind of get

[08:49] over the hump of creating all these different resources. Okay, so what does this actually look like? So here’s a project I kicked off last month two months ago. Um we’re adding a new API to products I lead called Vaults. And with a command here in um in Slack I can kick off this project with a simple description, usually a few sentences of what I’m trying to accomplish. Tarsin goes in and creates all these resources for me. I don’t need to go and

[09:20] create the project in linear. I don’t need to create a draft of the notion document. Um all of the decision logs and the open questions. Um Tars is creating a first pass at that. And so this then gives me an easy framework for me to step into as the lead product engineer and start giving more specification, rounding out areas that aren’t well defined with knowledge that I had know about what we’re trying to accomplish with the project, and then hand it back to Tars uh for execution. So, here’s an example of uh the project.

[09:57] Um and it’s like I said, it sets up these first milestones around our product engineering process. So, we haven’t done the hilltop review yet here. When that’s done, we’ll uh we’ll we’ll mark this ticket as complete and Tars will pick that up and move on to the next stage of project implementation. So, what we found is like a lot of teams are now doing more project brief and hilltop work because our agent can

[10:27] seed all that information. It’s that blank page problem with writing. If you can come into a document that already has information, and you know, these agents aren’t perfect. There are times where it grossly overestimates what we’re trying to accomplish with this project, and we have to cut out a lot of the scope that it comes up with. But, that’s fine. That’s a lot simpler for an engineer to add input into into rather than them spending time to set up all these primitives themselves. And then we can continue to drive this work, you know, through Slack, through Linear,

[10:59] um and ultimately uh results in PRs in GitHub. The other thing that this lets us do is we don’t necessarily always need to use our coding agent to implement uh pieces of work. Uh Devin is very popular. We have a lot of folks that really like using Devin. They can point Devin to these tickets and the same documentation to give Devin the context it needs to go and implement different parts of the work. Uh same with the local cloud code if you’re just using Opus in a local harness. Um it can grab through MCP all of these uh

[11:34] all of these pieces of documentation and use that as context for its work. And then, of course, we have people that collaborate in these project channels as well. You’ll notice our security team will come in and look take a look at new projects, weigh in on the security implications, and so forth. So, I alluded to we we kind of early on in the the development of our factory is

[12:05] created our own MCP gateway. Um, we call it our context engine. Um, this connects into all of our internal systems, but it also builds system prompts and context around what how to navigate these tools and when to use these tools. So, it is connected into Snowflake, which is our main data lake. We have semantic tables that we’ve built in Snowflake that describe product utilization or customer conversations.

[12:35] And then, we can provide an agent through our MCP server in the tool description list of here are the tables, this is the content they contain. If you’re trying to answer questions about this type of content, write a query for these tables. And so, it gives us a little bit of orientation to an agent to understand how to use how we use our tools, how we’ve organized linear in Snowflake, and give some guidance on where to find information. What has been really

[13:08] surprising about this is we actually now use this MCP server across a lot of other different internal tools. We open it up for people to query directly from Slack to do data or customer analysis. And so, while we initially kind of envisioned that this would just be a way to connect our agent or coding agent to all of our systems. Uh this has been an incredible piece of leverage for a lot of our internal teams, and we’re building a lot of other tools on top of this MCP gateway. So, if you’re just getting

[13:38] started with thinking about a software factory, it’s well worth your time to invest in an internal MCP gateway server that both connects all your tools, has descriptions that can tell the agent how to use those tools and how you specifically organize the information in them, and I think you’ll find that that ends up being useful in a lot of other use cases. Like I mentioned, we try to automate other parts of our software development.

[14:11] Um we have like bug bug requests that come in through Slack. Uh so, TARS through webhooks can listen to those and take a first pass at triaging and implementing opening PRs to fix bugs. Uh we have a lot of our customers uh in shared channels in Slack, as well. Uh we found TARS to be pretty useful to uh triage support requests that we’re getting through them, because it can look at the code, it can often understand like where the customer might be running into

[14:42] problems with our product uh from the code perspective. Um I showed you an example of how we kind of organize major features around this. Uh and then the last place I think is really exciting, we’re all trying to get to the self-improving software, or the self-driving software. So, we’re using uh TARS to actually build out our own uh sandbox infrastructure. So, we want to move off of some of the sandboxes as a service and own that infrastructure layer ourselves. Um

[15:13] Some of the reasons we have for that is we want really deep control over the session information, and uh be able to move workloads around different parts of our infrastructure. Uh so what we’re building out next is our memory layer and we want this to be an evergreen context uh about what every person in the company is working on, what team do they sit in, what products are they responsible for, and then at an organization level, what is the semantics about Work OS and how we do our work. And this we want to be able to

[15:46] plug into both our software factory, but lift that context out of our factory and into our other AI tools as well. So, I think this is kind of our our major takeaway of where we’ve seen a lot of folks invest effort just around outputs and where we think we can actually get that human exponential value out of our factory. Can we be actually delivering values to our customers? We think a lot about

[16:16] shipping and customer impact and so we want to encode that into their our software factory itself. Um certainly worried about, you know, introducing instability into our products. So, all right, can we measure uh defect rate and other um you know, time to recovery uh metrics? Um and then a lot of anecdotal, like we want to see our engineers using TARS as a sign that this is giving them value and accelerating their work. We want to see that they’re moving off electing to

[16:48] move out of their local harness and into a cloud sandbox. And then the real goal is we can use this information because we own the infrastructure, we can see what’s happening in the infrastructure. We use this information to self-improve the factory. We want it to learn, we want it to get better about how it writes code. We want to see where um our engineers can improve their skills. There’s so

[17:19] much moving quickly in AI. It’s kind of like a constant race to keep up with the latest um you know, tips and techniques. We can actually point agents at sessions and see where are the gaps and how people are using our factory. Where is there a skill that we should be building because the agent made a mistake. What skills are no longer relevant? Maybe the code has changed to a degree where a skill that we wrote six months ago is now obsolete. So, that continues verification. Semi-online

[17:52] is where we kind of see a big advantage to actually owning all the infrastructure ourselves. So, say it for the third time, it’s worth repeating. Sandboxes are great. It’s cool to run an agent and have it open a PR. We really think about our software engineering practices and processes and we want to encode those in automation. I’m Ryan. I’m one of the engineers here at WorkOS. We have a booth right

[18:24] opposite the speaking area. If you are building software factories, I would love to talk to you. I would really love to hear how you’re handling authorization. This is something I don’t talk about because we haven’t figured it out yet for ourselves, but maybe you all you all have some insights. So, please come by the booth, talk to me, would love to chat. Thank you.

[18:55] >> [music]