Como usar vibe coding para planejar antes de delegar tarefas a agentes

Martin abriu a live de domingo com o orquestrador na tela e workers prontos para receber tarefa. A primeira coisa que fez foi proibir o paralelismo. Ele queria decidir os próximos passos do app que está construindo, um aplicativo para ajudar quem quer parar de fumar, e não tinha escopo firme o bastante para mandar ninguém trabalhar.

Antes de delegar, feche o plano com 1 interlocutor só. Quem faz vibe coding com agentes descobre cedo que delegar em cima de escopo instável multiplica retrabalho: cada worker parte de uma suposição própria sobre o que está sendo construído, e desfazer isso custa mais do que o paralelismo economizou. Em 38 minutos de live, a conversa a dois mudou a ordem do projeto inteiro. O mesmo problema apareceu em como planejar um projeto de software.

O roadmap existia e mesmo assim não dava para delegar

Martin já tinha um roadmap, pedido numa janela anterior. Ele abriu a conversa assim: "eu pedi em outra janela que fosse feito um roadmap, mas eu não entendi muito bem quais são os próximos passos".

O orquestrador leu o documento com olhar de quem não tinha escrito ele e apontou um problema de formato. O roadmap estava correto, só que escrito como documento de referência. Eram 10 marcos que na prática valiam 3 fases, e o marco onde Martin estava naquele momento, o da fundação, nem tinha sido numerado. Ambiente montado, marca definida, design system pronto e nenhuma funcionalidade. O app abria bonito no emulador e ainda não fazia nada.

Um documento assim descreve o projeto sem dizer qual é a próxima ação. Delegar a partir dele é pedir para vários agentes interpretarem o mesmo texto ambíguo ao mesmo tempo, cada um puxando para um lado. Isso aparece também em spec driven development.

A fala que segura os workers

O pedido de Martin ao orquestrador foi explícito:

"Não quero que chame nenhum [...] paralelo, nenhum worker por enquanto. Vamos traçar um plano eu e você. Depois a gente sai delegando tarefas."

Os workers continuam previstos na última frase. Eles só entram quando existir tarefa de verdade para entregar a eles, o que abre uma janela curta de trabalho sequencial dentro de uma sessão montada justamente para rodar coisas em paralelo.

O que a conversa a dois revelou sobre a ordem do trabalho

O primeiro resultado do plano foi inverter o que parecia óbvio. Martin ia partir para as telas do onboarding; o orquestrador argumentou que não dá para desenhar a tabela de perfil sem saber exatamente o que o onboarding pergunta. Definir o esquema do banco hoje e descobrir amanhã que falta uma pergunta significa mexer no banco com o app já lendo dele, um retrabalho fácil de evitar enquanto ninguém escreveu tela nenhuma.

Martin repetiu a conclusão em voz alta para confirmar que tinha entendido: "então a gente não vai criar as telas do onboarding antes de criar o esquema". Confirmado, com a ressalva de que o esquema também nasce com a regra de segurança por linha, para que um usuário não leia os dados de outro.

O segundo resultado veio de uma tarefa que Martin tratava como paralela e que era, na verdade, o único input que destravava o resto do marco.

A conversa a dois também corre no sentido inverso. Quando o orquestrador propôs uma avaliação inicial de 8 perguntas, Martin cortou na hora, achou 8 demais para a primeira versão. Um worker recebendo a tarefa pronta teria construído as 8 sem discutir.

Quando o vibe coding volta a ser paralelo

O fim da live mostra o outro lado da regra. Com o escopo fechado, a delegação foi imediata: Martin foi criar o projeto do banco na nuvem, a única parte que dependia das credenciais dele, e liberou o agente para escrever o documento de onboarding ao mesmo tempo, porque aquela entrega não dependia do banco existir. "Sim, pode ir escrevendo o onboarding", ele autorizou.

O paralelismo fica barato depois que alguém consegue dizer, em uma frase, o que cada tarefa entrega e do que ela depende. Antes disso, o agente que recebe a tarefa está adivinhando o escopo junto com você.

Como aplicar isso no seu próximo turno de agentes

Abra 1 conversa só e feche 2 coisas nela antes de abrir a segunda conversa: qual é o marco atual, sem o roadmap inteiro em volta, e qual artefato precisa existir antes de todos os outros. Enquanto uma dessas respostas for "depende", ainda é cedo para delegar.

Desconfie do roadmap bonito. Ele passa a sensação de plano fechado, mas um documento de referência responde "o que existe no projeto" quando você precisa saber o que fazer agora. Se o próximo item não vira uma tarefa com entrada e saída em uma frase, o gargalo está no escopo, e abrir mais agentes só espalha o problema.

E deixe o builder decidir o tamanho. Foi Martin, não o orquestrador, quem cortou a avaliação de 8 perguntas para uma versão menor. Essa decisão some quando o plano é gerado e distribuído no mesmo movimento, e mantê-la é o que o vibe coding faz de melhor: quem sabe o que o produto precisa continua no circuito, definindo o escopo antes de a máquina multiplicá-lo. É também o que as leis do movimento cobram de quem constrói em público: o corte aparece na hora, na frente de quem está assistindo. Foi o mesmo caminho de o que e prd.

Dá para ver o plano sendo fechado em tempo real, antes de qualquer tarefa sair para os agentes, ao assistir à live no YouTube.