LLM como controle de qualidade no vibe coding, sem humano no meio

Se a sua esteira de vibe coding entrega mais itens do que você consegue olhar um a um, o passo que falta é um segundo modelo conferindo a saída depois de pronta. Thiago já tem esse passo rodando na plataforma que ele constrói em público, feita para fazer sozinha o trabalho de uma agência de marketing para quem quer vender esse serviço. Quando a plataforma monta um carrossel e gera a imagem da capa, ela aciona uma segunda LLM só para fazer a curadoria daquela imagem.

Essa segunda LLM não recebe o prompt nem o código que geraram a peça. Ela tira um print da imagem recém-criada e analisa esse print:

então ele bate um print ali da imagem, analisa e vê se tá dentro dos critérios que a gente queria

Roda sozinho, sem ninguém no meio, antes de o item seguir. E Thiago separa bem o que já está de pé do que ainda é promessa: pouco antes, falando de outra ideia, ele diz que "tá no plano, mas não funciona ainda", e então pergunta "Que acontece hoje?" para descrever a curadoria. A curadoria é a parte que já existe.

O curador olha o que o cliente vai ver

Quando uma saída de IA sai errada, o reflexo é voltar uma casa: reescrever o prompt ou mexer na função que monta o arquivo. Isso conserta a instrução, e a instrução pode estar correta enquanto o resultado sai torto.

Uma imagem de capa pode ter sido gerada com o prompt certíssimo e ainda chegar com o texto cortado ou com a composição fora do que a peça pedia. Nada disso aparece no prompt que pediu a imagem, só na imagem pronta. Olhar o print é o que aproxima a checagem daquilo que o cliente vai receber. E é barato: uma chamada a mais por item, dentro de um fluxo que já existia. Vale ver como isso terminou em vibe coding para checar cobranca real antes de instrumentar telemetria.

O objetivo declarado dele para esse automatismo é que nada saia fora do critério no final. É o alvo do mecanismo, não um número apurado, e a live não conta quantas imagens passam ou reprovam.

O critério precisa existir antes da imagem

O segundo modelo não é chamado para opinar sobre a imagem. Ele confere se ela está dentro dos critérios que o plano de conteúdo pedia. Esse critério já estava escrito antes de a imagem existir, porque é o plano que manda montar o carrossel.

Essa é a parte que costuma faltar quando alguém tenta plugar um revisor automático numa esteira. Perguntar a um modelo se a imagem ficou boa devolve uma resposta plausível e inútil, porque não existe nada contra o que comparar. Perguntar se a peça cumpre o que o plano pediu é uma conferência, e conferência tem resposta. É isso que a evidência real do sistema faz, checando o banco em vez de acreditar na intenção do código. E é também o que validar consentimento antes de publicar faz: confere o carimbo na mídia em vez de confiar que está tudo bem. Vale ver como isso terminou em vibe coding para nao esconder o controle na pagina que o menu nao abre.

Na prática, isso muda a ordem do trabalho. Antes de automatizar a revisão, você escreve o que a peça precisa ter. Se você não consegue escrever o critério, a etapa que falta é o plano.

Sem esse passo, o vibe coding não fecha a conta da escala

O produto do Thiago é um mecanismo de distribuição em escala, e é aí que o curador automático deixa de ser luxo. Ele dá o exemplo do pacote em que o cliente solta 3 carrosséis por dia, um de manhã, um de tarde e um de noite. São 90 carrosséis por mês. Ninguém revisa 90 imagens uma a uma, e quem contratou não quer isso, "ele quer distribuir conteúdo".

Para quem faz vibe coding, a conta é essa: volume só é sustentável se a checagem escalar junto com a geração. Enquanto a revisão for humana e item a item, o teto da operação é o tempo de uma pessoa, e velocidade na geração não compra nada. Ele já tinha atacado um pedaço parecido do problema ao montar um squad de agentes com papéis, mas o passo descrito aqui é outra coisa, um QA dentro da linha de produção, rodando antes da entrega.

Onde o humano ainda revisa virou decisão de produto

Thiago vai oferecer dois modos, automático e manual, e deixar o cliente escolher se quer aprovar os carrosséis antes de irem ao ar. Quando ele conta o que o cliente-piloto pediu, a escolha cai fora da imagem:

ele quer só aprovar o texto para ver se tá de acordo com o que ele falaria

O design e a imagem ele não quer nem ver, confia na ferramenta. O que ele faz questão de olhar é se o texto usa as palavras que ele usaria.

O pedido do cliente-piloto reposiciona o curador automático. Ele assume a parte que a máquina confere melhor, o critério objetivo da imagem, e com isso a atenção da pessoa sobra no único ponto que ela não delega, que nesse caso é a voz do cliente dentro do texto. E é isso que aparece também em vibe coding para validar mvp com primeiro cliente pagante, onde o cliente paga e fornece o feedback que decide o backlog. E em como usar vibe coding para travar publicação de imagem com rosto sem autorização, onde a revisão humana aprova o que ficou bloqueado.

Decidir onde o humano ainda revisa deixa de ser detalhe técnico e vira desenho de produto. Você escolhe o lugar em que a revisão humana rende mais por minuto gasto e automatiza o resto contra critério escrito. Errar essa escolha custa dos dois lados: ou você prende o cliente aprovando o que ele nem quer ver, ou entrega no automático justamente o pedaço que só ele sabe julgar.

O passo que dá para copiar amanhã

Pegue a etapa da sua esteira que produz algo que um cliente vai ver. Escreva, antes, os critérios que aquela peça precisa cumprir. Faça uma segunda passada olhar a saída renderizada, o print da tela ou o arquivo final, e comparar com esses critérios. Depois pergunte a quem recebe o resultado qual pedaço ele quer aprovar de verdade, porque a resposta costuma ser diferente da que você imaginou.

É assim que o vibe coding vira operação: com um passo de conferência que ninguém precisa lembrar de executar. Dá para assistir à live e ver ele descrever o mecanismo no meio da construção.