Fluxo de desenvolvimento da VM0: gerenciar agentes de IA como um time

No time de desenvolvimento da VM0, todo desenvolvedor trabalha com várias instâncias do Claude Code ao mesmo tempo. Geralmente, mais de oito.

Tratamos o Claude Code do mesmo jeito que tratamos um desenvolvedor de verdade. (Sim, nossa empresa é meio que de brincadeira chamada de AI Colleagues Co!)

Por causa disso, a filosofia de design por trás do fluxo de desenvolvimento da VM0 espelha as práticas clássicas de gestão de times em engenharia de software.

Usamos GitHub Issues para acompanhar o trabalho, Pull Requests para revisão e merge de código, e GitHub Actions para cuidar da automação. Ao longo de dois meses, essa configuração nos ajudou a lançar 404 releases e escrever mais de 230.000 linhas de código.

Este post explica como tornamos isso viável e por que o problema central nunca foi a capacidade da IA, e sim a coordenação humana.

O fluxo de desenvolvimento com IA na prática

Quando você coordena muitos agentes de IA em paralelo, o gargalo não é se o modelo consegue escrever código. O verdadeiro gargalo é a carga cognitiva humana.

Este fluxo de trabalho é composto por 14 slash commands, organizados em três camadas: Deep Dive, Issue Management e PR Management.

Vamos primeiro ver como é o meu fluxo de trabalho e como um recurso costuma ser construído.

Alinhamento de requisitos

Um humano abre uma sessão do Claude e começa com /deep-research. O Claude reúne fatos a partir da base de código, da documentação e do contexto relevante. Discutimos as descobertas e nos alinhamos sobre qual problema estamos realmente resolvendo.
Exploração de soluções

Usando /deep-innovate, o Claude propõe várias direções possíveis, com seus trade-offs. Discutimos, restringimos as opções e escolhemos uma direção.
Criação da issue

Criamos uma issue no GitHub usando /issue-create. O humano revisa a issue para garantir que os requisitos foram capturados com clareza.
Planejamento e aprovação

Use /issue-plan para deixar o Claude continuar o trabalho. O Claude vai executar automaticamente todo o fluxo de deep-dive e publicar os resultados na issue, incluindo:
1. descobertas do /deep-research
2. comparações do /deep-innovate
3. um plano concreto de implementação do /deep-plan
Implementação

Após a aprovação, /issue-action permite que o Claude implemente o plano, escreva testes, abra um PR e garanta que a CI passe.
Revisão e merge

Usamos /pr-review para uma revisão estruturada e, em seguida, fazemos a revisão humana final antes do merge.

O humano intervém em três pontos de controle: requisitos, direção e aceitação. Todo o resto roda de forma autônoma.

Mudança de mentalidade: você está liderando um time de desenvolvedores de IA

O momento em que percebi que precisávamos de um fluxo de trabalho estruturado foi quando adicionar mais sessões do Claude na verdade piorava as coisas. Quanto mais instâncias eu rodava em paralelo, mais difícil ficava acompanhar o que cada uma estava fazendo, em que estado o trabalho estava e o que já havia sido decidido.

Sem ferramentas externas, eu simplesmente não conseguia gerenciar tantas instâncias do Claude de uma vez. Foi aí que a ficha caiu: isso não era um problema de IA, era um problema de gestão.

O GitHub já é a ferramenta natural para colaboração em desenvolvimento de software, então, em vez de inventar algo novo, comecei a tratar o Claude do mesmo jeito que trato um colega humano. Assim que fiz isso, minha capacidade de gestão de repente escalou.

Dez anos de experiência em gestão de projetos e times finalmente fizeram sentido nesse novo contexto. Ao tratar o Claude como um membro do time e o GitHub como nosso espaço compartilhado de comunicação e gestão, todo o sistema voltou a ser gerenciável.

Um bom líder de time sabe quando se envolver e quando dar um passo atrás:

Ponto de controle	O que eu faço	O que a IA faz
Requisitos	Alinhar o problema, esclarecer o escopo	Pesquisar a base de código, reunir contexto
Direção	Revisar descobertas, aprovar abordagem	Propor 2 a 3 abordagens, avaliar trade-offs
Aceitação	Revisar o PR, verificar a qualidade	Implementar, testar, corrigir a CI

Isso espelha como times de software eficazes operam. Eu não faço microgerenciamento do desenvolvedor, mas defino requisitos claros, reviso decisões-chave e verifico o resultado final. O mesmo princípio se aplica ao gerenciar agentes de IA.

O fluxo de deep dive impõe um pensamento estruturado e lento

O fluxo de deep dive impõe um pensamento deliberado antes da implementação. Às vezes o Claude chega a um beco sem saída. Quando isso acontece, forçamos o Claude a parar e pensar, e então discutimos juntos. Ele tem três fases:

Fase	Comando	Objetivo	Saída
Pesquisa	/deep-research	Reunir fatos, entender o contexto	research.md
Inovação	/deep-innovation	Explorar múltiplas abordagens	innovate.md
Plano	/deep-plan	Definir passos concretos	plan.md

Cada fase tem limites rígidos.

Pesquisa: nenhuma sugestão
Inovação: nenhum detalhe
Plano: nenhuma implementação

Essas restrições forçam o Claude a um raciocínio lento e deliberado, em vez de pular direto para o código. Sem elas, casos extremos e preocupações de arquitetura costumam passar despercebidos!

Exemplo de uso

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Para tarefas simples, você pode pular o deep dive e ir direto para o /issue-create.

Para tarefas complexas com incerteza técnica, as fases de deep dive ajudam a garantir que você e o Claude estejam alinhados antes de a implementação começar.

Use o GitHub como memória compartilhada

A maioria das ferramentas de IA trata o contexto como algo temporário. Quando a sessão termina, a memória desaparece.

A VM0 usa o GitHub como memória persistente:

Recurso do GitHub	O que ele armazena
Corpo da issue	Requisitos e decisões
Comentários da issue	Pesquisa, opções, planos
Comentários do PR	Revisões e resumos
Labels	Estado do fluxo de trabalho

Isso também resolve um problema humano: a recuperação de contexto.

Quando estou gerenciando mais de 8 instâncias do Claude, recebo notificações de que o trabalho está concluído. Mas não consigo reconstruir, a partir da conversa do Claude, o que ele estava fazendo, quais decisões foram tomadas ou qual é o estado atual.

As issues do GitHub resolvem isso. Cada issue exibe:

Os requisitos originais
As descobertas da pesquisa (o que foi descoberto)
A fase de inovação (quais opções foram consideradas)
O plano aprovado (o que será implementado)

Esse formato estruturado torna a revisão eficiente. Assim, consigo escanear rapidamente as fases, entender a abordagem e aprovar ou solicitar mudanças, tudo sem precisar lembrar da conversa original.

Quando o trabalho termina, não preciso lembrar o que aconteceu em uma janela de chat. Posso abrir a issue e ver a história completa, estruturada e registrada por escrito.

Passagem de bastão entre agentes

Como todo o contexto vive no GitHub, o trabalho pode passar de um agente para outro sem atrito:

Um agente cria uma issue ou um PR
Outro continua mais tarde usando /deep-research issue 123 ou /issue-plan 123 ou /deep-research PR 124

Para discussões longas, /issue-compact consolida tudo em um corpo de issue limpo. Isso facilita as passagens de bastão tanto para humanos quanto para a IA.

Vamos resumir os padrões do fluxo de trabalho

Depois de tudo isso, deixe-me resumir algumas dicas práticas.

Tarefas simples

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Use isto quando os requisitos estiverem claros e o trabalho for direto.

Tarefas complexas

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Isso evita esforço desperdiçado na abordagem errada.

Trabalho em paralelo

Vários agentes podem trabalhar ao mesmo tempo enquanto o humano revisa os pontos de controle concluídos. É aqui que o fluxo de trabalho escala melhor.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Referência de comandos

Comandos de deep dive

Comando	Objetivo
`/deep-research`	Reunir informações, entender a base de código. Nenhuma sugestão permitida.
`/deep-innovate`	Explorar 2 a 3 abordagens, avaliar trade-offs. Nenhum código permitido.
`/deep-plan`	Criar passos concretos de implementação. Nenhuma implementação permitida.

Comandos de issue

Comando	Objetivo
`/issue-create`	Criar uma issue a partir do contexto da conversa
`/issue-bug`	Criar um relatório de bug com passos de reprodução
`/issue-feature`	Criar um pedido de recurso focado em requisitos
`/issue-plan`	Executar todo o fluxo de deep-dive e publicar os resultados na issue
`/issue-action`	Continuar a implementação após a aprovação humana
`/issue-compact`	Consolidar o corpo da issue + comentários para a passagem de bastão

Comandos de PR

Comando	Objetivo
`/pr-check`	Monitorar o pipeline de CI, corrigir automaticamente, repetir até 3x
`/pr-review`	Revisar o PR commit a commit em relação aos padrões do projeto
`/pr-comment`	Resumir a discussão da conversa em um comentário do PR

Como começar

Comece simples: use /issue-create → /issue-plan → /issue-action na sua primeira tarefa
Adicione o deep dive para tarefas complexas: quando os requisitos não estiverem claros ou forem tecnicamente complexos, comece com /deep-research
Escale gradualmente: adicione mais instâncias do Claude à medida que se sentir confortável com o ritmo de revisão
Confie no processo: deixe o Claude trabalhar de forma autônoma entre os pontos de controle

O fluxo de trabalho foi pensado para ser adotado de forma incremental. Você não precisa usar todos os 14 comandos desde o primeiro dia. Comece com o fluxo básico de issues e depois adicione as fases de deep dive e o trabalho em paralelo à medida que ganhar confiança.

Considerações sobre escala: o que fazer quando você tem mais agentes

O fluxo de trabalho foi testado com mais de 10 instâncias simultâneas do Claude. Nossa recomendação:

Até 10 agentes: confortável para uma colaboração profunda com cada um
Além de 10: não recomendado

O fator limitante não é o fluxo de trabalho, é a atenção humana e a qualidade das decisões. Ao gerenciar mais de 10 agentes, você corre o risco de se tornar um gargalo nos pontos de controle de revisão, e a qualidade das decisões começa a se degradar.

O clássico princípio do "time de duas pizzas" se aplica aqui. As mesmas restrições que limitam o tamanho de um time humano também limitam quantos agentes de IA uma pessoa consegue gerenciar de forma eficaz.

No momento, estou explorando uma estrutura de time em dois níveis 8×8 para escalar além de 10 agentes, mas ainda não desenvolvi práticas eficazes. Compartilharei mais quando houver resultados concretos…

O fluxo de desenvolvimento da VM0 muda a forma como pensamos o desenvolvimento de software quando a IA passa a fazer parte do time.

Quando você trata os agentes de IA como membros do time, e não como ferramentas, tudo se encaixa. O GitHub vira a memória compartilhada do seu time. As issues viram itens de trabalho. Os PRs viram entregáveis. E você vira o líder do time, focando em arquitetura, direção e qualidade, enquanto seu time de IA cuida da implementação.

Foi assim que lançamos 404 releases em 2 meses. E é assim que você pode escalar o seu próprio desenvolvimento com IA.