Vibe coding para saber pedir para o agente: o que falta no "corrige isso"

No vibe coding, o pedido mais repetido é também o que menos entrega: "corrige isso". danilixz estava testando um fluxo do próprio projeto ao vivo quando apareceu um bug ("já chama aqui um bugzinho"), e antes de mandar o agente resolver, ele parou a demonstração para explicar à audiência o que falta nesse pedido.

Faltam 2 coisas, e nenhuma delas é técnica: a sua hipótese sobre a causa do erro, e o tipo de profissional que resolveria aquilo. A fala foi essa:

"vocês têm que saber pedir, saber pedir, tá ligado? Esse é o segredo. E não dizer: \"Ah, corrige lá isso, tá ligado? Não, quero que corrija isto porque eu acredito que você está tratando o erro desta forma, assim, assim, assim. Eu preciso de um profissional competente para resolver a situação"

A hipótese da causa é a informação que só você tem

Repare no "eu acredito que você está tratando o erro desta forma". Aquela frase carrega informação, e a informação diz ao agente por onde começar. Quando o pedido é só "corrige isso", ele precisa antes adivinhar qual é o problema, e o que está mais à mão para ele é o sintoma na tela: a mensagem que apareceu, a linha que estourou. Ele trata o sintoma, o sintoma some e a causa continua onde estava.

Quem viu o comportamento acontecer sabe uma coisa que não está no código nem no log. Você mexeu em algum lugar, esperava um resultado, veio outro. Essa sequência é sua, e o agente só tem acesso a ela se você escrever. Dizer "acredito que o erro está sendo capturado antes da validação rodar" reduz o campo de busca: em vez de varrer o arquivo inteiro atrás de qualquer coisa com cara de bug, ele começa pelo ponto que você indicou.

No vibe coding, o papel pedido também precisa vir escrito

A segunda parte do pedido é o profissional. A explicação foi com encanamento:

"seria a mesma coisa se tiver um problema no encanamento da [...] sua casa e você chamar o pintor para resolver o problema na canalização, tá ligado? Que é que ele vai fazer com o teu problema? Se for pintor, vai pintar a parede do banheiro. [...]\"\n\nUm pintor de verdade, chamado para um cano, provavelmente diria que aquilo não é com ele e passaria o telefone de outra pessoa. O agente aceita o pedido que chegar e sempre devolve alguma coisa, com a mesma confiança, tenha ou não entendido o problema. Por isso o papel tem que vir escrito por você: do outro lado não existe ninguém para recusar o serviço.

Na prática cabe numa frase antes do pedido. "Você é a pessoa que cuida da autenticação neste projeto." "Preciso de alguém que entenda de migração de banco." O agente não vira um especialista por causa disso, mas o que ele abre primeiro e o vocabulário que ele usa mudam.

Quem não diz as 2 coisas não delegou, ficou delargado

O fecho da fala foi um trocadilho:

"Mas se não souber delegar, você está delargado. A diferença de delegar para delargado é exatamente essa."

Delegar para uma pessoa competente tem o mesmo formato: você conta o que observou, diz do que desconfia e nomeia o tipo de gente que resolve aquilo. Largar o problema no colo de alguém e sumir também produz um resultado, só que você não escolhe qual. No vibe coding essa diferença sai cara porque o retorno chega rápido e plausível: um diff grande, bem escrito, que passa pelos seus olhos sem resistência e entra no projeto.

Pedir uma feature e pedir um conserto não são o mesmo pedido

O conselho de prompt claro no vibe coding vale para o outro momento, quando você pede uma coisa que ainda não existe. Lá o que falta no prompt é o gatilho, o lugar onde a coisa aparece, o efeito que ela produz e o motivo de existir. É um pedido de construção, e o agente precisa saber o formato do que vai construir.

Aqui a coisa já existe e está errada. O agente pode ler o código inteiro sozinho e ainda assim errar o alvo, porque o que falta não está no código: está no que você viu acontecer e no tipo de conhecimento que aquilo exige. São 2 pedidos diferentes, com faltas diferentes. Caprichar na descrição de uma feature não ajuda em nada quando o problema é um bug.

Isto ele não disse na live

A hipótese cobra um preço. Se você escreve a causa com certeza, o agente vai atrás dela e pode parar de procurar em qualquer outro lugar, inclusive no lugar certo. Sai um conserto convincente num arquivo inocente, e o bug segue intacto do outro lado.

Escrever como suspeita evita boa parte disso. "Desconfio que seja o cache da sessão, confirme antes de mexer" faz o agente checar primeiro e voltar com o que achou. "O bug está no cache da sessão, arruma" faz ele começar a editar.

Junto da suspeita, mande o que você observou, separado do que você acha. O que você fez, o que esperava e o que apareceu na tela continuam valendo mesmo se a sua suspeita estiver errada, e é com isso que o agente investiga sozinho quando a sua pista não dá em nada.

O que acrescentar no próximo bug

Antes de apertar enter no seu "corrige isso", escreva mais 2 frases. Uma é do que você desconfia, com o pedido de confirmar antes de mexer. A outra é que tipo de profissional resolveria aquilo, escrita como se você estivesse contratando alguém para a tarefa. Vale também conferir o que está protegido na base de dados: rls supabase mostra por que a segurança do banco é a linha de defesa que mal aparece nas conversas sobre pedidos. E quando a auditoria expõe um painel administrativo exposto, verificar o empacotamento do deploy é o que separa código correto de infraestrutura insegura.

Vale assistir à live pelo timing da coisa: o bug aparece sozinho no meio do teste, e a dica sai ali, com o erro na tela, sem preparo nenhum.