Vibe coding para travar decisão de escopo antes de fechar o plano

A hora mais barata de resolver uma ambiguidade de escopo é a última linha do plano. Depois dela, a mesma pergunta vira tela desenhada e integração ligada, e responder deixa de custar 1 frase e passa a custar retrabalho. Numa live de build in public, um agente de planejamento parou exatamente ali: o plano estava pronto para fechar, e ele se recusou a fechar sozinho.

O que ele devolveu, literal:

"Antes de fechar, eu preciso travar duas decisões que mudam o escopo todo. Todas essas duas mudam o plano inteiro. Responde e eu fecho o plano."

O critério da interrupção está na própria frase: decisão que muda o plano inteiro. Dúvida de detalhe não entra nessa conta. É essa triagem que separa um agente que pergunta na hora certa de um que pergunta o tempo todo até virar formulário de cadastro.

As 2 decisões, e a que dá para ler

Das 2 que o agente segurou, só 1 sobrevive legível na gravação: como a captação funciona no lançamento da página. Ele desenhou 2 caminhos. No primeiro, lista de espera com WhatsApp e agenda, e Thiago fecha a venda na mão, conversa por conversa. No segundo, self-service, com a pessoa comprando sozinha na página.

Os 2 caminhos não constroem o mesmo produto. Um pede formulário de espera e um fluxo de conversa que termina numa proposta. O outro pede checkout e liberação de acesso automática, além de tudo que vem junto de receber dinheiro sem alguém no meio conferindo. Um agente que escolhesse ali por conta própria estaria trocando metade do backlog na moeda do palpite.

A outra decisão está corrompida na legenda a ponto de não dar para saber qual era. Eram 2, e só 1 delas dá para contar sem inventar o resto.

Por que o vibe coding precisa desse tipo de parada

Ambiguidade que o plano não resolve não desaparece, ela desce para a execução. No plano, ela custa 1 pergunta e a resposta cabe em 1 linha. Na execução, ela já custou o código escrito em cima da suposição errada, e agora custa o código mais o trabalho de desfazê-lo.

E o agente escolhendo sozinho nunca é uma escolha neutra. Ele vai no caminho mais comum, que é o que mais aparece nos dados de onde ele aprendeu. Para um produto de software vendido na internet, o default estatístico é self-service com checkout. Seu produto pode não ser o caso comum, e no vibe coding quem sabe disso é você, não o modelo: a informação que decide está na sua conta bancária e na sua disposição de atender gente no WhatsApp. Foi o mesmo caminho de vibe coding para congelar decisao de escopo e nao reabrir.

O inverso também vale como regra. Se o agente nunca te interrompe antes de fechar um plano, ou o plano é trivial, ou ele está decidindo por você em silêncio, e você só vai descobrir o que ele decidiu quando a tela estiver pronta.

A resposta certa não estava no menu

O builder não escolheu nenhuma das 2 opções. Ele respondeu que queria "as duas opções" ao mesmo tempo: quem quiser comprar direto na página compra e já acessa, e quem preferir assiste a um vídeo de venda e é levado para uma conversa no WhatsApp, onde ele mesmo conduz até o fechamento.

Um agente que tivesse assumido a decisão teria escolhido 1 dos 2 caminhos e construído metade do que o dono do produto queria, com toda a segurança de quem seguiu a prática recomendada do mercado. A pergunta valeu justamente porque a resposta certa não estava no menu que o agente montou. Ele fez o menu bem feito, com 2 opções coerentes, e ainda assim a resposta era "os 2", que só quem tem pele no jogo dá.

Esse mesmo builder já tinha passado por uma parada parecida em outro momento, no questionário de negócio no vibe coding. A diferença de posição importa: lá as perguntas vêm antes de o plano existir e são sobre a pessoa e as restrições dela, aqui elas vêm no momento de fechar e são sobre o escopo do produto. Vale ver como isso terminou em vibe coding para prompt de corrigir bug com plano antes de executar. Isso aparece também em cursor pro.

O que fazer para o seu agente parar no lugar certo

Escreva a regra de parada onde o planejador vai ler, no arquivo de instruções do projeto ou no próprio prompt de planejamento, e escreva o critério pelo tamanho do estrago: antes de entregar o plano, liste as decisões que mudam mais de 1 módulo ou que mudam o que precisa ser construído, e pare para perguntar só essas. Peça as opções escritas com a consequência de cada uma no que vai ser construído, do jeito que o agente fez aqui, com lista de espera de um lado e checkout do outro. Uma opção sem consequência declarada não dá para responder.

Peça também o inverso: uma lista curta das decisões que ele tomou sozinho e não achou que valiam interrupção. É nessa lista que moram as surpresas, e se ela vier vazia num plano grande o agente não fez triagem, ele só não te contou o que decidiu.

E quando ele parar, responda como dono. Escolha pelo negócio que você quer operar e não pela facilidade de implementação, e diga isso em 1 frase curta, sem justificar. Se a resposta certa for "os 2", responda "os 2" e diga o que cada caminho precisa entregar para o cliente, porque essa parte o agente não tem como adivinhar. Se você não souber responder, é sinal de que a decisão precisava mesmo subir para você, e o plano espera enquanto você decide, porque essa espera é sempre mais barata que a refação.

A gravação mostra a decisão sendo tomada, não o plano rodando em produção. Dá para assistir à live e ver o momento em que o agente para, oferece 2 caminhos e recebe uma resposta que não estava em nenhum deles.