Fábrica de software com IA: do worktree à entrega

Por que isso importa

Quando vários agentes conseguem escrever código ao mesmo tempo, o gargalo passa a ser conferir o que produziram. Dez funcionalidades aparentemente prontas podem virar dez decisões pendentes, cada uma exigindo reconstruir contexto, reproduzir o problema e descobrir o que realmente foi testado.

Na conversa com Greg Isenberg, Ras Mic apresenta sua fábrica de software como um processo de quatro etapas: isolar, construir, provar e entregar. O interesse está na passagem entre elas: o agente precisa apresentar evidências para avançar e voltar ao trabalho quando encontra uma falha. É uma abordagem útil para quem mantém aplicações, integrações ou produtos pequenos sem uma equipe exclusiva de qualidade.

Minha régua para avaliar esse modelo seria simples: ele reduz o tempo necessário para aceitar uma mudança com confiança? Abrir mais terminais só interessa se a revisão continuar administrável. A proposta abaixo acrescenta critérios de aceite, limites para as repetições e uma verificação da integração — pontos que precisam acompanhar a demonstração para o método funcionar no cotidiano.

Pontos principais

• 15:09 A entrega precisa ser verificável. Mic pede registros do comportamento anterior e posterior à mudança. O ganho é transformar a afirmação do agente em algo que outra pessoa consegue avaliar. Uma captura ajuda a conferir a interface; a correção de uma regra exige também observar seus resultados.
• 05:22 Cada tarefa recebe seu espaço de trabalho. O uso de Git worktrees permite que agentes editem diretórios separados. Isso resolve a disputa pelos mesmos arquivos durante a execução, mas ainda exige coordenação quando as mudanças voltam para a aplicação principal.
• 12:24 Código funcionando ainda precisa ser compreensível. A orientação de estrutura adotada por Mic procura facilitar a leitura e a manutenção. O princípio aproveitável é registrar os padrões do projeto e cobrar consistência, adaptando a arquitetura ao tamanho da aplicação.
• 22:11 Uma revisão externa alimenta o próximo ciclo. Greptile examina a proposta de alteração, ou PR, e o agente trata os apontamentos antes de solicitar nova revisão. Mic também menciona CodeRabbit e Macroscope como alternativas. A contribuição é separar a produção do código de uma segunda avaliação.
• 25:26 A escala apresentada depende desse processo. Mic relata trabalhar em 15 funcionalidades simultaneamente e entrar para fazer o merge após a revisão atingir sua exigência. É um relato de uso; a capacidade de revisão de cada projeto precisa determinar seu próprio limite de tarefas abertas.
• 29:13 As instruções concentram o método. A implementação descrita usa arquivos Markdown para organizar o fluxo. Isso facilita carregar os critérios entre ferramentas, desde que cada ambiente tenha os recursos necessários para executar testes, registrar evidências e receber avaliações.

Como aplicar

Comece a fábrica de software por uma entrega pequena

Escolha uma mudança cujo resultado você consiga conferir em poucos minutos. Um exemplo é corrigir a exportação CSV de um relatório que ignora o filtro de período. Antes de abrir o agente, escreva três condições: o arquivo respeita as datas selecionadas, mantém os valores corretos e contém apenas registros que aquele usuário pode consultar.

Em um produto brasileiro, acrescente exemplos com nomes acentuados e valores monetários. Defina também o separador e o formato decimal esperados pelo sistema que receberá o arquivo. Esses exemplos são uma proposta de aplicação: tornam a tarefa concreta e permitem avaliar a entrega sem depender da interpretação do agente.

Isole os arquivos e organize a execução

Em um repositório já configurado com origin/main, este exemplo cria um diretório e um branch para a tarefa:

git fetch origin
git worktree add -b fix/exportacao-periodo ../app-exportacao origin/main
git worktree list

O agente deve trabalhar dentro de ../app-exportacao. Essa é a função dos worktrees: manter múltiplos diretórios de trabalho ligados ao mesmo repositório. Consulte a documentação oficial do Git worktree para adaptar o comando ao seu projeto.

Para executar duas versões da aplicação, atribua uma porta a cada uma e confira os recursos compartilhados. Um banco de teste usado pelos dois agentes pode produzir interferências mesmo com os arquivos separados. Minha recomendação é começar com uma tarefa e acrescentar a segunda apenas depois de conseguir reproduzir e revisar a primeira.

Registre o caminho até uma entrega aceitável

Use o arquivo de instruções reconhecido pela sua ferramenta. Se ela lê AGENTS.md, registre ali a ordem do trabalho e os comandos reais do projeto. Evite instruções vagas como “teste bem”. Especifique como iniciar a aplicação, quais verificações executar e onde anexar os resultados.

Um roteiro inicial pode exigir:

1. Reproduzir o problema com dados de teste conhecidos.
2. Alterar o código seguindo os padrões existentes.
3. Executar as verificações pertinentes à mudança.
4. Registrar o resultado e os limites do que foi verificado.
5. Abrir o PR e tratar os apontamentos da revisão.

O repositório oficial de Ras Mic reúne suas skills e um modelo de fluxo. Use-o como referência para escrever instruções que correspondam à sua aplicação. Uma regra de arquitetura só ajuda quando facilita entender e modificar aquele código.

Faça a evidência responder ao critério de aceite

Para a exportação, filmar o clique no botão comprova apenas uma parte do caminho. O pacote de evidências precisa permitir conferir o conteúdo produzido.

| Critério | Evidência útil | | --- | --- | | Respeitar o período | Dados de entrada conhecidos e comparação das linhas exportadas | | Preservar valores | Verificação dos totais e exemplos de formatação | | Respeitar o acesso | Teste com usuários de permissões diferentes | | Manter o fluxo utilizável | Registro da seleção do filtro e do download |

Peça que o PR identifique o commit testado, os comandos executados e os resultados. Se houver uma etapa que o ambiente não consegue verificar, ela deve aparecer como pendência. Isso permite decidir exatamente o que ainda precisa de uma conferência manual.

Limite as repetições e confira a integração

A skill oficial Greploop organiza a repetição de revisão e correção até atingir seus critérios. Eu começaria com um limite operacional de três rodadas automáticas. Ao atingir esse limite, o agente deve apresentar o bloqueio e as tentativas feitas para uma pessoa decidir como continuar.

O objetivo é resolver problemas concretos. Uma nota 5/5 não demonstra, por si só, que todos os critérios do produto foram atendidos. Confira os apontamentos, os testes e as evidências em conjunto.

Antes do merge, valide a mudança com o estado atual da branch de destino. Worktrees não eliminam a possibilidade de conflitos no merge, como explica a documentação do Git merge. Além disso, duas alterações podem combinar sem conflito textual e produzir um comportamento errado quando executadas juntas.

Meça o custo de aceitar a mudança

Nas primeiras cinco entregas, anote o gasto com agentes e revisores, os minutos de revisão humana e quantas alterações precisaram de correção depois do merge. Uma conta útil é dividir o custo total pelas mudanças aceitas, incluindo as tentativas abandonadas.

Aumente o paralelismo quando esses números indicarem que você consegue absorver mais trabalho. Se a fila de revisão crescer, melhore os critérios e as evidências antes de abrir outra tarefa. A fábrica começa a trazer vantagem quando cada entrega exige menos investigação para ser aceita.