Prompt claro no vibe coding: quando X, preciso de Y, porque Z

Quando a IA não entrega a feature que você pediu, o defeito costuma estar na frase que você escreveu. myosbad topou com isso ao vivo, no meio de um sistema que ele está construindo para um cliente, um painel com contatos, funil, conversas e disparo. Ele queria um botão para tirar um lead do fluxo automático e passar aquele atendimento para a mão. O botão não aparecia.

Em vez de mandar o mesmo pedido outra vez, ele parou e falou o que estava faltando:

Caramba, mano. Tem que explicar certinho, exatamente o que eu quero. Cara, eu vou explicar pela última vez.

Aí reescreveu o pedido em voz alta enquanto digitava. A frase que saiu tem 4 partes, e as 4 partes servem para qualquer feature que você for pedir.

O primeiro pedido não dizia onde o botão deveria morar

Mais cedo na mesma live, ele ditou assim:

Continua sem aparecer o botão de tirar o cliente do fluxo parar de entregar mensagens do fluxo e botar para atendimento manual.

A frase nomeia o botão e emenda os comportamentos dele, mas não diz em que momento do sistema esse botão aparece, nem em que tela ele mora, nem que problema ele resolve para quem usa. Quem lê tem que adivinhar o lugar, e quando a adivinhação erra, a feature existe em algum canto do código e não existe na tela que você está olhando.

As 4 partes do pedido reescrito

Este é o pedido inteiro, do jeito que ele falou, gagueira e tudo:

quando um cliente quando começa o disparo e disparo em um contato, eu preciso que tenha o botão online em cima de conversas para tirar o lead do fluxo, porque às vezes Você vê que o lead precisa de algo que não está no fluxo. No fluxo. Então esse botão tira o lead do fluxo.

O gatilho vem primeiro: "quando um cliente quando começa o disparo e disparo em um contato". É o estado do sistema em que a coisa acontece. Sem ele, quem lê não sabe se o botão fica sempre visível, se aparece por contato ou se depende de um disparo rodando.

Depois vem o que precisa existir, com o endereço na mesma frase: "eu preciso que tenha o botão online em cima de conversas". O trecho "em cima de conversas" é a informação que faltava antes, e é a diferença entre a feature aparecer e a feature ficar escondida numa rota que ninguém abre.

Depois o efeito: "para tirar o lead do fluxo". O botão faz uma coisa e essa coisa tem nome, então dá para testar clicando.

E no fim o motivo: "porque às vezes Você vê que o lead precisa de algo que não está no fluxo". É a parte que costuma ficar de fora.

O motivo é o que salva o pedido quando ele fica ambíguo

Nenhum pedido de feature fecha todos os buracos, e no vibe coding isso pesa mais, porque quem preenche o buraco escreve o código antes de você olhar. Sempre sobra alguma decisão que você não tomou, como o que acontece com as mensagens que já estavam na fila quando alguém aperta o tal botão. Quem estiver do outro lado vai fechar esses buracos de algum jeito. Foi o mesmo caminho de como fazer um prompt.

Com o motivo escrito, essas decisões deixam de ser sorteio. Sabendo que o botão existe porque "o lead precisa de algo que não está no fluxo", o assistente ganha um critério: qualquer solução que interrompa o fluxo e leve a conversa para atendimento manual serve, e uma que só mude um status no banco fica de fora. Sem o motivo, as duas parecem igualmente boas.

O motivo também é o que você usa para conferir o resultado. Um botão que existe e não tira ninguém de fluxo nenhum passa como entregue se o pedido só falava em botão, e reprova na hora se o pedido dizia para que ele servia.

Como montar um prompt claro no vibe coding

Antes de apertar enter, leia a sua frase e veja se ela responde 4 coisas: quando aquilo acontece, o que precisa existir e em que tela, o que isso faz, e que problema resolve para quem vai usar. Se a resposta de alguma delas estiver só na sua cabeça, ela ainda não está no pedido.

Repetir o mesmo pedido esperando um resultado diferente é o sinal de que ele precisa ser reescrito. Foi o que ele fez quando disse que ia explicar pela última vez: em vez de reenviar, abriu a frase e colocou dentro dela o gatilho, o lugar, o efeito e o motivo. Isso aparece também em como validar ideia de plataforma no vibe coding. Essa reescrita é a parte do vibe coding que raramente aparece nos vídeos, porque não tem tela bonita, é você olhando para a própria frase.

Ele fechou com "Deu para entender agora.", mandou e ficou olhando: "Aí, agora sim. Vamos ver se vai entender, mano." Em seguida já estava abrindo outra pasta para começar um site, então a live não mostra o botão pronto na tela. O que ela mostra é a reescrita inteira, ditada em voz alta com a câmera ligada, que é o tipo de coisa que as leis do movimento cobram de quem constrói em público. Dá para assistir à live e ouvir o pedido sendo montado palavra por palavra, antes de existir qualquer resultado.