Vibe coding para prompt de corrigir bug com plano antes de executar e conferência depois

Quando o pedido é só "corrige os bugs", quem escolhe por onde começar é o agente. Ele decide o que investigar e devolve código já escrito. Na live "Day 01 - CavernaCODING", danilixz mandou o pedido de conserto com 4 exigências penduradas nele, e nenhuma das 4 fala do bug. Todas falam da ordem do trabalho: o que vem antes de mexer no código, e o que vem depois.

O texto não era um prompt isolado de manutenção. Ele vinha emendado num pedido maior, em que o builder pedia uma mudança de comportamento no fluxo do próprio projeto, e as exigências foram anexadas ali no fim:

"E eu quero que tu Corrija os bugs, utilizando as melhores skills, squads e agentes competentes para cada tarefa. E antes de executar, quero o planeamento completo, como se virar. E preciso também que contenha um debugger para analisar os [...] e caso necessite de um revisor para analisar antes [...] do ver final."

A citação está como a legenda automática capturou, e os [...] marcam onde ela comeu palavras. A primeira cláusula, a das "melhores skills, squads e agentes competentes para cada tarefa", é a mais fácil de escrever e a que menos depende dele. As outras 3 são as que reorganizam o trabalho, e é nelas que está a sacada.

O que custa rejeitar um plano e o que custa rejeitar um diff

"E antes de executar, quero o planeamento completo." A diferença entre receber um plano e receber um patch aparece no que sobra para você decidir. Diante de um plano, você ainda escolhe a abordagem: esse arquivo não, comece pelo log em vez do schema. Diante de um patch, você está revisando a escolha que o agente já fez, com os arquivos já alterados na tela.

E a inércia trabalha a favor do que já está escrito. Rejeitar um plano custa uma frase. Rejeitar um diff que roda custa reverter, explicar por que a abordagem certa era outra e pagar de novo o tempo de execução. Na prática, muita gente fica com o patch mais ou menos porque desfazer dá mais trabalho do que conviver com ele, e exigir o plano antes é o que evita chegar nesse ponto.

O trabalho volta conferido antes de chegar em você

Ele podia ter parado no plano. No mesmo texto, pediu também um debugger para analisar e um revisor para conferir "antes [...] do ver final". São 2 momentos separados: um olhando o que de fato está acontecendo no código, outro olhando o que foi feito depois do conserto.

O caminho normal do vibe coding é o builder ser o único revisor. O agente entrega, e você lê o diff, roda e descobre o que quebrou. Escrito assim, parte dessa leitura acontece antes de o trabalho chegar em você, e o que chega já passou por um olho a mais. Tudo isso coube no mesmo texto do pedido, sem nenhuma etapa nova de fluxo em volta.

Onde o prompt de vibe coding costuma gastar as palavras

Em vibe coding, a descrição do problema costuma levar toda a atenção do builder, e a ordem do trabalho quase nenhuma. O pedido do danilixz é curto na parte técnica, ele nem diz quais são os bugs, e detalhado na parte de processo. Isso é uma escolha sobre onde gastar as palavras do prompt. O mesmo problema apareceu em vibe coding para distinguir falha de worker redundante de bug real.

Faz sentido gastar ali. O agente lê o código e descobre o que está quebrado melhor do que você descreve de memória, mas não tem como adivinhar quanto de autonomia você quer dar nessa tarefa, que é justamente a informação que só existe do seu lado.

O mesmo plano antes, por 2 caminhos

Em planejar antes de delegar, outro builder chega no mesmo lugar por outro caminho. Ele fecha o plano conversando com um agente só, e proíbe execução em paralelo enquanto o escopo não estiver firme. O plano ali é uma conversa que o humano conduz, rodada a rodada.

Aqui o plano é um entregável exigido dentro do próprio pedido, escrito de uma vez. São 2 jeitos de pôr o plano antes da execução, com custos diferentes. A conversa custa tempo do builder, e em troca ele sabe exatamente o que está no plano. A exigência escrita não custa nada na hora, e depende inteiramente de o agente obedecer.

O que a live não responde

Daqui em diante é leitura minha. A live não mostra o resultado: logo depois de mandar o texto, danilixz volta a mexer na transmissão e o assunto muda. Não existe cena de plano entregue, de debugger rodando nem de revisor aprovando. Dá para assistir à live e não descobrir se alguma das 4 exigências foi cumprida.

Pedir o plano no mesmo texto que já autoriza a execução não garante parada. "Antes de executar" descreve uma ordem, e o mesmo texto já mandou corrigir os bugs. Sem exigir explicitamente que o agente pare e espere seu aval, ele pode imprimir o plano e emendar o código na mesma resposta, cumprindo a letra do pedido.

Revisor que é o mesmo agente herda os mesmos pontos cegos. Quem escreveu a solução acha que ela está certa, senão teria escrito outra. Aprovar o próprio trabalho é o cenário mais fácil de todos, e um revisor que sempre aprova entrega a sensação de conferência sem a conferência.

E pedir "as melhores skills, squads e agentes competentes" só tem efeito se esses papéis existirem de fato na sua configuração. Se existirem, a frase seleciona. Se não existirem, ela é enfeite no prompt, e o agente segue fazendo o que faria de qualquer jeito.

O que escrever no próximo pedido de conserto

Escreva a ordem em vez de deixá-la implícita: o plano primeiro, uma parada para o seu aval, a execução depois, e a conferência antes de você considerar o trabalho terminado. São 4 passos e cabem em 2 linhas no fim do prompt. A que mais falta nos prompts é a parada, porque é a única que tira do agente a decisão de seguir sozinho. Junto com a ordem de trabalho, confirme também o que está protegido no banco: rls supabase mostra a camada de defesa que costuma sair invisível nos pedidos de funcionalidade. E quando a segurança do deploy expõe um painel na internet, verificar o empacotamento antes de auditoria é o que separa um achado legítimo de um falso positivo.