Como criar uma fábrica de software que realmente funciona (curso completo)

Autoria: Greg Isenberg · 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: Building a Software Factory that actually works (Full Course) · Canal: Greg Isenberg · 31:16 · Assistir no YouTube

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

Resumo

Ross Mike explica como organizar agentes de IA em uma fábrica de software: um workflow que ajuda a entregar funcionalidades com rapidez sem abrir mão da qualidade. O processo apresentado tem quatro etapas: isolar cada tarefa em uma branch e worktree, construir com orientações de estrutura de código, comprovar o resultado com testes ou evidências visuais e enviar para revisão. Um agente de revisão de código pode apontar problemas e iniciar ciclos de correção até que o trabalho atinja o padrão esperado. A fábrica não depende de um modelo ou harness específico; ela é composta por workflows, skills e conhecimento de domínio.

Pontos-chave

Uma fábrica de software é um workflow estruturado, não um produto ou harness específico.
Cada funcionalidade deve ser isolada em uma branch e worktree próprios para evitar que agentes sobrescrevam o trabalho uns dos outros.
A skill de estrutura de código orienta os agentes a produzir código mais organizado e compreensível.
Os agentes devem comprovar o que fizeram com testes, capturas de tela, vídeos ou medições antes e depois.
As evidências ajudam pessoas não técnicas a revisar o resultado sem precisar ler todo o código.
Um agente de revisão de código pode identificar problemas e devolver a tarefa à etapa de construção.
O ciclo de construir, comprovar e revisar se repete até que o trabalho atinja o nível esperado.
A pessoa responsável entra no processo para revisar e mesclar a alteração quando ela está pronta.

Capítulos

Início	Capítulo	Resumo
00:00	O que é uma fábrica de software	Greg Isenberg apresenta a ideia de usar agentes para produzir software em um processo semelhante a uma linha de montagem.
03:49	Por que estruturar o workflow	Ross Mike explica que a fábrica aproveita modelos cada vez mais capazes e apresenta seus arquivos e skills.
05:27	Isolar tarefas em branches e worktrees	Cada funcionalidade é trabalhada em uma cópia isolada do projeto para permitir tarefas paralelas sem sobreposição.
11:20	Construir com estrutura de código	A skill de estrutura de código orienta os agentes a produzir implementações mais organizadas e fáceis de entender.
14:38	Comprovar o trabalho realizado	Testes, capturas de tela, vídeos e medições demonstram se a mudança realmente funcionou.
22:14	Revisar, corrigir e enviar	Greptile revisa o pull request e seu feedback pode levar o agente de volta à construção até resolver os problemas.
26:29	A analogia com uma fábrica física	Os participantes relacionam isolamento, construção, comprovação e envio às etapas de produção e controle de qualidade.
29:09	A fábrica como workflow, não como produto	Ross reforça que uma fábrica de software pode ser composta por arquivos Markdown e recomenda usar revisão de código.

Citações

Uma fábrica de software é totalmente independente de harness e de modelo. — 02:07

Como posso aproveitar ao máximo a capacidade do modelo em cada etapa do desenvolvimento? — 03:16

Só porque funciona não significa que foi bem escrito. — 13:01

A fábrica permite que um agente trabalhe em uma instância isolada, com diretrizes para construir e uma metodologia para comprovar o trabalho. — 25:58

Conceitos e entidades

software factory (conceito): Workflow estruturado que organiza agentes e etapas de desenvolvimento para entregar software com rapidez e qualidade.
AGENTS.md (ferramenta): Arquivo Markdown incluído no contexto do agente para orientar seu comportamento e seu workflow.
new feature (ferramenta): Skill que inicia cada funcionalidade em uma nova branch e worktree para isolar o trabalho.
code structure (ferramenta): Skill que orienta o agente a escrever código organizado e mais fácil de revisar.
service layer architecture (conceito): Arquitetura mencionada como referência para estruturar o código em uma camada de serviços compreensível.
evidence-driven testing (ferramenta): Skill que registra evidências do estado anterior e posterior para demonstrar que uma alteração funcionou.
before and after (ferramenta): Skill que apresenta evidências visuais ou outros resultados comparáveis antes e depois de uma mudança.
Grep Loop (ferramenta): Skill que usa o feedback de revisão de código para orientar ciclos de correção até que os problemas sejam resolvidos.
Greptile (ferramenta): Serviço de revisão de código que analisa pull requests, aponta problemas e fornece uma pontuação de confiança.
CodeRabbit (ferramenta): Serviço de revisão de código citado como alternativa a Greptile.
Cursor Cloud agents (ferramenta): Recurso citado como exemplo de agentes que trabalham em tarefas de software e apresentam evidências em vídeo.
Ross Mike (pessoa): Convidado que apresenta seu workflow e explica como organiza uma fábrica de software.
Greg Isenberg (pessoa): Apresentador do vídeo e interlocutor de Ross Mike.
Brex (empresa): Empresa citada no anúncio que abre o episódio.
Vercel (empresa): Empresa mencionada no anúncio como usuária da Brex.
OpenAI (empresa): Empresa mencionada no anúncio como usuária da Brex.
Anthropic (empresa): Empresa mencionada no anúncio como usuária da Brex.

Tradução completa (pt-BR)

00:00 O que são software factories e por que isso está viralizando? Basicamente, é um conceito que permite usar agents de IA para realmente lançar software que não é nada malfeito, mas se parece mais com uma fábrica. Pense em uma linha de montagem: em vez de construir produtos físicos, você está construindo software. E esse é mais ou menos o sonho. Se você consegue criar essa fábrica que constrói software — software valioso — e criar vários aplicativos que geram receita e agregam valor à

00:31 vida das pessoas, isso me parece ótimo. Então, no episódio de hoje, convidei Ross Mike, e ele explica claramente todo o processo. [música] Ao final deste episódio, você vai entender como montar sua própria software factory. [música] Então, aproveite o episódio. Mal posso esperar para ver o que você vai construir. Existe um motivo para esse conceito estar viralizando, e nos vemos no final. O episódio de hoje é oferecido pela Brex. Minha empresa usa a Brex há um ano e meio, e comecei a usar porque não parava de ouvir que empresas como Vercel, OpenAI e Anthropic usavam a Brex. Pensei: se elas

01:01 usam, por que eu não usaria? Foi uma mudança e tanto. O que me conquistou foi a facilidade de uso. Tem cartões com limites altos, serviços bancários e IA que cuida sozinha do trabalho burocrático do administrativo, como relatórios de despesas, que eu não quero fazer. É realmente feita para esse mundo de agents. Se você está construindo algo novo, está na hora de conhecer a Brex. Acesse brex.com/solutions/startups. Link na descrição. >> A startup pelo contraste. [música] Estamos tomando um gole de tempo, pessoal.

01:35 >> Mickey, bem-vindo de volta ao podcast. O que as pessoas vão aprender ao final deste episódio? >> Vamos entender o que significa essa expressão bizarra, software factory. Vou até mostrar como uso a minha. É bem mais fácil do que você imagina e, com certeza, não depende de um modelo nem de um harness específico, então você não precisa comprar outro produto para ter uma software factory. Vai ser divertido e simples. >> Certo. Então você vai explicar o que é, por que importa, como funciona e como pensar sobre isso. Ao final, as pessoas vão poder colocar a própria software factory para funcionar, se quiserem, ou, se pensarem: “Sabe

02:07 de uma coisa? Esse tal de Ross Mike… não, não, não, não gosto de software factories. Não gosto do que ele está dizendo.”, podem deixar para lá. >> Com certeza, com certeza. Com o termo software factory, surgiram muitas startups, e, veja bem, não estou aqui para desmerecer o trabalho de ninguém. Mas uma software factory não depende de um harness nem de um modelo específico, ou seja, não importa qual modelo você use nem qual harness você use. Deve funcionar, certo? Porque uma software factory tem mais a ver com o workflow, as skills e o conhecimento de domínio de alguém, organizados

02:42 em skills específicas que essa pessoa usa no processo de desenvolvimento. Agora, quero que todo mundo pense no último aplicativo que criou. Provavelmente, você abriu o Codex, o Claude Code, o Cursor ou outra ferramenta e simplesmente digitou, certo? Disse: “Quero construir isto.” E a ferramenta construiu para você. Você viu o resultado, não gostou e fez algumas mudanças, certo? Viu as mudanças, talvez tenha gostado, fez o deploy na Vercel ou em produção e pronto, ou continuou iterando. Esse é o processo. O objetivo de uma software factory é, em cada etapa do processo de desenvolvimento, descobrir como posso

03:16 maximizar a capacidade do modelo para obter o melhor resultado, certo? E também como posso avançar rápido, certo? Porque, se estamos usando o termo fábrica, existe uma estrutura, uma velocidade e uma lógica de linha de montagem que me permitem lançar o mais rápido possível sem perder qualidade. Essa é a definição longa e prolixa de software factory do Mike Schmollis. Espero não ter perdido ninguém, Greg. >> Foi perfeito. Certo, entendido. Mas por que isso importa? >> O motivo de isso importar é que a inteligência continua aumentando. Temos modelos incríveis, como GPT-6 Astra. Uma boa software factory permite sistematizar e usar esses modelos de maneira muito eficiente, em vez de simplesmente digitar e continuar indo e voltando. Acho melhor mostrar como a minha funciona, para dar uma ideia às pessoas. Vou disponibilizar minhas skills de graça, sem cobrar nada nem nada disso, mas não quero que vocês simplesmente me copiem sem pensar. Gostaria que refletissem sobre isso, entendessem o processo e depois o aplicassem

03:49 por conta própria. Dito isso, tenho uns cinco ou seis arquivos que compõem minha software factory. Tenho um arquivo agents.md e, para quem talvez não saiba o que é um arquivo agents.md, basicamente é um único documento, um arquivo Markdown, que é injetado no chat do agent. Isso é injetado… Desculpe, não no system prompt. É injetado no chat do agent toda vez que você se comunica com um agent. Então, toda vez que digo “oi”, se houver um arquivo agents.md, ele é enviado antes do “oi”. E o interessante desse arquivo é que posso

04:20 determinar, de certa forma, como quero que o agent aja. E, há pouco tempo, fizemos um vídeo, Greg, em que falei que o arquivo agents.md da maioria das pessoas é inútil, porque elas explicavam nele como era o código e incluíam informações que já estavam na base de código e que o agent já poderia conhecer. Mas, se você olhar o meu, há um workflow simples, e esse workflow não é algo que venha por padrão no agent, então ele explica claramente como fazer. Vou mostrar cada etapa. A primeira etapa é isolar. Há uma skill chamada new feature, e é isso que ela faz.

04:53 Ela diz: “Toda nova funcionalidade começa em uma nova árvore de trabalho do Git, criada a partir de origin main, para que os agents possam trabalhar em paralelo sem conflitos. Nunca desenvolva na main.” E, se você sabe como é quando Michael está no canal do Greg, sempre há diagramas. Então, vamos desenhar. Na primeira etapa, quando estou trabalhando em um projeto e digo para o agent trabalhar em uma funcionalidade, a primeira coisa que ele faz é isolá-la. Basicamente, isso significa que você pode imaginar o aplicativo do Greg e do Mike. Pode pensar

05:27 no aplicativo do Greg e do Mike como uma jornada: começamos aqui, começamos a escrever prompts aqui e, neste ponto, lançamos o produto em produção e temos milhares de clientes. A forma como a maioria das pessoas trabalha com seus agents é construir uma funcionalidade em cada etapa da jornada, construir uma funcionalidade, construir outra funcionalidade. É um processo muito linear, certo? Uma funcionalidade de cada vez, uma funcionalidade de cada vez, uma funcionalidade de cada vez. E, se você já tentou trabalhar em várias funcionalidades ao mesmo tempo, às vezes surgem conflitos, há

06:00 problemas. As pessoas dizem: “Ah, meu agent apagou este arquivo, sobrescreveu aquele arquivo.” O que essa primeira etapa, isolar, faz é o seguinte. Vou mostrar em um diagrama. Digamos que o Greg diga: “Não gosto nada da nossa página inicial.” E eu digo ao Greg: “Sabe, nossas chamadas de API poderiam ser mais rápidas.” Quando o Greg trabalha na funcionalidade dele, o agent, usando meu agents.md, cria uma nova branch. Você pode pensar em uma branch como uma cópia exata do

06:32 momento atual do aplicativo. Então, o Greg vai trabalhar em uma nova branch, em uma nova árvore de trabalho do aplicativo. Uma árvore de trabalho é basicamente uma cópia do aplicativo. Pense em alguém copiando um bloco de texto, colando-o em um novo documento, trabalhando nesse documento e, em algum momento, incorporando as alterações de volta ao documento original. É isso que o Greg está fazendo. Ele tem um novo documento para trabalhar naquela funcionalidade. E adivinhe? O Mike tem outra funcionalidade em que precisa trabalhar. Então, posso fazer isso ao mesmo tempo ou posso fazer em um momento diferente

07:02 o momento exato em que o app está. Então, Greg vai trabalhar em uma nova branch, uma nova work tree do app. Uma work tree é basicamente uma cópia do app. Pense em alguém copiando um bloco de texto, colando-o em um novo documento, trabalhando nesse documento e, em algum momento, mesclando-o de volta ao documento original. Então, é isso que Greg está fazendo. Ele tem um novo documento no qual está trabalhando nesse recurso. E adivinhe? Mike tem outro recurso em que precisa trabalhar. Então, posso fazer isso ao mesmo tempo ou posso fazer em um momento diferente

07:33 tempo. Agora tenho minha própria branch. Olha só que legal. Eu, Greg e outra pessoa, ou você mesmo com 50 agents diferentes, podemos trabalhar em vários recursos, e não vai haver problema de um agent passar por cima do trabalho de outro. Isso acontece muito com as pessoas. Se você vir tweets, Greg, de pessoas dizendo: “Cara, eu estava trabalhando nisso, e o agent apagou um monte de coisas.” Quase sempre, é porque as pessoas têm seus agents trabalhando em recursos diferentes na mesma branch.

08:06 E o agent vai fazer o que você mandar. Então, você mandou que ele atualizasse a página inicial, mas também mandou que deixasse as chamadas à API mais rápidas, e agora ele está percebendo: “Ah, essas páginas, o jeito como estão chamando a API é péssimo. Vou apagar isso e escrever de novo.” Só que ele estava trabalhando no design daquela página. Aí começam a surgir problemas. O Isolate me permite trabalhar em vários recursos ao mesmo tempo, em paralelo, sem que um agent passe por cima do outro. Esse é o primeiro passo do meu workflow.

08:36 Isso não é nativo do agent. Então, faz sentido isso existir em, hum, o Greg terminou, ou quando eu terminar, e vou explicar o workflow disso, mas, só para fechar o ciclo, quando o Mike terminar, tudo o que faço é mesclar essas alterações de volta. E, quando o Greg terminar, ele pode fazer isso antes de mim ou depois de mim. Mas estamos mesclando no documento principal, e não vai haver conflitos porque, primeiro, trabalhamos em uma cópia. Então, isso me permite lançar rápido com

09:11 vários agents. Se eu mostrar para vocês, talvez eu possa mostrar aqui. Se eu mostrar meu terminal, vocês vão notar que há quatro abas do Bezel; hum, três delas terminaram, mas literalmente tenho quatro recursos diferentes no mesmo aplicativo. Um está trabalhando em um cliente de e-mail, outro está trabalhando em um ambiente de computador, um ambiente Linux, e o outro está fazendo uma atualização da página inicial. Então, posso trabalhar nesses recursos com confiança, mantendo o isolamento. Isso não é nativo do agent. Esse agents.md mais a nova skill de recurso

09:44 me permite fazer isso. Vou pausar aqui. Alguma pergunta até agora? >> Sim, quero dizer, está muito claro. Acho que, se eu pensar nisso da forma como penso, se você tivesse mesmo uma equipe de engenheiros e estivesse tentando criar um aplicativo, obviamente não faria tudo na main, com todo mundo simplesmente enviando alterações para a main e coisas assim. Isso não faz sentido. Acho que, hum, sabe, não sou técnico. Hum, e acho que, de repente, você tem todas essas

10:14 pessoas não técnicas começando a criar aplicativos e se deparando com isso. Sabe, você basicamente comentou algo como: “Ah, cara, às vezes acontece de os agents sobrescreverem coisas.” Quer dizer, a verdade é que, em 95% das vezes, se você estiver criando algo, vai ter agents fazendo bagunça e sobrescrevendo coisas. Então, para mim, isso faz muito sentido e é uma ideia mais ampla, que é: como estruturar, sabe, a maneira como você trabalha com

10:46 agents para que seja mais como uma equipe, em vez de, sabe, sim. Não, simplesmente mais como uma equipe. >> Sim, quer dizer, é um nome melhor. Equipe é melhor do que Isolate. Talvez eu mude para Equipe. [risos] Mas é basicamente isso. >> Bem, é por isso que eu sou o profissional de marketing e você é o, hum, engenheiro. >> [risos] >> Mas, sim, é basicamente isso, certo? Então, é… >> Isolate parece algum tipo de proteína do soro do leite que vou tomar mais tarde. >> Então, se vocês conferirem o link, em breve vai ter um nome. Mas é basicamente isso que ele faz. Ele me permite ter vários agents

11:20 trabalhando em tarefas diferentes ao mesmo tempo, sem que um passe por cima do outro, certo? E também há um processo de limpeza que não vou abordar. Tipo, quando a branch, quer dizer, quando o trabalho é mesclado, a árvore de trabalho é excluída. Esse tipo de coisa acontece. Então, esse é o primeiro passo. O segundo é a construção em si, e acho que isso… Era uma skill que compartilhei originalmente, há bastante tempo, mas agora faz parte do meu workflow e compartilhei com todo mundo: estrutura de código. Vamos falar de modelos em breve, hum, mas uma coisa sobre os modelos é que eles são ótimos para fazer o trabalho. Só que

11:56 talvez o trabalho não fique pronto da melhor maneira, certo? Principalmente ao escrever código. Hum, por exemplo, eu diria que Fable foi um dos primeiros modelos a realmente escrever código que me fez pensar: “Nossa, isso é melhor do que o trabalho de alguns dos melhores engenheiros que já vi, certo?” Tipo, Fable escreve um código muito bom. Mas até Astra, que é um cavalo de batalha, o modelo mais poderoso, meu modelo favorito, toma algumas decisões sobre a qualidade do código que são… hum, não é que o modelo não seja capaz; o modelo simplesmente está fazendo o trabalho. E, se puder terminar de um jeito

12:28 malfeito, vai terminar de um jeito malfeito. O que a skill de estrutura de código faz é escrever o código no que chamamos de arquitetura em camadas de serviço. Não vou entediar todo mundo, mas, basicamente, o código é escrito de uma forma que, digamos, se você precisar de intervenção humana e contratar um desenvolvedor, será muito fácil para ele entender; ou, se você mesmo for desenvolvedor, será muito fácil para você entender. Mas até os seus agents, quando voltarem ao código e o lerem, vão pensar: “Ah, sim, faz sentido.” Tipo, já tive o GPT 5.6, certo, escrevendo código, e ele funciona. Faz o que deveria fazer.

13:01 Mas aí peço para Fable revisar o código, e Fable diz: “Isso está horrível. Tem duplicações, funções espalhadas por todo lado, código morto.” Certo? Então, só porque funciona, não significa que foi bem escrito. Essa skill dá ao agent uma diretriz de como escrever código. Voltando a este diagrama, estou trabalhando em um novo recurso, certo? A primeira coisa que acontece é o isolamento. A segunda coisa que acontece é, e espero que as pessoas estejam percebendo o aspecto de fábrica disso, a segunda coisa

13:32 que acontece é a construção, e nela usamos uma skill chamada estrutura de código. Basicamente, nesse processo, quando digo ao agent: “Ah, crie esta página inicial para mim. Crie este recurso.” Por exemplo, tenho trabalhado neste aplicativo, e o recurso que eu queria criar era um tipo de repositório de skills onde eu pudesse conectar vários dos meus agents a este aplicativo e armazenar as skills. E basicamente disse ao agent: “Crie isso para mim.” E, enquanto escrevia o código, ele continuava consultando a skill de estrutura de código. Então, começou a escrever código de um

14:06 jeito que eu, como desenvolvedor, consigo revisar. Mas, sabe, Deus me livre de precisar contratar alguém para revisar o código: não vai ser aquele canhão de código lixo que deixa a pessoa confusa, sem saber o que fazer, ou que faz cobrarem demais de você. O código é escrito de um jeito que um desenvolvedor consegue entender, e acho que, se você usar outro agent que não tenha contexto sobre seu codebase, ele vai entendê-lo muito bem. Primeiro, isolamos — desculpem pelo nome ruim. Segundo, construímos, certo? E tudo isso é feito de um jeito prescritivo, que permite ao agent

14:38 se mover rápido e fazer o melhor trabalho possível. Acho que faz sentido, certo, Greg? Não? >> Isso mesmo. Continue. >> Então, o terceiro passo é comprovar. O seguinte: hum, sabe, agents não podem fazer uma promessa de dedinho, certo? Então, se você pressionar bastante um agent… Bem, GPT-6 Astra é o motivo de haver um grande salto na capacidade dos modelos: ele é o modelo que menos alucina, o que é fantástico. Mas, deixando esse modelo de lado,

15:10 Dá para levar a maioria dos modelos a meio que mentir ou acreditar em alguma coisa, ou às vezes eles simplesmente dizem: “Ah, na verdade percebi que não fiz esse trabalho para você.” Então, uma coisa que faço o agente provar é o trabalho que ele fez. E esta provavelmente é minha skill favorita. Há duas skills envolvidas nisso: testes orientados por evidências. Basicamente, o que a abordagem orientada por evidências faz é, se sua máquina tiver capacidade para isso, ela literalmente registra o estado anterior, ou seja, antes do recurso, ou digamos que

15:43 você esteja tentando corrigir um bug: ela registra o bug em ação. E depois, quando terminar a correção, registra uma versão funcionando, certo? Então, é isso que os testes orientados por evidências fazem. Eles provam que a correção foi realmente feita. Porque você ficaria surpreso: às vezes, o agente escreve o código e acha que funcionou, mas não testou nem provou que funcionou; simplesmente disse que funcionou. Então, preciso garantir que o agente realmente prove esse trabalho. Mas digamos, digamos que sua máquina

16:16 não tenha capacidade para fazer isso. Há outra skill chamada “antes e depois”. E posso, na verdade, deixar eu abrir um PR para mostrar, certo? Porque acho melhor mostrar do que contar. Este é um PR que meu agente fez. Não fui eu. O agente fez. Eu queria que ele criasse uma página de e-mail de administrador e conectasse um serviço de e-mail que criei. Olhe o que ele fez. Mostrou o estado anterior, em que a página não existia. Simplesmente não existia. E mostra o estado posterior. Certo?

16:50 Então, para cada recurso que estou criando, para cada PR que faço, recebo um estado anterior e um estado posterior. E isso me ajuda, vou ser sincero: hoje em dia não leio todo o meu código. Talvez eu dê uma olhada, tipo: “Ok, ele fez isso, vamos ver…”, mas mal olho. >> É uma passada de olhos. Só uma passada de olhos. >> Vou ser sincero: até essas passadas de olhos estão ficando cada vez mais raras. Mas muitas das coisas que faço agora são no frontend, onde garanto que ele está seguindo minha skill de estrutura de código

17:22 e garanto que recebo capturas de tela do antes e do depois, certo? Posso até abrir… Deixe-me mostrar outro exemplo. Aqui está um exemplo mais significativo: eu estava trabalhando em um recurso específico de computador, queria dar um computador ao meu agente, e simplesmente não funcionou, certo? A primeira tentativa não funcionou. Eu nem sequer tinha [limpa a garganta] minha fábrica de software configurada. Estava trabalhando em outra máquina, e ele enviou o código, mas não funcionou. Como você pode ver, nada acontece. Eu disse ao meu agente que não funcionou, mandei usar as skills, usar a fábrica, e esta é a captura de tela posterior, com ele

17:57 usando o aplicativo de verdade, certo? Então, essas skills, a de comprovação e a de antes e depois, forçam o agente a me fornecer uma comprovação factual do antes e do depois, seja em vídeo ou em capturas de tela. E às vezes ele faz o antes, depois faz o depois e diz: “Ah, acabei de olhar a captura de tela ou o vídeo do depois e, na verdade, não terminei o recurso.” Então, o que ele faz? Volta a construir, certo? Essa é a natureza de fábrica disso. Não precisei dizer: “Ah, isso

18:31 sim, você não passou nos critérios de antes e depois. Vá terminar.” As skills são escritas de um jeito que o agente entende: “Ok, os critérios de antes e depois não foram atendidos. Preciso continuar construindo, certo?” Então, isso me dá uma representação visual do trabalho que foi feito. Facilita a revisão, especialmente se você não for uma pessoa técnica. Facilita a revisão porque, sabe, basta olhar algumas capturas de tela ou um vídeo, certo? Então, durante o processo de construção, em algum momento vou ter um PR em que consigo ver o antes e o depois. E, mesmo que talvez eu não entenda toda essa baboseira

19:03 técnica, isso vai me explicar, vai me mostrar uma comprovação visual de que o trabalho foi feito. Agora, já ouço alguém perguntando: “E se a comprovação não for visual?” Na verdade, há um PR que vou mostrar, sobre desempenho. Acho que é este. Certo, queria dar outro exemplo aqui. Queria fazer uma atualização de desempenho. Ou seja, em um dos aplicativos que estava desenvolvendo, os cliques não respondiam com rapidez suficiente. Como dá para ver agora, tudo responde rápido,

19:35 está carregando rápido. Antes não era assim. Então, eu disse ao agente: “Corrija isso.” E ele corrigiu. Ele acabou me dando capturas de tela também, mas digamos que fosse algo para o qual não pudesse me dar capturas de tela. Ele escreveria testes e depois me daria os resultados. Neste caso, verificou a velocidade de carregamento da página antes. Uma das páginas levava 850 milissegundos. Isso é um pecado no desenvolvimento web. Isso não pode acontecer. E, veja bem, isso foi escrito pelo GPT-5.6 soul, certo? Um ótimo modelo.

20:07 Mas ele reduziu o tempo para 60. 817, 61. Então, mais uma vez, tenho uma comprovação concreta do agente de que ele fez o que disse que fez, no processo de revisão. Vou parar por aqui. Esqueci alguma coisa até agora, Gregor? Isso… >> Então, sabe, se você está tentando construir uma fábrica de software, obviamente a confiança vai ser uma parte importante disso. E acho que o que você está dizendo é: “Olha, se você vai ter todos esses agentes construindo recursos, construindo aplicativos, precisamos poder confiar nas coisas que eles vão criar.” Então, o que você está dizendo é: aqui estão algumas skills que permitem a você, como gerente do agente — neste caso, Mickey, você é o gerente do agente, certo? Você não está mais mergulhado no código. Está meio que só acompanhando o que está acontecendo. E o legal dessas coisas visuais de antes e depois é que elas são boas para millennials e para a geração Z, ou para quem usa stories do Instagram ou do Snap, coisas assim. É quase como se você

20:38 estivesse simplesmente passando de um story para outro. Sim, sim, não. É tudo bem… em pequenas porções. >> Basicamente, é exatamente isso, certo? Isso me permite criar confiança no agente, porque… E o engraçado é que, como você disse antes, isso meio que me fez perceber. É isso que organizações normais costumavam fazer com os engenheiros, certo? Você criava um recurso e havia alguém, como um engenheiro sênior, cujo trabalho era revisar o que você fez. Você tinha esse PR com uma descrição mostrando: “Ok, basicamente, este é o trabalho que

21:09 fiz e estes são os testes que escrevi”, certo? Então, é basicamente a mesma coisa, só que agora fazemos isso com máquinas. Isso é essencialmente um exemplo do vídeo. Hum, este é… Este sou eu usando os agents na nuvem do Cursor. Diz “comprovação de melhoria” e este é um vídeo do agente trabalhando e usando o aplicativo, certo? Então, isso me permite, como você disse, no estilo do Instagram, do TikTok, assistir e ver: “Certo, ok, o agente realmente construiu isso e funciona.” Isso facilita para eu

21:41 não precisar ler código e simplesmente aprovar tudo, viver a vida do jeito que quero, sair e tocar na grama. Então, é isso. Agora temos uma etapa final, que é a etapa de entrega. Já mencionei o antes e o depois, mas há esta skill chamada Grep Loop, que usa um serviço de terceiros chamado Greptile, que é um agente de revisão de código. Você não precisa usar um agente de revisão de código, mas, se leva a sério a criação de software e ele vai ser usado por usuários, recomendo muito usar algum agente de revisão de código. Greptile é meu favorito; Code Rabbit, Macroscope, tem…

22:14 não precisar ler código e simplesmente fazer os merges, viver a melhor vida possível, sair e curtir a natureza. Então, é isso. Agora, temos uma etapa final, que é a etapa de envio. Já mencionei a etapa de envio antes e depois, mas existe esta skill chamada Grep Loop, que usa um serviço de terceiros chamado Greptile, que é um agent de code review. Você não precisa usar um agent de code review, mas, se leva mesmo a sério o desenvolvimento de software e ele vai ser usado por usuários, recomendo muito usar algum agent de code review. Greptile é meu favorito; também há CodeRabbit e Macroscope, tem

22:48 Há muitas boas por aí. Mas eu uso o Greptile, e eles têm uma skill chamada Grep Loop. Basicamente, o que ela faz — e acho que vou mostrar isso com este PR — é que o Greptile deixa esses resumos e depois dá feedback. Por exemplo, este foi o feedback inicial que ele deu sobre o PR. Havia um problema, sabe, com a paginação aqui. O espaço de algum menu não foi preservado. Então, ele deu esse feedback, o que significa que o agent que escreveu o código deixou passar essas coisas. E tudo bem. Acontece, né? Até

23:20 humanos deixam essas coisas passar, né? Mas o que acontece é que o Greptile não só dá feedback, como também dá uma pontuação de confiança. Agora, esta é cinco de cinco porque, depois que o feedback foi dado, se você olhar meu nome e esta linha aqui, o feedback foi atendido. Meu agent atendeu ao feedback. Mas, antes de o feedback ser atendido, essa pontuação era três de cinco. Isso mostra ao meu agent que há coisas que ele deixou passar e que precisa verificar. O que a skill Grep Loop faz — e, aliás, isso acontece automaticamente. Ninguém precisa

23:51 escrever “Grep Loop”. O agent faz isso automaticamente. O que ele faz é o seguinte: ele abre o PR com a comprovação do antes e depois incorporada à descrição. Sempre que a mudança tiver algo visível, números medidos ou pares de resultados. Quando não tiver, ele vai mostrar números, né? Ou uma captura de tela. E aí veja o que o agent faz. Ele executa Grep Loop ou Grep Loop Ops. A diferença é que o Grep Loop Ops é ativado se a alteração no arquivo tiver mais de 10.000 linhas. De novo, você não precisa se preocupar. O agent faz isso sozinho. Mas veja o que ele faz. Ele diz:

24:22 “O Greptile informa cinco de cinco até que os comentários sejam resolvidos. Conclui apresentando o URL do PR.” Basicamente, isso significa que ele vai… O agent vai pegar o feedback que recebeu. Vai voltar para a etapa de construção. Então, veja só. Digamos que estamos no ponto — deixa eu anotar isso. Estamos no ponto em que estamos na construção, em que estamos na… entrega, né? E agora ele está executando o Grep Loop. Quando recebo uma pontuação de feedback, uma pontuação de confiança, e ela é três de cinco, o que acontece agora? Lembra que estávamos falando de loops? Este é, na verdade, um bom loop. O que acontece é que ele volta para

24:57 a construção. Agora o agent volta para a etapa dois. Começa a construir. Depois de construir, o que ele faz? Ele comprova e depois entrega. E é isso que acontece. Automaticamente, os agents aguardam uma nova pontuação. O Greptile então nos dá quatro de cinco. Encontramos algumas coisas, mas deixamos passar uma última. Volta para a construção, né? Ele constrói, comprova e adivinha o que faz, Greg? Entrega. E agora tenho cinco de cinco. Quando tenho cinco de cinco, o que

25:28 falta agora é eu fazer o merge. Acho que talvez eu tenha um PR aberto aqui, então posso mostrar como é. Só falta eu clicar em “merge”. Quando clico em “merge”, ele finalmente volta para a cópia principal do app, para a versão principal do app. E fiz isso enquanto trabalhava em 15 versões simultâneas… quer dizer, funcionalidades. 15 funcionalidades diferentes. Com

25:58 agents diferentes, subagents, todo esse tipo de coisa. Isso permite — e é aí que entra a natureza de fábrica — que um agent tenha uma instância isolada na qual possa trabalhar por conta própria. Ele tem diretrizes sobre como construir. Tem uma metodologia para comprovar o próprio trabalho. E então tem um serviço externo que comprova o trabalho dele, que verifica o que ele fez. E, se o trabalho não estiver dentro do padrão, ele precisa continuar em um loop, trabalhando até que esse padrão seja alcançado. Quando recebo cinco de cinco, é aí que eu entro em cena.

26:29 É isso que é uma software factory. Repare que não falamos sobre modelo. Não falamos sobre harness. É tudo workflows, skills e um pouco de conhecimento de domínio, né? Nem todo mundo trabalha da mesma maneira. É assim que eu trabalho. Mas tenho tido ótimos resultados com isso. Vou pausar por aqui, Greg. Me diga o que preciso explicar melhor ou acrescentar. >> O que está se encaixando na minha cabeça é justamente essa analogia física de uma fábrica para uma software factory. Então, só para resumir,

27:01 vou contar como estou entendendo e quero saber o que você pensa. Então, a parte de isolar, na etapa um, é como uma fábrica recebendo um pedido personalizado e, sabe, destinando a ele uma estação própria para não atrapalhar o restante da produção, certo? Então, você chamou isso de work tree; em software, é um branch, uma work tree em um ambiente isolado, mas, sabe, esse é o conceito básico. >> Sim. >> Número dois: construir, né? Construir é a linha de montagem. Então, o agent está

27:32 de fato cortando, soldando, montando e conectando os fios do produto. Obviamente, em software, você não está fazendo isso. Está escrevendo código, alterando arquivos, adicionando estrutura às coisas. Você está realmente criando algo que é real no sentido de software. A terceira etapa é a comprovação, que é basicamente um jeito sofisticado de dizer controle de qualidade. >> Basicamente, sim. >> Basicamente, né? Tipo, antes de qualquer coisa sair da fábrica, alguém precisa testá-la. Você não vai simplesmente criar um produto e não pedir que as pessoas o testem.

28:05 Tipo: ele liga? Ele… encaixa? Quebra sob pressão? Todas essas coisas. Sabe, estou imaginando uma fábrica de carros ou algo assim. Em software, você pode executar testes… Bem, pode executar testes, visualizar uma prévia, consultar logs e, sabe, usar as capturas de tela que você mostrou. E, por último, a parte da entrega: basicamente, quando passa pelo controle de qualidade, sai pela porta. Mas

28:36 há algumas coisas que você precisa, sabe… Você vai precisar fazer o merge. Vai precisar fazer o deploy do PR. Vai precisar escrever notas da versão. Vai precisar, sabe, dar feedback para a equipe de produto, porque talvez não passe pelo controle de qualidade e aí você tenha que repetir esse loop, né? >> Exatamente. Acho que talvez eu vá renomear tudo que escrevi para usar os nomes que você falou, porque agora estou percebendo: “Ah, sim, meus nomes são péssimos.” Sabe, o que o Greg diz faz sentido. É exatamente assim que funciona.

29:09 >> Legal. Então, basicamente, o que estamos fazendo aqui é pegando uma fábrica e transformando-a em uma software factory. >> Basicamente. E é por isso que, de novo, sem querer desmerecer startups, produtos e coisas do tipo, uma software factory não é um produto. Não é um harness especial. Não é tipo: “Ah, esta empresa criou um software…” Não. Uma software factory é literalmente só um monte de arquivos Markdown. E outra coisa absurda, talvez para outro vídeo, fora do assunto, é que algumas startups agora são um agent com alguns arquivos Markdown.

29:39 Né? Realmente chegamos a esse momento. Então, espero que isso faça sentido para todo mundo e deixe todos animados. Estou muito empolgado com o momento em que estamos, porque agora muita coisa é possível. >> Com certeza. Quer dizer, não, isso é… é absurdo que você realmente consiga fazer isso. É legal que pessoas como você compartilhem isso, porque acho que vale a pena. Só quero fazer uma observação rápida sobre o Grep Loop ou qualquer software de revisão de código. Sabe, acho que, se você leva a sério, sem nenhuma ligação com o Grep Loop ou

30:12 algo assim, acho que, se você leva a criação de software a sério, ter algum software de revisão de código é bem… não entendo por que você não usaria o Grep Loop ou o Code Rabbit, uma dessas ferramentas. >> Alguma coisa, né? Faz sentido. Porque, de novo, se você… sabe, nós, nos negócios — e eu sei disso porque muita gente de negócios está assistindo — levamos a sério o serviço que oferecemos e todas essas coisas, mas parece que, quando se trata de criar software, simplesmente não nos importamos, né? E, se você

30:43 pessoas que vão usar seu app. Tipo, não sei, existe um certo nível de empatia que eu tenho pelo usuário do outro lado. E, sabe, gosto de muitas dessas startups porque elas levantaram um zilhão de dólares; elas têm muitos planos gratuitos. Você pode alternar entre planos gratuitos e usar um monte dessas coisas de graça, certo? Então, recomendo muito que, se você estiver criando algo com que realmente se importa e pelo qual é apaixonado, use algum tipo de agent de revisão de código. >> Sim. Legal. Obrigado por participar. Obrigado por compartilhar os macetes. Vou incluir links de onde acompanhar o Mickey na internet, no

31:16 YouTube, em todos esses lugares, e também do software que ele está criando. Vão lá e sigam ele. Cara, até a próxima. >> Agradeço a você, Greg, como sempre. Obrigado a todos pelo carinho e por assistirem. E, sim, nos vemos no próximo.

Transcrição original

[00:00] What are software factories and why is it going viral? I mean, it’s basically this concept that allows you to use AI agents to actually ship software that isn’t sloppy at all, that is more like a factory, more like think about an assembly line and you’re just instead of building physical products, you’re building software. And that’s kind of the dream. I mean, if you’re able to just create this factory that builds software and it’s valuable software and you can create multiple apps that generate revenue and add value to

[00:31] people’s lives, that sounds pretty good to me. So, on today’s episode, I brought on Ross Mike and he clearly explains the entire process. [music] By the end of this episode, you’re going to understand how to set your own software factory up yourself. [music] So, enjoy the episode. I can’t wait to see what you build. There’s a reason why this concept is going viral and I’ll see you at the end. Today’s episode is brought to you by Brex. My company’s been on Brex for a year and a half and I started because I kept hearing companies like Vercel, OpenAI, and Anthropic were using Brex and I figured if they’re

[01:01] using it, why shouldn’t I? It’s been a game-changer. The thing that got me is how smooth it is. It’s got high-limit cards, it’s got banking, it’s got AI that handles the back office busywork like expense reports, which I don’t want to do, on its own. It’s really just built for this agentic world. If you’re building something new, it’s time to get Brex. Check it out at brex.com/solutions/startups. Link in the description. >> The startup by the contrast. [music] We’re sipping time, baby.

[01:35] >> Mickey, welcome back to the pod. By the end of this episode, what are people going to learn? >> We’re going to understand what this bizarre phrase software factory means. I’m actually going to show you how I run mine. It’s a lot easier than you think and it’s definitely model and harness agnostic, so you don’t have to purchase some different product to have a software factory. It’s going to be fun and it’s going to be simple. >> Okay, so you’re going to explain what it is, why it matters, how it works, how to think about it. By the end of this, people are just going to be able to boot up their own software factory if they want, or if they think, “You know

[02:07] what? This Ross Mike guy, I don’t I don’t I don’t I don’t like software factories. I don’t like what he’s saying.” They can pass. >> 100% 100% With the term software factory, there’s been a lot of like startups who have started, and you know, I’m not here to knock anyone’s hustle. Um but a software factory is completely harness and model agnostic, meaning it doesn’t matter what model you use, it doesn’t matter what harness you use. Um it should work, right? Because a software factory is more about someone’s workflow, skills, and domain knowledge, and it’s packed up

[02:42] in specific skills that they use in their development process. Now, I want everyone to think like the last app that they built. You probably went on Codex, Claude Code, Cursor, whatever it is, and you just typed, right? You said, “I want to build this.” And it built it out for you, you saw it, and you didn’t like it, and then you made some changes, right? And you saw the changes, maybe you liked it, you deployed it to Vercel or to production, and you’re good to go, or you keep kept on iterating. That’s the process. The whole point of a software factory is in each step of the development process, how can I best

[03:16] maximize the model’s capability to get the greatest output, right? And also, how can I move fast, right? Because if we’re using the term factory, there’s some sort of structure and speed and conveyor belt nature that allows me to ship as quick as possible without losing quality. That’s the long bloated Mike Schmollis translate definition of software factory. Um I haven’t lost anyone, hopefully, Greg. >> That was perfect. Okay, so understood, but like why does that matter? >> The reason why it matters is um

[03:49] intelligence is continuing to increase. We have amazing models like GPT-6 Astra. A good software factory allows you to systematize and use these models in a very efficient way versus just typing in and continuing to go back and forth. And I think it’s better I just show you how mine works to give people an idea. Now, I’ll give my skills are available for free, no charge, nothing like that, but I don’t want you to blindly copy me. I would like for you to think about it, understand the process, and then apply

[04:20] it yourself. That being said, I have about five or six files that make my software factory. I have an agents.md file, and for everyone who might not be aware with her age what an agents.md file is, it’s basically this one document, this one markdown file that’s injected into the system prompt. That’s inject Sorry, not in the system prompt. That’s injected into the agent chat every time you communicate with an agent. So, every time I say hi, if there’s an agents.md file before the hi is sent, the agents.md file is sent. And what’s cool about this file is I can

[04:53] sort of dictate how I want the agent to act. And we actually did a video not too long ago, Greg, where I talked about most people’s agents.md file is useless because they were telling the agents.md file what the code looked like and already information that’s in the code base that the agent could already know about. But if you look at mine, there’s a simple workflow, and this workflow is something that’s not native to the agent, so it explains clearly how to do it. And I’ll walk you through every single step. The first step is isolate. There’s a skill called new feature, and this is

[05:27] what it does. It says, “Every new feature starts in a fresh Git work tree branched from origin main, so agents can work in parallel without conflicts. Never build on main.” And if you know when Michael is on Greg’s channel, there’s always diagrams. So, we’re about to draw. So, with the first step when I’m working on a project and I tell it to work on a feature, the first thing it’s going to do is isolate. And what this basically means is you can think of uh Greg and Mike’s app. You can think of

[06:00] Greg’s and Mike app like the journey being, you know, we started here, we started prompting here, and this is when we launched the production, we’ve got thousands of customers. The way most people uh work with their agents is at every single step of the journey, they’re building a feature, they’re building a feature, they’re building a feature, and it’s it’s a very linear process, right? One feature at a time, one feature at a time, one feature at a time. And if you ever try to work like like with on multiple features the same time, sometimes there’s conflicts, there’s

[06:32] issues, people have, you know, oh, my agent deleted this file, it overwrote this file. What this first step, isolate, does is the following. I’m going to show via diagram. So, let’s say Greg was like, I really don’t like our landing page. And I’m telling Greg, you know, our um our API calls can be faster. When Greg works on his feature, what the agent does using my agents.md, is he’s going to create a new branch. And you can think of a branch as a copy-paste of

[07:02] the exact moment where the app is. So, Greg is going to work on a new branch, a new work tree of the app. A work tree is basically a copy of the app, like you can think of someone copying a block of text, pasting it in a new document, working on that document, and at some point going to merge it back in the original document. So, that’s what Greg is doing. He has a new document working on that feature. And guess what? Mike has another feature has to work on. So, I can do it at the same time, or I can do it at a different

[07:33] time. I now have my own branch. Here’s what’s cool. Me and Greg and another person, or you yourself with 50 different agents can work on multiple features, and there’s not going to be an issue of one agent overstepping on another agent’s work. This happens a lot to people. If you ever see tweets, Greg, of people saying, “Man, like I was working on this, and the agent deleted a bunch of stuff.” Almost always, it’s because people have their agents working on different features on the same branch.

[08:06] And the agent will do what you tell it to do. So, you told it to update the landing page, but then you also told it to make the API calls faster, and now it’s noticing, “Oh, these pages, the way they’re calling the API suck. Let me delete these and write these again.” But then it was working on a design on that page. So, issues start to arise. Isolate allows me to work on multiple features at the same time, parallelly, without having an agent overstep on an agent. This is the first step of my workflow.

[08:36] This isn’t native to the agent. So, this makes sense to exist in um the uh Greg is done, or when I’m done, and I’ll explain like the workflow for this, but just to close the loop, when Mike’s done, all I do is merge these changes back. And then when Greg’s done, he can either do it before me, or he can do it after me. But we’re merging into the into the main document, and there’s not going to be conflicts cuz we worked on a copy at first. So, this allows me to ship fast with

[09:11] multiple agents. If I show you and I can maybe show here. If I show you my terminal, if you notice there’s four tabs of Bezel uh three of them finished, but I literally have four different features on the same exact app. One’s working on an email client, the other one is working on uh a computer environment, a Linux environment, the other one is doing a landing page update. So, I can work on these confidently while still having isolation. It’s not native to the agent. This agents.md plus the new feature

[09:44] skill allows me to do that. I’ll pause here. Any questions back so far? >> Yeah, I mean it’s like crystal clear. I think it’s if the way I think about it is if you actually had a team of engineers and you were trying to build an app, you obviously wouldn’t be building it all on main and and having everyone just being pushing to main and stuff like that. That just doesn’t make sense. I think um you know, I’m non-technical. Um and I think you have all of a sudden all these

[10:14] non-technical people starting to build apps and they’re running into this. Uh you know, you you basically made mention you’re kind of like, “Oh hey man, like sometimes it happens that agents override stuff.” I mean, the truth is 95% of the time if you’re build it you’re going to have agents kind of mess up and and override things. So, this is like to me this is you know, makes a lot of sense and it’s sort of a bigger idea which is how do you structure your you know, the way you work with

[10:46] agents to be more like a team versus uh you know, yeah. No, just more like a team. >> Yeah, I mean and I I mean it’s a better name. A team is better than isolate. I might change it to the team. [laughter] But that’s basically >> Well, that’s why I’m the marketer and you’re the uh the engineer. >> [laughter] >> But yeah, that’s basically what it is, right? So, it’s >> Isolate sounds like some sort of like whey protein that I’m going to drink later. >> So, if you guys check the link, there will be a name of it very soon. But that’s basically what this does. It allows for me to have multiple agents

[11:20] working on different tasks all of the same time without overstepping each other, right? And there’s also a cleanup process I won’t get into. Like once the branch like once the work is merged in, the work tree gets deleted. All that type of stuff happens. So, that’s step number one. Number two is the actual building, and this I find has This was a skill that I I shared originally way back, but now it’s part of my workflow and I shared with everyone, is code structure. We are going to talk about models soon, uh but one thing about uh the models is they are great at doing the work. It

[11:56] just might not be done the best way, right? Especially when writing code. Um there’s, for example, Fable is I would say one of the first models to really write code that I would say, “Huh, like this is better than some of the best engineers I’ve seen, right?” Like Fable runs writes really good code. But even Astra, which is workhorse, most powerful model, my favorite model, some of the code quality decisions it makes is uh and it’s not that the model’s not capable, the model’s is just getting it done. And if it could get it done in a

[12:28] sloppy way, it’ll get it done in a sloppy way. What the code structure skill does, it writes it in what’s called a service layer architecture. Won’t bore everyone, but basically it’s written in a way where let’s say you had you needed human intervention, you hired a developer, very easy for the developer to catch on, or you yourself are a developer, very easy for you to catch on. But even for your agents, for them to come back to the code and read the code, they’ll be like, “Oh, like yeah, like it makes sense.” Like I’ve had like I’ve had GPT 5.6 all right code and it works. It does what it’s supposed to do.

[13:01] But then I’ll have Fable review the code and Fable will be like, “This is disgusting. Like there’s duplications, there’s functions all over the place, there’s dead code.” Right? So, just because it works doesn’t mean it’s written well. This skill gives the agent a guideline on how to write code. So, going back to this diagram again, I’m working on a new feature, right? The first thing that happens is isolate. The second thing that happens is and I’m going to I hope people are seeing the factory nature of it. The second thing

[13:32] that happens is the building and in building we’re using a skill called code structure. And basically in this process when I’m telling the agent, “Oh, build me this landing page. Build me this feature.” For example, I’ve been working on this app and the one feature that I wanted build is I wanted a skills like repository where I can have different agents of mine connect to this app and store the skills. And I basically told the agent, “Build me that.” And as it was writing the code, it kept referencing the code structure skill. So, it started to write code in a

[14:06] way that me as a developer, I can review. But, you know, God forbid I need to hire somebody to review the code, it’s not going to be the slop cannon where they’re confused and they don’t know what to do or they overcharge you. It’s written in a way for a developer to understand and I find that if you use another agent that doesn’t have context on your code base, it will understand it very well. So, first we isolate, excuse the bad name. Second, we build, right? And all of these are done in an opinionated way that allow the agent to

[14:38] move fast and to do the thing as best as possibly can be. I think this makes sense, right Greg? No? >> Yep. Keep going. >> So, step number three is prove. Here’s the thing. Um, you know, agents can’t pinky promise, right? So, like if you push an agent enough, well, GPT-6 Astra is the reason why it’s a big leap in model capability is like it like the like it is the least hallucinating model, which is fantastic. But like that model aside,

[15:10] most models you can kind of push to like lie or to believe something or sometimes will straight up be like, “Oh, I actually realized I didn’t do this work for you.” So, one thing that I have the agent prove the agent do, is to prove the work that it did. And this is probably my favorite skill. There’s two skills involved in this, evidence-driven testing. And basically, what evidence-driven does, if your machine has the capability to do it, it will literally record the before state, meaning before the feature, or let’s say

[15:43] you’re trying to fix a bug, it will record the bug in action. And what it will do after is after it’s done fixing, it will record a working version after, right? So, this is what evidence-driven testing does. It proves that the fix actually was made. Because you’ll be surprised sometimes the agent will write the code and it will think it worked, but it didn’t test it or it didn’t prove that it worked, and it just told you it worked. So, I need to make sure that the agent actually proved this work. But let’s say, let’s say your machine

[16:16] doesn’t have the capability to do that. There’s another skill called before and after. And I can actually, let me pull up a PR to show this, right? Cuz I think it is better show you than I tell you. This is a PR my agent made. I didn’t make this. The agent made this. And I wanted it to create an admin email page and connect an email service that I made. Look at what it did. It showed me a before state where the page didn’t exist. It just It didn’t. And it shows me the after state. Right?

[16:50] So, for every feature that I’m building, every PR that I’m doing, I am getting a before state and after state. And the reason why this helps, this helps me like, I’ll be honest, I’m not reading all my code nowadays. Like, I might like, okay, it did this, like, let’s see, like like barely. >> It’s a skim. It’s a skim situation. >> I’ll be honest, the skims have even become less and less now. But a lot a lot of the things that I’m doing now is I’m working on the front end where I make sure that it’s following my code

[17:22] structure skill, and I make sure I’m getting before and after screenshots, right? I can even pull up Let me pull up another um example. Here’s a more prominent example where I was working on a specific uh computer feature where I wanted to give my agent a computer, and it just didn’t work, right? The first run didn’t work. Um I didn’t even have [clears throat] like my software factory set up. I was working on a different machine, and it pushed the code, and it didn’t work. As you can see, nothing’s going on. I told my agent it didn’t work, use the skills, use the factory, and this is the after screenshot with it

[17:57] actually using the app, right? So, these skills, the proof and the before and after, force the agent to give me factual like a before and after proof, whether it’s a video or it’s screenshots. And there are times where it’ll do the before, but then it’ll do the after, and it’ll be like, “Oh, I just looked at the after screenshot or the after video, and I didn’t really finish the feature.” So, it’ll go back to what? It’ll go back to building, right? This is the factory nature of it. I didn’t have to tell it, “Oh, that

[18:31] yeah, you failed your before and after. Go finish the the the skills are written in a way where the agent knows, okay, the before and after criteria hasn’t been met. I have to go continue on building, right?” So, this gives me a visual representation of the work that’s been done. It makes reviewing, especially if you’re a non-technical person, it makes reviewing easier cuz, you know, I just look at some screenshots or video, right? So, in the building process, at some point, I’ll have a PR where I get to see the before and after, and even though I might not understand all this mumbo

[19:03] jumbo, it it will it will explain it will show me visual um proof that the work’s been done. Now, I already hear somebody asking, “What if the proof is not visual?” And there’s actually um a PR I’ll show some on performance. I think it’s this one. Okay, so I wanted to do another example here. I wanted to do a performance update. Meaning, for one of the apps I was building, the clicks weren’t snappy enough. Like you could see now, everything is snappy,

[19:35] it’s loading and fast. That wasn’t the case. So, I told the agent, “Fix it.” And it did. And it did end up giving me screenshots, but let’s say there This is like something that it couldn’t give me screenshots for. It will write test, and then it’ll give me the results. In this case, it checked the speed at which the page was loading before. In this case, one of the pages 850 milliseconds. This is a sin in web development. Like this cannot happen. And mind you, this was written by GPT-5.6 soul, right? Great model.

[20:07] But it got it down to 60. 817 61. So, I have again actual proof by the agent that it’s done what it said it did in the review process. I’ll pause right there. Anything I’ve missed so far, Gregor? Does it >> So, you know, if you’re trying to build a a software factory, trust obviously is going to be a big part of that. And I think what you’re saying is, “Hey, we’re if you know, you’re going to if you’re going to have all these agents, you know, building features, building apps, we

[20:38] need to be able to trust the things that it’s going to create.” So, what you’re saying is uh here are a couple skills that allow you as like the agent manager, where in this case, Mickey, you’re like you are the agent manager, right? You’re not you’re you’re not deep in the code anymore. You’re kind of just looking at what’s happening. And what’s cool about um the before and after visual stuff is it’s kind of good for um you know, millennials and Gen Z or people on, you know, Instagram stories or Snap stories, stuff like that. It’s almost like you’re

[21:09] just like clicking through story to story. Yes, yes, no. Like it’s it’s it’s bite-size. >> Basically, that’s literally it right there, right? It’s it’s allowing me to build trust with the agent cuz and what’s funny is like you said it earlier and it kind of clicked in my head. This is what like normal organizations used to do with their engineers, right? It’s like you build a feature and then there was someone whose job, like a senior engineer, whose job was to review your work and you would have this PR with this description and it would show, okay, basically this is the work that

[21:41] I’ve done and this is the test that I’ve written, right? So, it’s basically the same thing except now we’re doing it with machines. Like that’s essentially an an example of the video. Um this is a This is me using Cursor Cloud agents. It says proof of improvement and like this is a video of the agent at work using the app, right? So, this allows me to your point, like Instagram, Tik Tok, I I can watch this and see, all right, okay, the agent actually built this and it works. This makes it easy for me to

[22:14] not have to read code and I can just merge away and live my best life and go outside and touch grass. So, there’s that. Now, we have one final step, which is the ship step. Now, the ship step I mentioned before and after, but there’s this skill called Grep Loop, which uses a third-party service named Greptile, which is a code review agent. Now, you don’t need to use a code review code review agent, but if you’re really serious about building software and it’s going to be used by users, I highly suggest using some code review agent. Greptile’s my favorite code code rabbit, macroscope, there’s

[22:48] tons of good ones out there. But me using Greptile, they have this skill called Grep Loop. And basically what this does and I think I’ll show it with this PR. Greptile leaves these summaries and then it gives feedback. For example, this was the initial feedback it gave on the PR. There was some issue with, you know, pagination right here. Some menu space wasn’t preserved. So, it gave this feedback, meaning the agent that wrote the code missed these things. And that’s fine. It happens, right? Even

[23:20] humans miss these things, right? But what happens is Greptile not only gives feedback, it gives a confidence score. Now, this is a five out of five because after the feedback was given, if you see my name and then this line over here, the feedback was addressed. My agent addressed the feedback. But before the feedback was addressed, this score was a three out of five. What that tells my agent is that there are things that it missed, and it needs to look at it. What the Grep loop skill does, and by the way, this happens automatically. Someone doesn’t have to

[23:51] write Grep loop. The agent will do it automatically. What it does is as follows. It says it opens the PR with the before and after proof embedded in the description. Whenever the change has a visible surface, measured numbers or output pairs, when it doesn’t, it’ll give you numbers, right? Or screenshot. And then look what the agent does. It runs Grep loop or Grep Grep loop ops. The difference is Grep loop ops, if your file change is like 10,000 lines plus, um that skill activates. Again, you don’t have to worry. The agent does it itself. But look what it does. It says,

[24:22] Greptile reports five out of five until resolved comments. Finished by presenting PR URL. Basically, what this means is it will The agent will take the feedback it it got. It will go back to build. So, check this out. Let’s say we’re at the point, let me write this down. We’re at the point where at build, where at um ship, right? And it’s now running Grep loop. When I get a feedback score, confidence score, and it’s three out of five, what now happens, remember we were talking about loops? This is actually a good loop. What happens is this goes back to

[24:57] building. Now the agent goes back to step two. It starts to build. After it builds what it is what does it do? It proves and then it ships. And here’s what happens. Automatically the agents will wait for a new score. Reptile then gives us a four out of five. We caught some things but there’s one final thing we missed. Go back to building, right? It builds, it proves, and guess what it does, Greg? It ships. And now I have a five out of five. When I have a five out of five, what’s

[25:28] left now is for me to merge. And I think maybe I have a open PR right here so I can show you what that looks like. What’s left for me is to just click merge. When I click merge, what happens is this is finally back in the main copy of the app of the main version of the app. And I did this while working on 15 either simultaneous version Sorry, features. 15 different features. With

[25:58] different agents, sub agents, all that type of stuff. What this allows, and this is the factory nature, it allows for an agent to have an isolated instance where it can work on its own. It has guidelines on how to build. It has a methodology to prove its work. And then it has an external service proving its work checking its work. And if its work is not up to standard, it has to continue in a loop working until that standard is met. Once I get a five out of five, this is when I enter the picture.

[26:29] This is what a software factory is. Notice we didn’t talk about model. We didn’t talk about hardness. It’s all workflows, skills, and a little bit of domain knowledge, right? Not everybody works the same. This is how I work. Um but I found great results with this. I’ll pause right here, Greg. Let me know what I need to further explain or um or add on. >> I I’m like what’s clicking in my head is just really this physical factory analogy for a software factory. So, just to like summarize, I’m

[27:01] going to tell you how I’m I’m seeing it and I want I want your thoughts. So, like the isolate piece in the step one, um that’s like [clears throat] a factory taking a custom order and, you know, giving it its own station so it doesn’t mess with the rest of production, right? So, you you you know, you called it a work tree, you know, in software it’s a branch, a work tree in isolated environment, but you know, that’s the basic concept. >> Yes. >> Number two, uh build, right? Build is the assembly line. So, the agent is

[27:32] actually like cutting and welding and assembling and wiring the product. Um obviously in software, you’re not doing that. You’re writing code, you’re changing files, you’re adding structure to things. You’re You’re actually creating something that’s real in a software in a software sense. Um step three is the proving step, which is basically a fancy way of saying quality control. >> Basically, yes. >> basically, right? Like before anything leaves the factory, someone has to test it. You’re not just going to like create a product and not have people test it.

[28:05] Like does it turn on? Does it Does it fit? Does it break under pressure? Like all the things. I you know, I’m I’m picturing like a car factory or something like that. In software, you know, you can run tests like Well, you can run tests, you can preview it, you can do logs, you and you know, the screenshots you showed. And then lastly, the shipping piece, um it’s basically like once it passes quality control, you know, it’s going out the door. Um

[28:36] But there’s going to be some things that you have to like let, you know, uh you’re going to have to merge it. You’re going to have to deploy the PR. You’re going to have to do release notes. You’re going to have to, you know, s- give feedback back to the product team because maybe it doesn’t pass quality control and then you have to like do that loop again, right? >> Exactly. I think I might actually rename everything you like I’ve written to what you said cuz like now I’m realizing like oh yeah, my names are terrible. You know, what Greg says makes sense. That’s exactly how this works.

[29:09] >> Cool. So basically what we’re doing here is we’re taking a factory and we’re making a software factory. >> Basically. So and this is why like I’ve seen again not to knock people startups and and products and stuff like that. Like a software factory is not a product. It’s not a special harness. It’s not a like oh this company built a software No, a software factory is literally just a bunch of markdown files. And this is also another insane thing off topic maybe a different video is some startups are now an agent with a

[29:39] couple markdown files. Right? We’ve really entered that time. So I hope this makes sense for everyone and this excites everyone. I’m very excited with the time we’re in right now cuz a lot of things are possible now. >> 100%. I mean no, this is this is insane that you’re actually able to do this. It’s cool that you people like you are like sharing this cuz I think it’s it’s worthwhile. I want to just do one quick note on Grep Loop or any code review software. You know, I think if you’re serious, you know, no affiliation with Grep Loop or

[30:12] anything like that, but I think if you’re serious about creating software, having you know, some code review software is pretty like I I don’t understand why you wouldn’t use a Grep Loop or Code Rabbit, one of these tools. >> Something, right? Like it makes sense. Like cuz again, if you have like you know, we in in business and then I know cuz a lot of business people are watching, you know, we take the service we provide and all that stuff seriously, but it seems like with building software like we just don’t care, right? And if you have

[30:43] people who are going to use your app, like I don’t know, like there’s a level of like empathy I have for the user on the other side, and you know, I like a lot of these like startups because they’ve raised bajillions of dollars, like they have a lot of free tiers, like you know, you can cycle through free tiers and use a bunch of this stuff for free, right? So, I highly encourage, if you’re building something that you’re serious, you’re passionate about, I would use a code review agent of any kind. >> Yeah. Cool. Thanks for coming on. Thanks for sharing the sauce. I’ll include links for where to follow Mickey on the internet, on

[31:16] YouTube, all those places, his his software that he’s creating, too. Go give him a follow, and dude, I’ll see you next time. >> I appreciate you, Greg, as always. Thank you, everyone for showing love and watching, and yeah, we’ll see you in the next one.