Vibe coding para instrução negativa quando o agente foge do padrão
O agente trocou a ferramenta de imagem por Python e a série de capas saiu do padrão. Por que "siga o padrão" não bastou e o que falta na correção.
Um agente gera as primeiras peças de uma série, você olha o resultado, aprova, e aquilo vira o padrão. Nas peças seguintes ele atende o mesmo pedido por outro caminho, e o padrão se desfaz sem que ninguém tenha mudado uma vírgula do que foi pedido. Jhonatan passou por isso ao vivo, gerando as capas do projeto: as primeiras saíram certas, e nas seguintes o agente desenhou a capa em código, com Python, em vez de usar a ferramenta de imagem que tinha gerado as anteriores.
A lição que ele tirou dali é sobre a forma da correção. Pedir "siga o padrão" é instrução positiva, e isso ele já dava. O que ele concluiu que falta é a instrução negativa, dizer explicitamente qual caminho o agente não pode usar. A live termina com ele anunciando que vai aplicar a ideia, e o problema segue aberto quando a transmissão acaba.
O que mudou foi a rota, e a rota é o que sustenta a série
Quando as capas novas apareceram fora do padrão, o diagnóstico dele foi imediato:
"É porque ele usou o python aqui."
O pedido era o mesmo. O caminho para atendê-lo foi outro. Em vez da ferramenta de imagem que produziu as primeiras capas, o agente escreveu código e desenhou a capa ali dentro. Os 2 caminhos entregam uma capa, e os 2 cumprem o que foi pedido ao pé da letra. Só que cada um tem seu jeito próprio de tratar tipografia, espaçamento, corte e cor, então o que sai de um dificilmente encosta no que sai do outro, e a consistência da série, que parecia estar no pedido, estava na rota que ninguém tinha combinado explicitamente.
A correção dele nomeia o caminho certo e fecha o errado
Ele escreveu a correção assim:
"Eh, você não usou as mesmas ferramentas para criar a capa. Então, eu quero que você copie usando a mesma ferramenta que você criou, aquelas primeiras capas. Não use Python se for o contexto que você fez aqui."
O formato dessa frase tem 2 metades. A primeira nomeia a rota obrigatória, "a mesma ferramenta que você criou aquelas primeiras capas". A segunda fecha a saída lateral que ele acabou de ver acontecer, "não use Python". A proibição vem depois da obrigação, e as 2 apontam para a mesma peça.
Mesmo com a proibição escrita, o padrão não voltou
A série tinha começado bem, e ele marcou isso em voz alta:
"O primeiro ele fez certinho. Buf. Beleza, esse é o padrão."
Com a correção aplicada, o agente entregou de novo. O veredito:
"Não pegou nenhum padrão. Esqueceu do padrão. Não, não. Tá errado."
A live não mostra a instrução negativa funcionando. Ela mostra o problema aparecendo, a correção sendo escrita, o agente reincidindo, e só então o diagnóstico.
O diagnóstico dele: a positiva ela já dá
Na conversa, alguém sugeriu instruir o agente a seguir sempre um design fixo. A resposta dele foi esta:
"Então eu até eu instruo isso aí, mas o que que ele faz é que é [...] Ele é as negativas que você falou lá que eu preciso fazer, velho. Porque ele foge do estilo de criação."
O corte no meio é da legenda automática, que embaralha 1 palavra ali. A sugestão do design fixo veio de outra pessoa da conversa, e a fala acima é a resposta dele: já instrui isso, e o que falta são as negativas.
Por que isso aparece tanto no vibe coding
No vibe coding você aprova por resultado. Você olha a peça pronta, ela está dentro do padrão, e aprova. A rota que produziu a peça não entra na aprovação porque ela nem aparece: enquanto o resultado sai parecido, a rota fica invisível, e ela só se torna visível no dia em que muda. Some a isso que o agente escolhe a rota a cada pedido, e o que funcionou ontem deixa de ser garantia de qualquer coisa hoje. Isso aparece também em vibe coding para nao montar o agente na mao.
Instrução negativa e saber pedir puxam para lados diferentes
Um movimento vizinho a este é saber pedir para o agente, que trata de acrescentar ao pedido a sua hipótese da causa e o papel certo para quem vai executar. Ali o trabalho é somar informação positiva. Aqui o assunto é o caso em que somar informação positiva não resolve, porque o pedido já dizia o que fazer e o agente foi por fora mesmo assim, e a saída é proibir o desvio pelo nome. No vibe coding os 2 movimentos são complementares, não concorrentes.
Minha leitura do caso, e ela não está na live
Proibição isolada não generaliza. Proibir 1 caminho deixa todos os outros abertos, e o agente que não pode usar Python ainda pode escolher outra rota qualquer para desenhar a mesma capa. O que funciona é o par, nomear a rota obrigatória e proibir o desvio que você viu acontecer, que é exatamente o formato da frase que ele escreveu.
Instrução negativa dita no chat morre com a sessão. Se a proibição não estiver num lugar que o agente lê sozinho a cada pedido, você vai redigitá-la em toda sessão nova. Vale também verificar os limites da estrutura antes de acreditar que uma coisa cabe no molde que você desenhou. Isso vale especialmente quando múltiplos contextos precisam concordar, como em centralizar comentários numa caixa de entrada, quando os limites vêm da ferramenta que você escolheu, e quando você precisa documentar as regras negativas para a próxima sessão.
O sinal mais útil da cena não é sobre proibição. Quando o agente abandona um resultado que já tinha sido aprovado, em geral é porque o pedido nunca registrou por que aquele resultado foi aprovado. Ele guardou a peça e não guardou o critério. A capa aprovada ficou no histórico como imagem, sem nada dizendo o que nela era o padrão.
O que fazer amanhã
Quando aprovar uma peça gerada, anote junto qual caminho a produziu. Essa é a informação que você vai precisar citar no dia em que o agente desviar, e é a que costuma ficar de fora, porque na hora da aprovação ela parece irrelevante.
Depois escreva a correção no formato do par: a rota obrigatória mais a proibição do desvio que você observou. É um trabalho chato de vibe coding, e é o que segura uma série de peças de pé quando você não vai revisar cada uma na mão. Antes de testar qualquer resultado gerado que interaja com o mundo exterior (disparos, e-mails, chamadas à API de terceiros), use ambiente local para validar. Dá para acompanhar a cena completa, com as capas na tela, na live em que ele gera as capas do projeto.