Vibe coding para IA aprender com o motivo da rejeição: o desenho que ainda não roda

Uma pessoa perguntou no chat como o produto dele funciona, e a resposta que Thiago deu ao vivo carrega uma decisão de produto que vale mais que a explicação inteira: no modo em que o cliente aprova cada peça antes de publicar, reprovar não termina em "gera outro". O cliente escreve por que reprovou, e o sistema guarda isso para a próxima rodada.

Nada disso está rodando. Ele descreve o fluxo inteiro no condicional, "imagina que tudo seria feito de forma automática", "você decidiria", e diz com todas as letras em que ponto o produto está:

"depois que esse SAS tiver pronto, eu vou oferecer para outras pessoas"

O que ele mostrou foi desenho de produto, explicado de improviso. E o desenho é bom o bastante para ser copiado por quem monta fluxo de conteúdo com agente hoje.

O fluxo que ele descreveu

O cliente começa ensinando a própria marca ao sistema, quem ele é e o que a marca resolve para quem compra. Depois escolhe o regime de operação: deixar a IA gerar e publicar sozinha, ou aprovar peça por peça antes de qualquer coisa ir ao ar. O exemplo de volume que ele deu foi de roteiro: os roteiros de vídeo do mês ficam prontos, 1 por dia, 30 roteiros esperando o olho do dono.

No modo de aprovação aparece a ideia que interessa:

"você aprova ou não? Quero que gera outro. E aí você coloca, por que que você não aprova? Ah, eu não gostei disso, não gostei daquilo. E ela vai aprendendo [...] com o que você não gosta"

O destino desse aprendizado, ainda na descrição dele, é o dono chegar ao ponto de confiar e deixar no automático.

Rejeição sem motivo devolve o sistema ao mesmo lugar

"Gera outro" descarta a peça e não move nada. O modelo continua com a mesma instrução que produziu a peça reprovada, então na rodada seguinte ele erra pelo mesmo motivo, o dono reprova de novo, e o tempo do humano vai embora enquanto a qualidade fica parada. Com 30 roteiros na fila, isso deixa de ser irritação e vira trabalho.

O motivo transforma o clique de reprovar, que é informação binária e quase sem conteúdo, em uma frase sobre gosto que pode virar instrução.

O momento em que o gosto sai barato

A recomendação padrão é escrever um documento de tom de voz antes de soltar o agente. Ele quase nunca sai do papel, porque descrever o próprio gosto no vazio é difícil e o que sai serviria para qualquer marca.

O motivo da rejeição resolve isso pela lateral. A pessoa já está ali, com a peça na frente e a reação fresca. Dizer "não gostei disso" olhando para a coisa específica custa poucos segundos, e cada frase dessas é mais concreta que um parágrafo escrito de memória. O documento de gosto vai se formando de peça em peça, sem ninguém sentar para escrevê-lo.

Por que a escada de confiança faz sentido no vibe coding

O desenho tem 2 degraus, aprovação e automático, e a ordem importa. Confiança em automação se acumula, e o que a produz é acerto repetido que a pessoa viu com os próprios olhos. Quem começa no automático está apostando, não confiando por evidência. Depois de ver o sistema acertar rodada após rodada, você sabe o que está delegando.

Esse padrão aparece toda hora no vibe coding: você aprova cada diff do agente até parar de encontrar erro, e aí passa a rodar em lote. O desenho dele aplica a mesma escada a conteúdo, alimentando a subida com o que você reprovou no caminho. Vale ver como isso terminou em handoff ia. Foi o mesmo caminho de vibe coding para usar ia como rascunho de contador e advogado.

O contraste útil está numa coisa do mesmo builder que já roda. Em LLM como controle de qualidade no vibe coding, uma segunda LLM confere a peça criada contra o que o plano de conteúdo pedia, antes de ir ao ar. Lá é automação de julgamento funcionando hoje; aqui é o passo seguinte, ainda no papel, o sistema aprender com o motivo de uma reprovação humana. A explicação completa, com a pergunta do chat que a puxou, está na live desse dia.

Daqui para baixo é análise e recomendação minha

O que vem agora ele não tratou na live. São os pontos em que quem for construir esse fluxo vai esbarrar.

"Não gostei disso" sozinho não é sinal de treino. Para virar sinal, o motivo precisa estar amarrado à peça que foi rejeitada e ser específico o bastante para valer nas peças seguintes. Motivo vago erra para os 2 lados: o sistema aprende a evitar coisa demais e a saída encolhe, ou não aprende nada e a rejeição vira registro morto. Um campo de texto livre no botão de reprovar não resolve sozinho, precisa de âncora no trecho que incomodou.

Preferência aprendida também tende a estreitar a saída. Se o sistema só evita o que foi reprovado, ele converge para o que já foi aprovado antes, e o conteúdo fica cada vez mais parecido consigo mesmo. Vale reservar espaço para a peça que ninguém pediu, senão o aprendizado vira funil.

E o modo automático precisa de caminho de volta. O dono que parou de olhar não percebe quando a qualidade cai, e é justamente ele que não vai reprovar nada. A escada de confiança precisa de um degrau de descida, algum sinal que o traga de volta para o modo de aprovação antes de a queda aparecer para o público.

O que dá para fazer amanhã sem esse produto existir

Colher motivo de rejeição não depende de SaaS nenhum. Da próxima vez que pedir outra versão ao seu agente, escreva por que a anterior não serve e guarde essa frase em um arquivo que ele leia no começo da próxima rodada. Um arquivo de preferências no repositório dá conta. Em uma semana esse arquivo vira a descrição do seu gosto, escrita sem você ter sentado para escrevê-la.