A precisão do vibe coding é uma medição, não uma propriedade do modelo
Dois times usando o mesmo modelo chegam a resultados muito diferentes, porque a precisão no nível que importa para você é determinada pelo que acontece depois da geração. Alguém conferiu? Conferiu contra o quê? Em quanto tempo um resultado errado voltou para ser corrigido?
Colocada assim, a pergunta deixa de ser "qual modelo é mais preciso" e passa a ser "qual é o meu ciclo de feedback", que é algo sob o seu controle.
O que vale a pena medir
O comportamento descrito acontece
A única definição de correto que sobrevive ao contato com um usuário.
Medida ao executar o fluxo, não ao ler o código.
O que funcionava ontem ainda funciona
A taxa de regressão importa mais do que a precisão na primeira tentativa depois que você passa da primeira semana.
Cerca de uma em cada cinco mudanças de funcionalidade quebra algo que antes funcionava.
Quanto tempo até um resultado correto
Tentativas até o verde é mais útil do que passou ou não passou na primeira tentativa.
Isso captura aquilo que você de fato sente, que é quanto tempo o ciclo leva.
A armadilha: testes escritos pelo mesmo autor
A forma óbvia de medir precisão é pedir que o agente escreva testes e ver se eles passam. Isso produz um número quase sempre alto e que significa muito pouco. Um teste gerado a partir das mesmas premissas da implementação concorda com ela por construção, inclusive onde as duas estão erradas.
Uma medição de precisão precisa de uma verificação independente. Algo que exercite o produto contra o comportamento pretendido, e não contra a ideia que o próprio código faz de si mesmo.
Como montar a medição
Descreva, em linguagem simples, os fluxos que definem o que é correto para o seu produto, antes da próxima rodada de mudanças. Execute-os contra o app publicado. A primeira execução te dá uma linha de base, e cada execução depois dela te dá um sinal de regressão.
Nada disso exige um terminal. Crie um projeto no painel do TestSprite, descreva a verificação em linguagem simples e aponte para o seu app. As pessoas desenvolvedoras do seu time podem fazer a mesma coisa pela linha de comando, se preferirem, o que está no repositório do CLI.
Um dado que vale conhecer
Em um ranking público em que agentes de código construíram a mesma aplicação, o modelo mais barato da disputa produziu o app mais correto quando havia um ciclo de verificação no lugar, pela metade do custo da inscrição mais cara. A parte interessante não é a colocação. É que o ciclo pesou mais do que o modelo, o oposto do rumo que a conversa sobre precisão costuma tomar.
Para que o número serve de verdade
Números de precisão costumam ser coletados para responder a uma pergunta que ninguém fez, do tipo se o modelo é bom. A pergunta útil é mais estreita: dá para fazer merge disto.
Isso reformula a medição. Você não precisa de uma nota para o produto inteiro, precisa saber se esta mudança quebrou algo que funcionava antes dela. Um punhado de verificações cobrindo os fluxos que importam, executadas contra o build publicado, responde a isso em minutos. Um benchmark abrangente responde a outra pergunta ao longo de uma semana.
Isso também muda o que um número ruim significa. Uma precisão em queda em um benchmark é interessante. Um fluxo específico que funcionava ontem e hoje não funciona é acionável, e é o segundo caso que impede que as coisas cheguem aos usuários.
Torne a medição contínua
Uma medição isolada fala sobre um único momento. Precisão é uma propriedade de um processo contínuo, então as verificações pertencem a cada mudança.
São dois caminhos, e a escolha é, na verdade, sobre quem é dono do pipeline. Conectar o GitHub App pelo painel não exige nenhuma mudança no seu repositório, porque ele reage ao deploy que o seu build já emite. Adicionar um passo do GitHub Actions coloca a verificação no repositório, onde ela passa por revisão como o resto do build.
Transformando precisão em algo que você mede
O TestSprite é a verificação independente de que a medição precisa. Ele exercita o seu produto publicado contra o comportamento que você descreveu, não contra a ideia que o próprio código faz de si mesmo, e é isso que faz o número significar algo quando a implementação e os testes vieram do mesmo agente.
Na prática, você descreve uma única vez os fluxos que definem o que é correto para o seu produto, e eles rodam a cada mudança. A primeira execução é a sua linha de base. Cada execução depois dela responde à pergunta que você de fato tem, que é se esta mudança quebrou algo que funcionava ontem.
Isso te dá os dois números que valem acompanhamento: a taxa de regressão por mudança e quantas tentativas são necessárias para voltar ao verde. Os dois se movem quando o ciclo aperta, e nenhum deles pode ser inflado escrevendo mais testes.
Qual modelo é mais preciso para vibe coding?
É a pergunta errada para a maioria dos times. A variação introduzida por você verificar ou não é maior do que a variação entre os modelos de fronteira atuais.
Dá para medir precisão sem escrever testes?
Dá. Descreva os fluxos em linguagem simples e faça com que rodem contra o app. Você está medindo comportamento, e comportamento não exige código de teste para ser observado.
O que é um bom número de precisão?
Não existe um parâmetro útil que sirva para produtos diferentes. Acompanhe a sua própria tendência: taxa de regressão por mudança e tentativas até um resultado correto. As duas devem cair conforme o ciclo aperta.
Mais cobertura significa mais precisão?
Não de forma confiável. Cobertura conta o que foi exercitado, não se as expectativas estavam certas. Uma suíte grande de testes gerados pode reportar cobertura alta sobre as premissas erradas.
Com que frequência devo medir de novo?
A cada mudança, automaticamente. Precisão medida por agendamento fala sobre o agendamento, não sobre a mudança que quebrou alguma coisa.
Precisão é o seu ciclo, não o seu modelo.
A precisão do vibe coding é algo que você mede no seu próprio produto: o comportamento descrito acontece, o que funcionava ontem ainda funciona, quanto tempo até um resultado correto. Use uma verificação independente em vez de testes escritos pelo mesmo autor, e meça a cada mudança.