Vibe coding para exigir evidência antes de confiar na IA que diz sim

Perguntar a um assistente de código se está tudo certo é a pior pergunta que existe, porque ela aceita resposta sem verificação, e a resposta vem. Thiago perguntou isso sobre a telemetria da plataforma de carrosséis que ele constrói em público, ouviu que estava tudo certo, e descobriu o contrário mais tarde na mesma sessão: com um trabalho já pronto, abriu o painel de telemetria e não apareceu nada.

O que veio depois vale mais que o bug. O assistente investigou, achou a causa e, quando foi cobrado, explicou por que tinha errado antes. Ele havia respondido a partir do que o código deveria fazer, sem olhar o que o código tinha feito.

A intenção do código quase sempre parece certa

A causa era pequena e específica. Ao gravar o evento, o código colocava o identificador do cliente num campo que esperava o da organização. A chave estrangeira rejeitava a inserção, o erro ia só para o log, o evento era descartado, e "por isso a tabela estava com zero linhas".

Repare no desenho: ele estava correto. A tabela existia, a inserção existia. Quem lê esse caminho e responde de cabeça responde certo sobre o plano, e é por isso que a resposta soou segura. Um assistente que lê código tem acesso à intenção, e a intenção quase sempre parece boa, porque foi escrita por alguém que queria que funcionasse. O estado real não está no arquivo. Está no banco e nos logs.

Perguntar se algo está funcionando para quem só leu o código é perguntar se o plano faz sentido. As duas perguntas soam iguais e recebem o mesmo tom de resposta, mesmo quando a distância entre elas é uma tabela vazia.

Falha silenciosa é a que mais sobrevive

O erro tinha ido só para o log. Nenhuma tela quebrou, nenhuma geração falhou, o produto continuou entregando o carrossel. A única evidência ficou num arquivo que ninguém abre enquanto as coisas parecem bem, e um painel vazio ainda passava por falta de uso. Aviso que aparece e é desligado termina no mesmo lugar: vibe coding para nunca silenciar aviso do lint mostra o sinal sendo conferido em vez de calado.

Bug que grita morre no mesmo dia. O que só escreve uma linha de log fica, e fica justamente onde vai doer depois: no registro de custo e na métrica de uso, cuja saída ninguém confere todo dia. Essas partes do sistema dependem de alguém perguntar, e a pergunta volta a ser o problema quando é respondida sem checagem. O mesmo problema apareceu em vibe coding para checar cobrança real antes de instrumentar telemetria, onde o custo já estava sendo pago sem nenhum registro do lado de cá. Isso aparece também em llm como controle de qualidade no vibe coding, onde um modelo faz a conferência automaticamente antes de o resultado ir embora. E também em como usar vibe coding para travar publicação de imagem com rosto sem autorização, onde a trava valida consentimento antes de publicar. Foi o mesmo caminho de vibe coding para nao esconder o controle na pagina que o menu nao abre. O mesmo problema apareceu em handoff ia. Isso aparece também em benchmark de ia.

No vibe coding, cobrar depois é o que traz o mecanismo

Thiago não deixou passar. Lembrou que já tinha perguntado antes:

Eu te perguntei se tava tudo certo e você falou que tava tudo certo.

Junto veio uma reprimenda curta, do tipo que se usa entre pessoas que trabalham lado a lado. A resposta é o que dá valor à cena. O assistente admitiu:

No segundo ponto eu errei.

Depois contou como errou: respondeu pelo caminho do código, não conferiu nem o banco nem os logs, e disse que, se tivesse olhado, teria visto que não estava gravando. E resumiu o próprio modo de falha:

Foi confiança demais no desenho.

Essa frase é útil porque nomeia o mecanismo, e é do mecanismo que sai regra nova. Ficou combinado ali que pergunta sobre telemetria ou custo passaria a ser respondida só depois de confirmar no banco e nos logs. A regra saiu da admissão, e a admissão só apareceu porque alguém cobrou.

Existe o caminho oposto, de prevenção: o critério de aceite que exige a prova antes evita que a afirmação falsa chegue a existir, enquanto esta cena mostra como flagrar a que já foi dita. A mesma lógica vale um passo antes do código, na hora de decidir o que entra: vibe coding para travar decisão de escopo antes de fechar o plano mostra a decisão sendo conferida antes de virar plano, em vez de aceita porque soou razoável. Vale ver como isso terminou em property based testing.

O que se perdeu não volta

Enquanto a falha existiu, os eventos não entraram na tabela, e eles não entram depois. O trabalho que já tinha sido gerado não recupera o registro de custo, porque aquelas inserções foram descartadas na hora em que o banco recusou.

Isso muda a conta do prejuízo: a resposta falsa custou o tempo até alguém desconfiar e também o dado que teria existido naquele intervalo. Telemetria e registro de custo não são reconstituíveis, já que ou o evento foi gravado na hora, ou ele nunca existiu. Por isso a checagem precisa vir antes da afirmação, enquanto ainda dá para gravar.

Troque a pergunta que você faz

O ajuste é barato e cabe em qualquer rotina de vibe coding:

- em vez de perguntar se está tudo certo, peça me mostre o que tem na tabela agora - em vez de perguntar se a telemetria funciona, peça a consulta feita e a saída dela, colada

Vale também calibrar a desconfiança pelo relógio. Conferir banco e log leva tempo; opinar sobre o código sai na hora. Quando a resposta sobre estado chega instantânea, ela quase certamente veio de leitura. Não precisa acusar ninguém, basta pedir o que sustentaria a afirmação. Esse jeito de validar é o que aparece também em validar consentimento antes de publicar, onde o silêncio vira bloqueio.

Nada disso depende de ferramenta. É a diferença entre aceitar a intenção do código e exigir o estado do sistema, e é o hábito que separa quem faz vibe coding com controle de quem entrega a decisão e espera dar certo. A sequência inteira, do painel vazio até a admissão, está em assistir à live.