Construí a fábrica de software mais simples (você pode copiá-la)

Ver no idioma original →

Autoria: Leon van Zyl · 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: I Built the Simplest Software Factory (You Can Copy It) · Canal: Leon van Zyl · 27:12 · Assistir no YouTube

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

Resumo

Leon van Zyl apresenta uma fábrica de software baseada no GitHub que distribui tarefas de issues para um grupo de agentes de programação, incluindo Codex e Claude Code. Ele explica o ciclo de triagem, execução, validação e revisão humana e, em seguida, demonstra como criar a fábrica usando Upstash, GitHub Actions e uma skill reutilizável. O tutorial cobre a configuração de repositórios, credenciais, agentes, caixas virtuais e snapshots, além de mostrar como testar o fluxo e adicionar repositórios. Os agentes executam em sandboxes na nuvem, e as alterações propostas chegam como pull requests para revisão humana.

Pontos-chave

• A fábrica de software é o sistema que recebe sinais, como issues do GitHub, e distribui tarefas para agentes disponíveis.
• O fluxo típico inclui triagem, execução por um agente, validações e criação de um pull request, com etapas de revisão humana.
• Agentes diferentes podem ser escolhidos conforme o tipo de tarefa, manualmente por meio de labels ou por uma etapa de triagem.
• Executar cada agente em uma sandbox na nuvem ajuda a limitar o acesso a arquivos e segredos e evita disputar recursos do computador local.
• Uma skill reutilizável permite que um agente construa a fábrica sem que o usuário precise programá-la manualmente.
• O tutorial usa GitHub Actions para conectar os repositórios de projeto à fábrica e acionar o processamento de issues.
• Snapshots do Upstash permitem criar ambientes reutilizáveis com ferramentas, skills e configurações disponíveis para os agentes.
• Para adicionar um repositório, é preciso conceder acesso ao token do GitHub, solicitar sua inclusão na fábrica e mesclar o pull request correspondente.

Capítulos

Início	Capítulo	Resumo
00:00	Demonstração da fábrica no GitHub	O apresentador mostra como uma issue marcada como pronta é atribuída a um agente, que depois abre um pull request para revisão.
01:00	O que é uma fábrica de software	Ele define a fábrica como um sistema que recebe sinais, distribui tarefas a agentes e permite incluir validações e etapas de revisão humana.
04:05	Escolha de agentes e execução isolada	O vídeo explica por que usar agentes diferentes e executar cada um em uma sandbox própria na nuvem.
06:09	Preparação dos repositórios e criação da fábrica	O apresentador escolhe repositórios e o serviço de nuvem, depois inicia a criação da fábrica com uma skill reutilizável.
10:18	Configuração dos agentes e das credenciais	Ele seleciona repositórios, agentes e quantidade de caixas, configura ferramentas de navegador e adiciona os segredos necessários.
17:00	Testes e integração com os repositórios	O agente testa as caixas e configura os gatilhos; o apresentador mescla os pull requests que conectam os repositórios à fábrica.
22:06	Snapshots e expansão da frota de agentes	O vídeo demonstra como preparar snapshots reutilizáveis com skills e criar mais caixas para ampliar o grupo de agentes.
25:10	Adição de repositórios e teste com Codex	O apresentador concede acesso a outro repositório, o conecta à fábrica e testa uma issue atribuída ao Codex.

Citações

A fábrica de software em si não é um agente de programação. — 01:31

Cada agente é executado em sua própria sandbox. — 05:06

Vamos pedir ao nosso agente que construa uma fábrica para nós. Não precisamos programar nada. — 07:43

Podemos criar um snapshot. Assim, definimos um ambiente e criamos caixas a partir dele. — 22:37

Conceitos e entidades

• software factory (conceito): Sistema que recebe tarefas, encaminha-as a agentes de programação e acompanha o fluxo até a revisão ou entrega da alteração.
• Codex (modelo): Agente de programação usado no tutorial como uma das opções para executar tarefas da fábrica.
• Claude Code (ferramenta): Agente de programação que pode ser executado nas caixas do Upstash para trabalhar nas issues.
• Upstash (empresa): Serviço usado no tutorial para executar agentes em máquinas virtuais na nuvem.
• GitHub Actions (ferramenta): Recurso usado para transmitir eventos dos repositórios de projeto à fábrica de software.
• Context7 (ferramenta): Ferramenta recomendada no vídeo para ajudar o agente a consultar documentação atualizada.
• create Upstash software factory (skill): Skill reutilizável apresentada no vídeo para orientar um agente na criação da fábrica de software com Upstash.
• Jev (pessoa): Nome citado como exemplo de uma ferramenta que poderia classificar alterações na etapa de triagem.
• Leon van Zyl (pessoa): Apresentador que demonstra a configuração e o uso da fábrica de software.
• Upstash boxes (ferramenta): Máquinas virtuais Linux do Upstash nas quais os agentes de programação são executados.

Tradução completa (pt-BR)

00:00 Tenho experimentado fábricas de software e criei esta, que funciona no GitHub. Gosto da ideia de ter um enxame de coding agents, mas eu realmente não queria mais uma ferramenta de CLI ou um app para gerenciar. Queria que minha fábrica de software ficasse bem ao lado do meu código de verdade. Então, isso significa que tudo o que preciso fazer é criar uma issue, marcá-la como pronta, e a fábrica atribuirá uma tarefa a um agent. Tenho cerca de 10 agents no meu enxame, e, na verdade, é uma mistura de agents do Codex e do Claude. Esses agents podem trabalhar em vários projetos. A fábrica vai até mesmo

00:30 alterar os labels também. Então, podemos ver que ela está trabalhando nesta issue no momento. Vamos tentar outra. Posso ir até os labels, marcar esta como pronta e também decidir qual agent quero usar. Para esta issue, vamos atribuir um agent do Codex. E, só para ter certeza, esta é a issue 34. Se voltarmos à fábrica, veremos que a issue 34 foi atribuída a um agent. E, se atualizarmos nossa lista de agents, este coding agent agora está ocupado com essa issue. Quando o agent terminar, ele criará um pull request, que posso revisar.

01:00 Então, isso envolve uma pessoa no loop. E, se estivermos satisfeitos com essa alteração, podemos prosseguir e fazer o merge. Neste vídeo, vou explicar o que é uma fábrica de software e mostrar como configurar sua própria fábrica de software no GitHub. Mas o que exatamente é uma fábrica de software? Para muita gente, é meio que o próximo passo no trabalho com coding agents. Em vez de supervisionar sessões específicas de agents, as fábricas de software dão acesso a um enxame de agents que ficam mais ou menos de prontidão, esperando tarefas para processar. Isso significa que poderíamos configurar uma equipe de agents com talvez 10

01:31 coding agents diferentes. E esses agents ficam apenas esperando tarefas para processar. Eles receberão uma tarefa, vão testá-la, passar pelas nossas salvaguardas e, por fim, entregar a alteração ou criar um pull request. As grandes fábricas de software também envolvem revisão humana. Isto não é uma fábrica obscura, onde os agents simplesmente ficam trabalhando por conta própria, fazendo o que bem entendem. A fábrica de software em si não é um coding agent. A fábrica é mais ou menos o sistema, o programa ou o harness que desenvolvemos, que receberá algum tipo de tarefa a partir de um sinal.

02:02 Pode ser uma mensagem no Slack, uma mensagem no Telegram, uma issue do GitHub; alguma coisa vai acioná-la. Então, ela revisará essa alteração e a atribuirá a um coding agent disponível. É mais ou menos o sistema responsável por gerenciar todo o workflow. Este é um loop de fábrica bem comum. Como mencionei, pode haver algum tipo de sinal. Ou seja, há algum tipo de sistema em que as pessoas relatam bugs. Podem ser issues do GitHub. Pode ser uma mensagem no Slack. Qualquer coisa pode ser um sinal que aciona a fábrica de software.

02:32 E então temos esta etapa de triagem. Pode chamar de triagem, orquestração, delegação, como preferir. Basta entender que, nesta etapa, recebemos a tarefa. Se quisermos, podemos executar um LLM para classificar essa etapa. Por exemplo, se você estiver usando Jev, pode usá-lo para talvez classificar a alteração como um bug, um recurso novo ou documentação. E isso poderia determinar a qual coding agent a alteração deve ser atribuída. Ou, no meu exemplo, nem incluí um LLM.

03:03 É simplesmente um trecho de código que é executado, pega a tarefa e a atribui a um dos coding agents disponíveis. Então, um dos coding agents implementará a alteração. Ele pode validá-la executando revisões, testes unitários e assim por diante. Por fim, ele liberará essa alteração criando um pull request ou talvez até enviando o código. E então a fábrica de software continuará monitorando a chegada de novos sinais. Você pode incluir quantas etapas de aprovação humana quiser, como decisões arquiteturais, breaking changes, incidentes ativos ou simplesmente revisar

03:34 e fazer merge de pull requests. E é assim que vamos implementar isso. Nosso sinal será uma issue do GitHub. Nossa etapa de triagem será, na verdade, um dispatcher, que receberá essa issue e a atribuirá a um dos agents disponíveis. Se um agent ainda não estiver pronto, ele continuará tentando até que algum agent fique disponível. Além disso, se o usuário atribuir o label que direciona a tarefa para um agent do Codex ou do Claude Code — e, aliás, você pode usar qualquer outro agent que quiser. Estou usando o Claude ou o Codex como exemplo neste tutorial. Então, a tarefa será atribuída ao agent correto.

04:05 Quando esse agent terminar, ele criará pull requests ou atualizará as issues originais com comentários, caso encontre algum problema ou precise de uma decisão de design. E, claro, vamos incluir uma pessoa no loop. Assim, você pode revisar os pull requests e decidir se quer simplesmente fechá-los, adicionar mais comentários ou fazer merge do pull request. Então, por que talvez quiséssemos usar uma mistura de agents diferentes? Por que não usar apenas o Claude para tudo, certo? Bem, o legal de uma fábrica de software é que você pode aproveitar os pontos fortes de diferentes agents. Por exemplo, Claude Fable é muito bom em

04:36 escrever código complexo. E modelos como GPT-6 Astra são muito bons em trabalho 3D. Então, um exemplo é que, na etapa de triagem ou de orquestração, você poderia usar um LLM para talvez analisar o incidente. Se envolver algum trabalho 3D, poderia atribuir uma tarefa a um modelo Codex. Ou, se envolver programação complexa, atribuí-la a um agent Claude Fable. Ou, se a alteração envolver uma atualização de documentação muito simples, poderia usar um modelo bem simples, rápido e barato. Isso é muito importante.

05:06 Cada agent é executado na própria sandbox. E talvez você esteja se perguntando por que faríamos isso. Primeiro, é mais seguro executar modelos em uma sandbox. Assim, eles não podem acessar segredos na sua máquina, executar comandos nocivos e assim por diante. Lembre-se de que as issues podem conter instruções nocivas por meio de prompt injection. E, se o agent estiver sendo executado apenas em uma sandbox isolada, o dano fica totalmente limitado. Os agents não podem acessar seu laptop, seus arquivos, seus segredos, nada. Outra coisa é que cada um desses agents é executado em seu próprio VPS.

05:38 Isso significa que eles têm recursos de hardware próprios, como este, que tem duas CPUs e quatro GB de RAM. Assim, esses agents não disputam recursos da sua máquina. Imagine executar 10, 20 ou 100 agents ao mesmo tempo, todos disputando os mesmos recursos. Mas, por favor, me contem nos comentários se algum dia vocês precisariam de tantos agents. E outro benefício óbvio de executar esses agents em um VPS é que eles estão sempre online. Então, se eu fechar meu laptop, o trabalho continuará normalmente. Posso sair, posso

06:09 abrir o GitHub no meu celular, registrar uma issue e um desses agents criará o pull request. Certo, chega de teoria; vamos construir nossa fábrica de software. Para começar, precisaremos de pelo menos um repo do GitHub para a fábrica de software gerenciar. Então, use um dos seus repos existentes no GitHub ou, se quiser se prevenir, faça o deploy de um app de lista de tarefas bem simples. Esses repos podem ser privados ou públicos, fica totalmente a seu critério. Mas tenha em mente que, se o repo for público, outras pessoas poderão atribuir issues, e isso também poderá acionar sua fábrica de software. Você sempre pode atualizar sua etapa de triagem

06:41 para processar apenas issues do GitHub atribuídas por você. Neste vídeo, vou usar dois repos diferentes: o RTS demo e o app de lista de tarefas. Depois, também precisamos executar nossos agents na nuvem. Para fábricas de software, não gosto muito de executar agents na minha máquina local, pelos motivos mencionados antes, e uma das maneiras mais fáceis que encontrei de executar agents na nuvem é com o Upstash. Você poderá acompanhar usando o plano gratuito deles. Então, basta criar sua conta no Upstash e acessar a opção box aqui. E, se você acessar boxes, vai

07:12 vão notar que, no momento, não temos nenhuma box em execução. Uma box é simplesmente uma pequena máquina virtual Linux, e nossos agents, como Claude Code e Codex, vão rodar nessas máquinas. E, por fim, tudo o que precisamos fazer é criar nossa fábrica de software. Como mencionei antes, a própria fábrica de software não é o agent de programação. Ela é basicamente o ambiente, o programa ou o wrapper responsável por receber esses gatilhos — ou seja, receber as issues e atribuí-las aos agents de programação — e depois gerenciar todo o processo. Então, o que vamos fazer é pedir ao nosso agent de programação

07:43 que construa uma fábrica para nós. Não precisamos programar nada. Depois, vamos fazer o deploy da nossa fábrica no GitHub. E o mais legal é que o código da fábrica de software vai rodar dentro do próprio GitHub. Vocês vão ver que é realmente muito, muito legal. Configurar tudo isso pode ser bem complicado, e precisei consultar vários artigos para fazer funcionar. Um artigo muito bom é este, da própria Upstash, que discute a necessidade de ter um sandbox separado para cada agent em uma fábrica de software. Há muitas informações valiosas nesse artigo,

08:14 e também precisei consultar vários outros artigos para entender como as boxes e o GitHub Actions funcionam, além de tudo o que precisamos para construir essa fábrica. Então, em vez de entediar vocês com todos os detalhes técnicos, decidi criar uma skill reutilizável para agents, que vocês podem instalar e simplesmente pedir ao agent que construa a fábrica para vocês. Na descrição deste vídeo, vocês encontrarão um link para este repo do GitHub com todas as minhas diferentes skills. E, dentro da pasta de skills, encontrarão esta skill create Upstash software factory. Ela fornece ao agent muitas referências sobre tudo o que usei para construir esta fábrica de software.

08:45 Então, se vocês realmente quiserem entender a fundo como tudo isso funciona, podem simplesmente pedir ao agent que examine este repo, veja a skill e explique tudo em detalhes. Não quis tomar o tempo de vocês, então vou apenas mostrar como usar essa skill. Mas, em linhas gerais, ela vai explicar ao agent como criar essas boxes programaticamente e configurar os agents Claude e Codex nelas, usando os diferentes níveis de esforço, os diferentes nomes de modelo e assim por diante. Ela também explica ao agent como configurar aquele loop da fábrica que

09:16 vimos antes, no qual vamos processar issues do GitHub, fazer a triagem delas, encaminhá-las aos agents de programação e, por fim, receber de volta os pull requests. Ela também explica ao agent como o GitHub Actions funciona e como ele vai acionar esses eventos para a fábrica, fazendo com que ela atualize as issues nos repos originais. Mas, se tudo isso for técnico demais, vocês podem simplesmente pedir ao agent que explique como a skill funciona. Mas, se quiserem apenas construir a fábrica, vamos fazer isso agora. Basta copiar o link para este repo do GitHub e, de volta ao seu agent de programação,

09:46 criem uma nova pasta para a fábrica de software e peçam ao agent: “instale a skill da fábrica de software”. Depois, colem a URL, e pronto. Nosso agent acabou de instalar a skill, e agora só precisamos pedir a ele que a use ou podemos acioná-la digitando uma barra, create Upstash software factory, e vamos enviar. Quero mencionar que, neste momento, o agent vai tentar obter documentação sobre a construção de fábricas de software

10:18 e o uso das boxes da Upstash. Para ajudar o agent a encontrar documentação atualizada, recomendo usar o Context7. Neste ponto, o agent pode perguntar se pode configurar o Context7. Basta dizer que sim. Eu já o configurei, então o agent sabia exatamente o que fazer. Se disserem não ao Context7, tudo ainda vai funcionar. O agent simplesmente vai buscar a documentação online usando a pesquisa na web. E nosso agent vai perguntar quais repos queremos vincular a ele. Neste ponto, basta escolher um dos seus repos existentes

10:48 do GitHub e passá-lo ao agent. Isto está mostrando apenas os últimos repos que criei, então vou selecionar estes dois. E vamos clicar em “avançar”. Quais agents de programação os workers devem executar e como devem fazer login? É aqui que vocês podem dizer ao agent quais agents de programação ele deve usar. Se quiserem usar apenas o Claude Code, tudo bem. Basta selecionar Claude Code. Ou, se quiserem usar o Claude Code com sua chave de API, também podem fazer isso. Vou usar o Claude Code com minha assinatura. Também vou usar o Codex. E, aliás, se

11:19 vocês tiverem outros provedores que gostariam de usar, fiquem à vontade para pedir ao agent que também os use. Depois, vamos clicar em “avançar”. Qual deve ser o nome do novo repo da fábrica? Ele precisa pertencer a mim, e Upstash software factory — esses dois nomes já foram usados, porque, obviamente, fiz alguns testes. Vou chamá-lo de software factory, e ele será privado. Recomendo que a fábrica de software também seja privada, pois não há realmente necessidade de o público vê-la. Qual é o limite de boxes do seu plano da Upstash?

11:51 Quantos workers vocês querem? Vou usar o plano gratuito e, aliás, vocês também podem acompanhar de graça. A sugestão será de 10 boxes. Na verdade, vou escolher quatro boxes: duas para o Codex e duas para o Claude. Vocês definitivamente não precisam criar 10 boxes. A sugestão é de 10 simplesmente porque o plano gratuito da Upstash permite até 10 boxes. Certo, quando uma issue não tiver um rótulo de agent, qual tipo de agent deve ser escolhido primeiro? Como mostrei mais ou menos na introdução deste vídeo,

12:22 podemos atribuir rótulos para direcionar uma tarefa ao Claude, ao Codex ou a qualquer agent de programação que quisermos. Então, esta pergunta é simplesmente para saber como as tarefas devem ser distribuídas entre esses agents quando não atribuirmos um rótulo. Devemos escolher primeiro o Claude, o Codex ou apenas distribuir igualmente? Vou escolher essa opção. Os workers devem receber uma imagem de worker com uma ferramenta de navegador? Os dois aplicativos são apps de navegador, e cada box recebe o Chromium da Upstash por padrão, mas o agent precisa de uma ferramenta, como o agent-browser,

12:52 na imagem, para controlá-lo e realmente conferir o trabalho. Então, sim, recomendo ativar o agent-browser. Qual é o limite de boxes na sua conta da Upstash? Se estiverem no plano gratuito, o limite é 10. Se estiverem gostando do vídeo, cliquem no botão de curtir e se inscrevam no meu canal para ver mais tutoriais de programação agêntica. Certo, o agent acabou de criar a estrutura inicial da fábrica e também a enviou ao GitHub. Podemos vê-la aqui. Temos nossa fábrica de software com vários arquivos. Agora, o agent está pedindo que forneçamos

13:23 estes três secrets. Vou mostrar daqui a pouco como gerá-los, mas quero mencionar que o agent está pedindo que coloquemos os secrets neste arquivo .env. Essa é a maneira mais segura de fazer isso, mas, se quiserem facilitar, podem simplesmente colá-los no chat. Ainda assim, recomendo atualizar diretamente o arquivo .env. Normalmente, basta clicar neste arquivo. Se estiverem usando o Claude Code, podem clicar neste link para abrir o arquivo .env. Depois, é só colar os valores

13:54 e qualquer alteração será salva automaticamente. Para o primeiro, vamos obter nossa chave de API das boxes da Upstash. Basta acessar a Upstash, depois ir a box, overview e, em API keys, criar uma nova chave. Vou chamá-la de software factory. Vamos copiar a chave e colá-la neste arquivo. Vou pressionar Control+S para salvar as alterações. Essa chave de API das boxes da Upstash permitirá que nossa fábrica de software

14:24 para interagir com os agents no Upstash. Também precisamos que nossa fábrica de software consiga interagir com o GitHub. Isso dará à nossa fábrica acesso aos repositórios e permitirá que ela obtenha o conteúdo, crie pull requests e issues. Para criar esse token do GitHub, acesse seu perfil, vá para as configurações, role para baixo até as configurações de desenvolvedor, acesse tokens de acesso pessoal e, depois, tokens de acesso refinados. Vamos gerar um novo token. Vamos dar ao nosso token um

14:55 nome como software factory. Você pode adicionar uma descrição, se quiser. Também pode definir uma data de expiração. Vou deixar em sete dias. Depois, também podemos selecionar os repositórios que poderão ser acessados com essa chave. Podemos selecionar repositórios públicos, todos os repositórios ou, o que eu recomendo, apenas os repositórios selecionados. Assim podemos controlar a quais repositórios nossa fábrica de software terá acesso. Então, vamos clicar neste menu suspenso. Depois, vamos selecionar a própria software factory.

15:27 E, em seguida, quaisquer repos aos quais queremos dar acesso à nossa fábrica de software. Então, se algum dia quiser incluir mais repositórios na sua fábrica de software, lembre-se de selecioná-los nesta lista. Mas, para começar, provavelmente não recomendo selecionar todos os repositórios. Depois, em permissões, vamos adicionar uma permissão. Nesta lista, vamos pesquisar por conteúdo. E vamos definir como leitura e gravação. Vamos adicionar outra permissão. Vamos pesquisar por issues. Vamos definir esta também como leitura e gravação. E, por fim, vamos também adicionar

15:58 permissões para pull requests. E devemos poder ler e gravar pull requests. Então, suas permissões devem ficar mais ou menos assim. Vamos clicar em gerar token. Vamos clicar em gerar token novamente. Vamos copiar o token. E vamos adicioná-lo ao nosso arquivo .env. Por fim, também vamos obter nosso token OAuth do Claude Code. Isso permitirá que os agents executem o Claude Code usando nossa assinatura, em vez de pagarmos por chaves de API. Para obter esse token, basta executar este comando.

16:28 No Claude Code, isso é muito fácil. Basta clicar em executar. E agora só vou colar a chave e fechar o arquivo .env. Vou excluir todos esses tokens depois da gravação, então, por favor, não use meus tokens. Agora podemos simplesmente dizer ao Claude: atualizei o .env. E agora estamos recebendo mais algumas perguntas. Para os workers do Claude Code, qual modelo e nível de esforço de raciocínio devem ser armazenados nas caixas? Podemos simplesmente usar os padrões, Sonnet, Opus ou o que quisermos. Vou usar Opus com esforço alto.

17:00 Para os workers do Codex, qual modelo e nível de raciocínio devemos usar? Vou dizer GPT-6 Astra com raciocínio alto. Certo, isso é muito legal. O que seu agent vai fazer agora é criar duas caixas de amostra no Upstash, só para testar as conexões e garantir que esses agents realmente funcionem. Podemos acessar as caixas no Upstash e ver a caixa smoke-test Codex. Depois disso, o agent excluirá essas caixas automaticamente. E nosso agent confirmou que consegue criar caixas

17:30 e executar agents de programação dentro delas. Ele vai configurar a fábrica de software no GitHub. Esta mensagem tem muita coisa. Ela está perguntando se pode configurar todos os diferentes gatilhos na própria fábrica. Então, neste momento, basta dizer: “Sim, aplique os dois.” Certo, nosso agent fez um ótimo progresso e chegará a esta etapa, a etapa cinco, em que vai pedir que você faça merge dos pull requests. Para explicar mais ou menos como isso funciona, a fábrica de software poderá atualizar issues

18:00 e criar pull requests nos diferentes repos que está gerenciando. Mas os próprios repos dos projetos também precisam de uma forma de disparar gatilhos para a fábrica de software. Para dar um exemplo rápido, se eu acessar o próprio projeto e entrar em issues, quando criamos uma issue e atribuímos um rótulo que aciona a fábrica de software, este repositório deve poder informar ou sinalizar à fábrica de software: “Ei, há uma nova issue”, e você precisa atribuí-la a um agent para trabalhar nela. Para que este

18:31 repo tenha conhecimento da fábrica de software, precisamos fazer merge de um pull request. Então, o agent teria criado esse tipo de pull request nos repos existentes. Basta abrir este repo, que claramente diz que é para enviar issues prontas à fábrica de software. Só precisamos clicar em fazer merge e concluir o merge deste pull request. Vou acessar também meu segundo repo. Tenho exatamente o mesmo pull request aqui. Vou fazer o merge.

19:01 E isso permitirá que esses repos enviem instruções para a fábrica de software. Certo, agora fiz merge desses dois pull requests, então podemos fazer um pequeno teste. Crie uma issue de teste simples em um dos repos e adicione o rótulo ready, por exemplo. Certo, vamos fazer isso. Vou acessar um desses repos. Vamos criar uma nova issue. Vamos chamá-la de criar modos claro e escuro. Também vou colocar isso na descrição. Depois, em rótulos, vamos pegar o rótulo ready,

19:32 que diz para a fábrica começar a trabalhar nesta issue. Então, vou selecionar esse rótulo. Vamos clicar fora dele. Vamos criar esta issue. Se voltarmos ao repo da fábrica de software, podemos ver o que ela está fazendo acessando as actions. E aqui podemos ver a issue que acabamos de criar. Isso foi executado muito rápido porque ainda não usa o agent de programação. Está apenas testando a integração entre o repo do nosso projeto e a fábrica de software. Então, vamos apenas dizer ao agent: criei a issue, defini o rótulo como ready,

20:04 e consegui ver a action em execução na fábrica de software. Vamos enviar isso. Você não precisa fornecer todos esses detalhes. Pode simplesmente dizer ao agent que criou a issue. Ele vai monitorar tudo isso automaticamente. E ele está dizendo que o dry run foi aprovado. Então, agora vai desativar o dry run e fazer o agent realmente implementar as mudanças. Mas ele não conseguiu executar um determinado comando porque o sistema de permissões o bloqueou. Se receber essas mensagens, não se preocupe. No Claude Code, basta

20:34 clicar neste pequeno botão para executar esses comandos. Agora podemos fazer isso de verdade removendo este rótulo. Vamos fazer isso. Vamos adicionar o rótulo novamente, assim. E nosso agent deve processar a issue de verdade. Do lado da fábrica de software, vejo que a issue foi recebida. E, se acessarmos nossas caixas do Upstash, podemos ver que este agent está mesmo ocupado. O mais legal é que, se voltarmos à issue, veremos o rótulo mudar de ready para factory running. Esta é uma forma muito conveniente de ver

21:05 quais issues estão sendo processadas pela fábrica no momento. E, na verdade, a fábrica acabou de concluir o trabalho e mudou o rótulo para factory review. Antes de sairmos da issue, há outras coisas úteis também. Se olharmos os comentários, a fábrica nos informou que o worker Claude02 foi designado para trabalhar nesta tarefa. Também podemos ver que este pull request foi criado. Vamos acessar nossos pull requests. Vamos abrir este. Este pull request nos diz que fechará a issue 52 se fizermos merge, e inclui todos os detalhes

21:35 relacionados a essa mudança. Vamos fazer merge deste pull request. Agora está funcionando, mas ainda não terminamos. Primeiro, vamos apenas dizer ao nosso agent: adicionei novamente o rótulo ready, o agent criou o PR e eu fiz merge. Mas o agent apenas verificou os logs e confirmou que tudo funcionou corretamente. Ele está propondo que testemos isso em grande escala agora. Podemos criar várias issues e ver como tudo isso funciona na prática. Agora, é claro, se esta é a sua fábrica de software,

22:06 pode fazer isso. Teste usando os diferentes repos que você conectou e tente iniciar quantos coding agents quiser. Mas quero mostrar um conceito muito importante que você precisa entender sobre as boxes da Upstash. Essas boxes são muito simples. São máquinas virtuais rodando Linux. Configuramos o Claude ou o Codex nessas boxes e nada mais. Vamos supor que você queira que suas boxes sejam configuradas de uma maneira muito específica. Então, para cada um desses agents, independentemente do coding agent que você estiver usando, certas skills ou determinados

22:37 guardrails precisam estar em vigor. Isso também é muito fácil. E, em vez de definir isso em cada box, podemos criar um snapshot. Com um snapshot, podemos definir um ambiente e, depois, quando criarmos nossas boxes, podemos criá-las a partir desse ambiente. É como configurar um modelo reutilizável. Neste caso, nosso agent já criou dois snapshots, um para o Codex e outro para o Claude. Tenho quase certeza de que são bem simples. Um simplesmente instala o Codex, e o outro instala o Claude.

23:08 Mas digamos que quiséssemos criar um snapshot que já incluísse várias agent skills às quais queremos que todos os nossos agents tenham acesso. O que podemos fazer é pedir ao nosso agent: “Crie novos snapshots para as boxes do Claude e do Codex com as seguintes skills pré-carregadas.” Para dar um exemplo, digamos que eu queira a skill frontend-design para criar esses agents. Basta colá-la aqui. Talvez eu também queira que o agent-browser esteja disponível, então posso adicioná-lo aqui. Enfim, acho que você entendeu a ideia. Então, neste momento,

23:38 você pode simplesmente incluir quaisquer skills, servidores MCP ou seu arquivo AGENTS.md. O que você quiser que esteja disponível nessa box, basta pedir ao seu agent para criar um snapshot reutilizável. Isso vai criar ou atualizar nossos snapshots e implantá-los na Upstash. Assim, quando criarmos novas boxes daqui para a frente, elas herdarão todas essas skills e tudo o mais que quisermos do modelo ou dos snapshots. Certo, o Claude acabou de criar essas novas boxes. E é muito importante que o Claude não pode excluir boxes. Então, a Upstash não

24:08 permite que agents excluam boxes ou snapshots. Portanto, você precisa fazer isso por conta própria. Vou pegar essas imagens antigas. Vamos excluí-las. Também vou excluir todas as nossas boxes existentes. Vamos fazer isso. E vamos voltar ao Claude. Acabei de excluir os snapshots antigos e todas as boxes disponíveis. Por favor, recrie as boxes usando os novos snapshots. Certo, vamos ver. Ótimo, podemos ver que o Claude está criando essas novas boxes. Então, sempre que atualizamos a página, vemos uma nova box aparecer.

24:39 Na verdade, este pode ser um bom momento para mostrar como criar mais boxes. Digamos que, na verdade, eu queira 10 boxes divididas entre o Codex e o Claude. Vamos fazer isso. E é assim que é fácil escalar nosso enxame de agents. O Claude está criando seis boxes adicionais. E, se atualizarmos a Upstash, podemos ver que as novas boxes já estão sendo adicionadas. Que facilidade, não é? Por fim, talvez você esteja se perguntando: o que fazer quando quiser adicionar um novo repo? Bem, o processo é o mesmo, tanto para adicionar quanto para remover repos.

25:10 Então, vamos supor que eu também queira adicionar este pequeno repo. A primeira coisa que precisamos fazer é voltar às nossas configurações. Vamos voltar às configurações de desenvolvedor. Vamos encontrar aquele fine-grained token, que chamamos de Software Factory. Vamos clicar em Edit e, em Select Repositories, vou selecionar esse novo repo. E vamos clicar em Update. Ótimo. Claro que, se você selecionou todos os repos, não precisava fazer esta etapa. Depois, podemos simplesmente abrir nossa Software Factory usando o Claude Code ou o que quer que estivéssemos usando.

25:41 E vamos dizer simplesmente: “Adicione este repo à Software Factory também.” E vamos colá-lo aqui. O Claude está dizendo que o token consegue acessar esse repo. Se você tiver algum problema, confira se atualizou esse personal access token. E, como antes, nosso agent vai abrir um pull request, permitindo que esse repo envie essas instruções para a Software Factory. Então, só precisamos mesclar esse pull request. Vamos tentar criar uma

26:11 nova issue para este projeto. E não sei que mudança podemos fazer neste app. Talvez possamos simplesmente adicionar o modo escuro. Então, vamos escrever: “Adicione suporte aos modos claro e escuro”, assim. Vamos criar a issue. Depois, em labels, vamos definir como ready. Mas vamos também atribuí-la ao Codex, porque ele é muito bom com trabalhos em 3D. E este app depende bastante de elementos 3D, certo? Vamos ver se a Software Factory vai pegar isso. A Software Factory está processando.

26:41 A label Factory Running foi adicionada. E podemos ver este comentário dizendo que o Codex01 assumiu a tarefa. Que legal, não é? Vamos voltar às suas boxes da Upstash. E aqui podemos ver que o Codex01 está mesmo trabalhando nessa tarefa. E, se formos às actions da própria Software Factory, veremos que ela está mesmo em execução. Que legal, não é? Se você realmente quer aprender a trabalhar com coding agents, considere entrar na minha comunidade Skool, Agentic Labs. Isso dará acesso a cursos mais exclusivos, como o Agentic Coding Masterclass. É lá que ensino todos os fundamentos

27:12 do uso de coding agents. E criamos aplicações completas que incluem processamento de pagamentos, autenticação de usuários e muito, muito mais. Isso também dá acesso a sessões ao vivo, como nossas sessões Tuesday Coffee e as sessões Thursday Deep Dive. Também quero agradecer à Upstash por patrocinar este vídeo e recomendo muito que você confira. Vejo você no próximo. Tchauzinho.

Transcrição original

[00:00] I’ve been playing around with software factories and I built this one that runs on GitHub. I do like the idea of having a swarm of coding agents, but I really didn’t want another CLI tool or app to manage. I wanted my software factory to live right next to my actual code. So this means all I have to do is create an issue, mark it as ready, and the factory will assign a task to an agent. And I’ve got about 10 agents in my swarm, and this is actually a mixture between Codex and Claude agents. And these agents can work across multiple projects. The factory will actually

[00:30] change the labels as well. So we can see it’s currently working on this issue. Let’s try another one. So I can go to labels, we can set this to ready, and I can decide which agent I want to use as well. For this issue, let’s assign a Codex agent. And just to be sure, this is issue 34. And if we go back to the factory, we can see that issue 34 has been assigned to an agent. And if we refresh our agent list, this coding agent is now busy with that issue. Once the agent is done, it will create a pull request, which I can review.

[01:00] So this does involve human in the loop. And if we’re happy with this change, we can go ahead and merge it. In this video, I’ll explain what a software factory is, and I’ll show you how to set up your very own software factory within GitHub. But what exactly is a software factory? For a lot of people, it’s kind of that next step with working with coding agents. Instead of you supervising specific agent sessions, software factories give you access to a swarm of agents that are all sort of on standby, waiting for tasks to process. This means we could set up an agent team with like maybe 10

[01:31] different coding agents. And those agents are just waiting for tasks to process. Those agents will receive a task, test it, go through our guardrails, and eventually ship the change or create a pull request. The big software factories involve human review as well. This is not a dark factory where the agents are just kind of running by themselves, doing whatever they want. The software factory itself is not a coding agent. The factory is kind of the system or the program or the harness that we develop that will receive some kind of task from a signal.

[02:02] This could be a Slack message, a Telegram message, a GitHub issue, something will trigger it. It will then do a review of that change and assign it to an available coding agent. It’s kind of the system that’s responsible for managing the entire workflow. This is a very common factory loop. Like I mentioned, there could be some kind of signal. So there’s some kind of system where people report bugs. It could be GitHub issues. It could be a Slack message. Anything could be a signal that triggers the software factory.

[02:32] And then we’ve got this triage step. Now this could be triage. It could be orchestration. It could be a delegation step, whatever you want to call it. Simply see it as in this step, we receive the task. We could, if we want to, run an LLM to classify that step. For example, if you are using Jev, you could use that to maybe classify the change as being a bug, a new feature or documentation. And then that could drive which coding agent the change should be assigned to. Or in my example, I didn’t even include an LLM at all.

[03:03] It’s simply a piece of code that runs that will grab the task and assign it to one of the available coding agents. Then one of the coding agents will implement the change. It could validate it by running reviews, unit tests, et cetera. And finally, it will release that change by creating a pull request or maybe even shipping the code. And then the software factory will keep monitoring for any new signals. And you can include as many human gates as you want, like architectural decisions, breaking changes, active incidents, or just reviewing

[03:34] and merging pull requests. And this is how we will implement this. Our signal will be a GitHub issue. Our triage step will actually be a dispatcher, which will receive that issue and assign it to one of the available agents. If an agent is not yet ready, it will just keep retrying until an agent becomes ready. Also, if the user assigned the label to assign the agent to Codex or Claude Code, or by the way, you can use any other agent you want. I’m just using Claude or Codex as an example in this tutorial. It will then assign the task to the correct agent.

[04:05] Once this agent’s complete, they will actually create pull requests or they would update the original issues with any comments if they run into any issues or they need a design decision. And of course, we will add human in the loop. So you can review the pull requests and decide if you just want to close it, add more comments, or merge the pull request. So why might we want a mix of different agents? Why not just go with Claude for everything, right? Well, the cool thing about a software factory is you can lean into the strengths of different agents. Like Claude Fable is really good at

[04:36] writing complex code. And then models like GPT-6 Astra is really good at 3D work. So one example is in your triage step or in orchestration step, you could use an LLM to maybe scan the incident. If it involves any 3D work, it could assign a task to a Codex model. Or if it involves complex coding, assign it to a Claude Fable agent. Or if the change involves a super simple documentation update, it could use a very simple and quick and cheap model. Now, this is really important.

[05:06] Each agent runs in its own sandbox. And you might be wondering, why would we want to do that? Firstly, it’s safer to run models in a sandbox. That way they can’t access secrets on your machine, run harmful commands, et cetera. Remember that issues could contain harmful instructions through prompt injection. And if the agent is only running in a contained sandbox, the damage is completely limited. The agents can’t access your laptop, files, your secrets, nothing. Another thing is that each of these agents actually run on their own little VPS.

[05:38] This means they’ve got their own hardware allocation, like this one’s got two CPUs and four gig of RAM, which means that these agents are not fighting over resources on your machine. Imagine running 10 or 20 or 100 agents at the same time, all fighting for the same resources. Although please let me know down in the comments if you would ever need that many agents. And another benefit of obviously running these agents on a VPS is that they are always online. So if I close my laptop, the work will continue as per usual. I can go away, I can

[06:09] open up GitHub on my phone, log an issue, and one of these agents will create the pull request. All right, enough theory, let’s build our software factory. To get started, we will need at least one GitHub repo for the software factory to manage. So just use one of your existing GitHub repos, or if you just want to be safe, just deploy a really simple to-do app. These repos can be private or public, it’s totally up to you. But just keep in mind if the repo is public, other people could assign issues, and that could trigger your software factory as well. You could always update your triage step

[06:41] to only process GitHub issues that were assigned by you. For this video, I am going to use two different repos, so it’s the RTS demo and the to-do app. Then we also need to run our agents in the cloud. For software factories, I don’t really like running agents on my local machine for the reasons mentioned earlier, and one of the easiest ways I found to run agents in the cloud is with Upstash. You will be able to follow along with their free tier. So simply create your Upstash account and go to the box option over here. And if you go to boxes, you

[07:12] will notice that we currently don’t have any boxes running. A box is simply a little Linux virtual machine, and our agents like Claude Code and Codex will run in those machines. And then finally, all we have to do is create our software factory. As I mentioned earlier, the software factory itself is not the coding agent. It’s basically the environment or the program or the wrapper that’s responsible for receiving those triggers, so receiving the issues and assigning them to the coding agents and then managing the entire process. So what we’re going to do is get our coding agent

[07:43] to build a factory for us. We do not have to code a thing. And then we’ll deploy our factory to GitHub. And what’s really cool is the software factory’s code will run within GitHub itself. You’ll see it’s actually really, really cool. Now setting all of this up can be quite tricky, and I had to reference multiple articles to get this to work. A really good article is this one from Upstash themselves, where they discuss the need to have a separate sandbox per agent in a software factory. There was a ton of valuable insight in this article,

[08:14] and I also had to reference a whole bunch of other articles to understand how boxes work, GitHub Actions, and everything we need to build this factory. So instead of boring you with all the technical details, I decided to create a reusable agent skill, which you can install and just get your agent to build the factory for you. In the description of this video, you’ll find a link to this GitHub repo with all of my different skills. And within the skills folder, you’ll find this create Upstash software factory skill. This gives the agent a ton of references of everything that I use to build this software factory.

[08:45] So if you really want a deep understanding of how all of this works, you can actually just ask your agent to look at this repo, look at the skill, and just break everything down in detail for you. I didn’t want to waste your time, so I’m just going to show you how to use this skill. But just at a very high level, this is just going to explain to the agent how it can programmatically create these boxes and set up the Claude and Codex agents on those boxes using the different effort levels, the different model names, et cetera. It also tells the agent how to set up that factory loop that

[09:16] we had a look at earlier, where we’ll process issues from GitHub, triage them, send them off to coding agents, and eventually get those pull requests back. It also explains to the agent how GitHub Actions work and how GitHub Actions will trigger those events to the factory and will get the factory to update the issues within those original repos. But if this is all too technical, again, you can just ask your agent to explain how the skill works. But if you just want to build the factory, then let’s do that now. Simply copy the link to this GitHub repo, then back in your coding agent,

[09:46] just create a new folder for your software factory, and then you can ask your agent, please install the software factory skill, then paste in that URL, and done. So our agent just installed the skill, and all we have to do now is ask the agent to use the skill, or we can just trigger it using forward slash, create Upstash software factory, and let’s send this. So I do want to mention at this point that the agent is going to try to retrieve documentation related to building software factories

[10:18] and using Upstash boxes. To help the agent find up-to-date documentation, I do recommend using Context7. So at this point, the agent might actually ask you if it can go ahead and set up Context7. You can just say yes at that point. I’ve already set it up, so the agent knew exactly what to do. If you say no to Context7, everything will still work. The agent will just go online to retrieve documentation using web search. And our agent is just going to ask us which repos we want to link it to. So at this point, you can just take one of your existing

[10:48] GitHub repos and give it to the agent. This is simply showing the last few repos that I created, so I’m going to select these two. And let’s click on next. Which coding agents should the workers run, and how do they sign in? But this is where you can tell the agent which coding agents it should use. So if you only want Claude Code, that’s perfectly fine. Just select Claude Code, or if you want to use Claude Code with your API key, you can do that as well. I’ll just use Claude Code with my subscription. I’m also going to use Codex. And by the way, if

[11:19] you have other providers that you would like to use, feel free to tell the agent to use those providers as well. Then let’s click on next. What should the new factory repo be? It must be owned by me and Upstash software factory, and those two have already been taken because I’ve obviously practised a few times. I’ll just call this one software factory, and it will be private. I do recommend making your software factory private as well, as there’s really no need for the public to see your software factory. What is your Upstash plan’s box limit?

[11:51] How many workers do you want? So I am going to use the free plan, and by the way, you can follow along for free as well. And this is going to propose 10 boxes. I’m actually going to say four boxes, two Codex and two Claude. You definitely don’t have to create 10 boxes. It’s simply suggesting 10 because the free plan with Upstash goes up to 10 boxes. All right, so when an issue has no agent label, which agent type should it take first? Like I showed you sort of in the intro of this video,

[12:22] we can assign labels to assign a task to Claude or Codex or whatever coding agent we want to assign it to. So this is simply asking if we don’t assign a label, how should it allocate tasks to those agents? So should we go with Claude first or Codex first, or just spread evenly? I’ll just choose that option. Should the workers get a worker image with a browser tool? Both of these apps are browser apps, and every box gets Upstash’s Chromium by default, but the agent needs a tool such as agent-browser

[12:52] in the image to drive it and actually look at its work. So yes, I would just recommend enabling agent-browser. What is the boxes limit on your Upstash account? If you are on the free plan, the limit is 10. If you’re enjoying this video so far, please hit the like button and subscribe to my channel for more agentic coding tutorials. Right, so the agent just scaffolded the factory and it actually pushed it to GitHub as well. We can view it over here. So we’ve got our software factory with a bunch of files. So now the agent is asking us to supply

[13:23] these three secrets. I am going to show you how to generate those in a second, but I do want to mention that the agent is asking us to put those secrets in this .env file. This is the most secure way to do it, but if you just want to be lazy, you can just paste those into the chat, but I would actually recommend just updating the .env file directly. So usually that simply means clicking on this file. If you are using Claude Code, you can just kind of click on this link and that will bring up the .env file. And all we have to do is paste in those values

[13:54] and this will automatically save any of these changes. For the first one, let’s get our Upstash box API key. Just go to Upstash, then go to box, overview, and under API keys, let’s create a new key. I’ll just call this software factory, just like that. Let’s copy the key and let’s paste it into this file and I’ll press control and S to save these changes. This Upstash box API key will allow our software factory

[14:24] to interact with the agents on Upstash. We also need our software factory to be able to interact with GitHub. This will give our factory access to the repositories and it will allow it to pull the contents, create pull requests and issues. In order to create this GitHub token, go to your profile, go to settings, scroll down to developer settings, go to personal access tokens, go to fine-grained tokens, let’s generate a new token. Let’s give our token a

[14:55] name like software factory. You can give a description if you want. You can also set an expiration date. I’ll just make it seven days. Then we can also select the repositories that can be accessed through this key. We can select public repositories, all repositories or what I would recommend are the selected repositories only. So this is how we can control which repositories our software factory will have access to. So let’s click on this dropdown. Then let’s select our software factory itself.

[15:27] And then any repos we want to give our software factory access to. So if you ever want to include more repositories in your software factory, remember just to select it from this list. But starting out, I probably don’t recommend selecting all repositories. Then under permissions, let’s add a permission. From this list, let’s search for contents. And let’s set this to read and write. Let’s add another permission. Let’s search for issues. Let’s change this to read and write as well. And finally, let’s also add

[15:58] permissions for pull requests. And we should be able to read and write pull requests. So your permission should look something like this. Let’s click on generate token. Let’s click on generate token again. Let’s copy the token. And let’s add it to our .env file. And finally, let’s also get our Claude Code OAuth token. This will allow the agents to run Claude Code on our subscription instead of us paying for API keys. To get that token, all we have to do is run this command.

[16:28] So in Claude Code, that’s really easy. You can just click on play. And all I’m going to do now is just paste in the key and close the .env file. I am going to delete all of these tokens after the recording, so please do not use my tokens. And now we can just tell Claude. I’ve updated .env. And now we’re getting a few more questions. For Claude Code workers, which model and reasoning effort should be stored in the boxes? We could just go with the defaults, Sonnet, Opus, or whatever we want. I’ll just go with Opus with high effort.

[17:00] For the Codex workers, which model and reasoning should we use? I’ll say GPT-6 Astra with high reasoning. All right, so this is really cool. What your agent is going to do now is create two sample boxes within Upstash just to test the connections and to ensure that these agents actually work. We can actually go to the boxes in Upstash and here we can see that smoke-test Codex box. And afterwards, the agent will automatically delete those boxes. And our agent has confirmed that it can create boxes

[17:30] and run coding agents within those boxes. It’s going to set up the software factory on GitHub. Now, this message is really loaded. It’s asking if it can go ahead and set up like all the different triggers in the factory itself. So at this point, all you have to do is just say, “Yes, apply both.” Right, our agent’s made very good progress and it is going to get to this point, stage five, where it’s going to ask you to merge pull requests. So just to kind of explain how this works, the software factory will be able to update issues

[18:00] and create pull requests on the different repos that it’s managing. But the actual project repos themselves also need some way to fire off triggers to the software factory. So maybe just to give you a quick example, if I go into the project itself and to issues, when we create an issue and we assign a label to trigger the software factory, this repository should be able to inform or signal the software factory that, “Hey, there’s a new issue,” and you need to assign it to an agent and work on it. Now, in order for this

[18:31] repo to have that awareness of the software factory, we do have to merge a pull request. So the agent would have created these types of pull requests in those existing repos. So all you have to do is open up this repo, and this clearly says it’s to send ready issues to the software factory. All we have to do is click on merge and merge this pull request. Let me just go to my second repo as well. I’ve got the exact same pull request over here. I’m just going to merge it.

[19:01] And this will now allow these repos to send instructions to the software factory. Right, so I’ve now merged those two pull requests, and now we can run a small test. Create a small test issue in one of the repos and add the ready label, for example, that. All right, let’s actually do that. So I’ll go to one of these repos. Let’s create a new issue. Let’s just call this create light and dark modes. I’ll just put that in the description as well. Then under labels, let’s grab our ready label,

[19:32] which says factory start work on this issue. So I’ll just highlight that label. Let’s click off it. Let’s create this issue. And if we go back to the software factory repo, we can see what it’s doing by going to actions. And here we can see that issue that we just created. And this ran really quickly because it doesn’t actually use the coding agent yet. It’s just testing that integration between our project repo and the software factory. So let’s just tell the agent. I’ve created the issue, set the label to ready,

[20:04] and I could see the action running in the software factory. Let’s send this. You don’t have to provide all of these details. You could just tell the agent that you created the issue. It will automatically monitor for all of these things. And it’s saying the dry run passed. So it’s now going to disable the dry run and get the agent to actually make the changes. But it couldn’t execute a certain command because it was blocked by the permission system. So if you get these messages, don’t worry. All you have to do in Claude Code

[20:34] is just click on this little button to execute these commands. And now we can run this for real by removing this label. So let’s actually do that. Let’s re-add the label, like so. And our agent should process this for real. On the software factory side, I can see that issue was pulled in. And if we go to our Upstash boxes, we can see this agent is indeed busy. What’s really cool is if we go back to the issue, we can see the label change from ready to factory running. This is such a convenient way to see

[21:05] which issues are currently being processed by the factory. And in fact, the factory just completed and changed the label to factory review. Before we move away from the issue, there are other useful things as well. If we look at the comments, the factory told us that worker Claude02 was assigned to work on this task. And we can also see that this pull request was created. Let’s go to our pull requests. Let’s open up this one. This pull request is telling us that it will close issue 52 if we merge it with all the details

[21:35] related to this change. Let’s go ahead and merge this pull request. Now this is working, but we’re not done yet. First, let’s just tell our agent, I re-added the ready label, the agent created the PR and I merged it. But the agent just kind of looked at the logs and ensured that everything worked correctly. It is proposing that we kind of test this en masse now. So we could create multiple issues and see how all of this actually works. Now, of course, if this is your software factory,

[22:06] please go ahead and do this. Test this using the different repos that you connected and try to kick off as many coding agents as you want. But I want to show you a really important concept that you need to understand with Upstash boxes. These boxes are very simple. These are virtual machines running Linux. We’ve set up Claude or Codex on these boxes and nothing else. Let’s just assume that you want your boxes to be set up in a very specific way. So for each and every one of these agents, irrespective of what coding agent you’re using, certain skills or certain

[22:37] guardrails need to be in place. That is very easy as well. And instead of defining these per box, what we can do is create a snapshot. So what a snapshot does is we can define an environment and then when we create our boxes, we can create those boxes from that environment. That’s kind of like setting up a reusable template. Now, in this instance, our agent already created two snapshots, one for Codex and one for Claude. Now, I’m pretty sure these are very simple. This simply installs Codex on the one and Claude on the other.

[23:08] But let’s say we wanted to create a snapshot that already includes a whole bunch of agent skills that we want all of our agents to have access to. What we can simply do is ask our agent, please create new snapshots for the Claude and Codex boxes that have the following skills preloaded. And for argument’s sake, let’s say I wanted the frontend-design skill to create these agents. I can just paste that in here. Maybe I also want the agent-browser to be available so I can add it in here. Whatever, I think you get the idea. So at this point,

[23:38] you can just pass in any skills or MCP servers or your AGENTS.md file. Whatever you want to be available on that box, just tell your agent to create a reusable snapshot. So this will now create or update our snapshots and deploy them to Upstash. So when we create new boxes going forward, these will inherit all of these skills and whatever we want from the template or snapshots. All right, Claude just created these new boxes. And what’s very important is Claude is not able to delete boxes. So Upstash does not

[24:08] allow agents to delete boxes or snapshots. So you do have to do that yourself. I’ll just grab these old images. Let’s delete them. What I’m also going to do is actually delete all of our existing boxes. So let’s do that. And let’s go back to Claude. I’ve just deleted the old snapshots and all of the available boxes. Please recreate the boxes using the new snapshots. Right, let’s see this. And cool, we can see that Claude is now creating these new boxes. So every time we refresh, we can see a new box coming in.

[24:39] In fact, this might be a good time to show you how to create more boxes. So let’s say, in fact, I want 10 boxes split between Codex and Claude. Let’s do that. And that’s how easy it is to scale up our agent swarm. Claude is now creating six additional boxes. And if we refresh Upstash, we can see the new boxes are already being added. How easy is that? Now, finally, you might be wondering, well, what do you do when you want to add a new repository? Well, the process is the same, whether or not you want to add or remove repositories.

[25:10] So let’s assume I want to add this little repo as well. Well, the first thing we have to do is go back to our settings. Let’s go back to developer settings. Let’s find that fine-grained token, which we called Software Factory. Let’s go to Edit and under Select Repositories, I’ll select that new repository. And let’s click on Update. Cool. Of course, if you selected all repositories, this step wasn’t needed. Then we can simply open up our Software Factory using Claude Code or whatever we were using.

[25:41] And let’s simply say, please add this repo to the Software Factory as well. And let’s paste it in there. Claude is saying that the token can reach that repo. If you do run into issues here, just ensure that you’ve updated that personal access token. And just like before, our agent will open up a pull request and this will allow this repo to send those instructions to the Software Factory. So all we have to do is go ahead and merge this pull request. Let’s then try to create a

[26:11] new issue for this project. And I’m not sure what change can we make to this app. Maybe we can just add dark mode. So let’s say, Add Support for both light and dark modes like so. Let’s create the issue. Then under labels, let’s set this to ready. But let’s also assign this to Codex as Codex is really good with 3D work. And this app is highly reliant on 3D stuff, right? And let’s see if the Software Factory actually picks this up. The Software Factory is processing this.

[26:41] This label, Factory Running, has been added. And we can see this comment saying that Codex01 has picked this up. How cool is that? Let’s go back to your Upstash boxes. And here we can see Codex01 is indeed working on this task. And if we go to the actions on the Software Factory itself, this is indeed running. How cool is that? If you really want to learn how to work with coding agents, then consider joining my Skool community, Agentic Labs. This will give you access to more exclusive courses like the Agentic Coding Masterclass. This is where I teach you all the fundamentals

[27:12] of using coding agents. And we build full applications that include payment processing, user authentication, and a lot, lot more. This also gives you access to live sessions like our Tuesday Coffee sessions and the Thursday Deep Dive sessions. I also want to thank Upstash for sponsoring this video and I highly recommend checking this out. I’ll see you in the next one. Bye-bye.