Vibe coding para testar modelo novo em A/B sem mexer na produção

Modelo novo não se troca no feeling. Você replica a mesma chamada para A e para B, guarda o resultado sem publicar, e só depois decide se a API mais barata segura a operação. Thiago chegou nessa regra no meio de uma live de 216 min do Taurus Hub, o produto que ele constrói para fazer o trabalho de uma agência de marketing, quando a pergunta deixou de ser qual modelo está na moda e virou se o DeepSeek V4 Flash segura o carrossel no lugar do Haiku e do Sonnet 5.

A telemetria real ainda era pouco. 3 eventos no módulo: 1 roteiro, 1 lote, 5 temas no carrossel. Mesmo assim a missão já estava clara: descobrir se o DeepSeek V4 Flash entrega o mesmo resultado, mais barato, sem ir à produção e sem reconstruir o contexto à mão.

A certeza pedia as mesmas chamadas

Ele falou a missão com o STT ainda sujo, e a fala ficou gravada:

descobrir se trocarmos tanto haiko como stone 5 por pela API do stick P4 flash. teríamos o mesmo resultado, porque ficaria incrivelmente mais barato. Como poderíamos ter a certeza? testando tudo, tipo fazendo prova a Deste entre as duas ABS, apenas com com as chamadas sem ter de ir ao sem ter de ir em produção.

Certeza, no vocabulário dele, é prova A/B entre as 2 APIs com as mesmas chamadas. O teste corre em cima do que já foi pedido, guarda o texto que volta e deixa o registro intacto. O criativo que já saiu fica de fora da rodada, e o prompt permanece o que já foi pedido.

A troca era por operação. Haiku e Sonnet 5 entram em frentes diferentes, roteiro, lote, corte. 1 modelo só para o produto inteiro misturaria essas contas. Com A/B por operação, você vê qual frente melhorou e qual piorou.

Replay benchmark é o vibe coding que não publica

O caminho que ele descreveu:

O caminho ideal é fazer um replay benchmark offline sem alterar a produção.

Replay, no caso dele, é pegar a tarefa que já existiu, os 5 temas daquele carrossel ou o lote ou o roteiro, mandar o mesmo prompt para A e para B e guardar o resultado. Offline, o banco de prova fica fora do fluxo que publica, e o carrossel que já saiu continua o que é.

Quando o modelo novo chega, a tentação do vibe coding é ligar a chave e seguir. Tem live irmã em que ele liga o modelo novo via OpenRouter, e o modelo entra no roteador; o teste desta live fica dentro do produto, offline. Foi o mesmo caminho de vibe coding para migrar dados sem perder historico. O mesmo problema apareceu em vibe coding para recusar rotulo sem citacao na peca. Vale ver como isso terminou em o que é white label. Vale ver como isso terminou em vibe coding para nao mexer nas faixas depois do pedido de producao. Isso aparece também em ambiente de producao. Isso aparece também em vibe coding para testar login pay e restore na versao atual.

Outro builder mediu teste de custo de modelo no vibe coding a 10 centavos por candidato. No recorte do Thiago a comparação é a operação inteira, o que voltou e o tempo gasto, antes de o Flash ir para o carrossel.

O banco de prova mora no módulo de telemetria

O caminho primeiro era o replay fora da produção. Depois ele viu que o contexto da chamada já deveria estar no produto:

Certo, tive uma ideia melhor. Que tal criarmos no módulo de telemetria? uma opção de teste de API.

Se cada API nova entra como teste A/B no mesmo módulo que já registra evento, o histórico de qualidade, latência e custo fica ao lado dos 3 eventos que hoje existem. O módulo ainda tem só isso: 1 roteiro, 1 lote, 5 temas. O pedido é a API nova entrar ali como candidato, com histórico, sem remontar o contexto.

Ele foi explícito sobre o que some se esse rastro continuar solto:

Nunca vamos saber o que pode estar a melhorar, mas a ideia é que nós sempre vamos estar a melhorar o Taurus Hub e será sempre a partir de um novo modelo que está a ser lançado

Quando o próximo modelo sair, rode o A/B no módulo

Amanhã, quando outro modelo chegar com a promessa de ficar mais barato no carrossel, isole 1 operação e rode as 2 APIs em cima da mesma chamada. Guarde o resultado sem publicar e compare o que voltou com o tempo e o custo, e a troca, se vier, fica só naquela operação.

Se o produto ainda não tem telemetria, um log da chamada faz o mesmo papel: prompt, modelo, tempo e texto que voltou. Sem esse rastro, cada teste começa de novo, e volta à frase que ele deixou no ar: nunca vamos saber o que pode estar a melhorar.

Dá para assistir à live e ouvir a troca entre feeling e replay. O resto de como esse jeito de construir funciona está no vibe coding.