Testes A/B com Claude Code: Simule Experimentos Antes de Gastar Tráfego Real
O insight de conversão mais útil da minha carreira veio de um dashboard que ninguém me pediu para abrir. Na Namu, a aquisição funcionava inteiramente em Facebook Ads, e quando comparei segmentos, visitantes orgânicos estavam convertendo notavelmente melhor do que os pagos. Essa única comparação acabou reformulando toda a estratégia de conteúdo, focando em posts de blog com CTAs em vez de landing pages pagas.
Claude Code agora pode executar esse tipo de comparação antes de um único visitante real ver sua página. Você passa o contexto do negócio mais uma hipótese, aprova um plano de teste, e ele simula um teste A/B entre duas variantes e escreve o vencedor projetado. A simulação funciona como uma etapa de triagem, e usuários reais ainda fazem a chamada final.
O que é uma simulação de teste A/B com Claude Code?
Basicamente, é o modelo de linguagem interpretando seu usuário alvo contra duas versões de uma página, depois estimando qual versão vence em uma métrica que você definiu. Claude Code lê ambas as variantes do seu repositório, aplica a persona e contexto do negócio que você forneceu, e produz um relatório com números de conversão projetados.
Esses números são sintéticos. Eles vêm da compreensão do modelo sobre como as pessoas se comportam, que é ampla mas genérica. O que torna o exercício útil mesmo assim é que a maioria das variantes perdedoras perde por razões chatas e previsíveis: proposta de valor pouco clara, um formulário pedindo muito cedo demais, um CTA abaixo da dobra, nenhum sinal de confiança perto do passo de pagamento. Um modelo detecta isso instantaneamente.
A maior diferença é que um painel de usuários reais custa dinheiro e semanas. Uma simulação custa apenas alguns prompts.
Por que se importar, quando testes A/B reais existem?
Porque a maioria dos sites não consegue executar um teste A/B real que signifique algo. Execute os números através de qualquer calculadora de tamanho de amostra: detectar um aumento relativo de 10% em uma linha de base de conversão de 3%, com configurações padrão de significância e poder, precisa de aproximadamente 50.000 sessões por variante. Uma loja cliente fazendo 20.000 sessões por mês precisaria de cinco meses por teste, assumindo que mais nada mude naquela janela.
Então, ou você tem volume, ou qualquer decisão é tendenciosa para suas próprias preferências. Na prática, times ou pulam testes inteiramente ou executam testes sub-potência e enviam a variante que estava à frente quando alguém ficou impaciente. Escrevi antes sobre por que demos de IA falham em produção, e testes A/B sub-potência falham pela mesma causa raiz: a lacuna entre o que foi validado e o que é enviado. Uma simulação pelo menos o impede de desperdiçar seu tráfego real limitado em uma variante que nunca funcionaria mesmo.
Passo 1: construa o contexto antes de pedir qualquer coisa
Claude Code simula usuários apenas tão bem quanto entende quem são esses usuários. Antes de tocar no teste em si, alimente-o com o modelo de negócio, a persona alvo, o objetivo da tela específica, e acesso de leitura à implementação em si.
O padrão que funciona é uma descrição inline curta emparelhada com referências @file a documentos mais profundos:
Este é um WooCommerce armazenando suplementos de bem-estar no Canadá.
Detalhes do modelo de negócio: @docs/business.md
Perfil de cliente alvo: @docs/persona.md
Explore a base de código e analise como o fluxo de checkout é implementado.
Não altere nenhum arquivo.
Quero fazer um teste A/B da etapa "criar conta", então construa uma
compreensão de como funciona atualmente.
Se algo for pouco claro, faça-me perguntas.
As menções @file importam porque Claude Code abre esses arquivos por conta própria quando precisa de profundidade, então você mantém o prompt curto sem privá-lo de contexto. A linha "faça-me perguntas" importa tanto quanto, e é o mesmo princípio por trás do prompting carregado de restrições que cobri em prompts Claude Code PACREF: o modelo funciona melhor quando os limites são explícitos.
Passo 2: hipótese primeiro, plano segundo
Um teste sem uma hipótese escrita produz um relatório no qual você não consegue agir. Mude Claude Code para o Modo Plano (Shift+Tab faz ciclo através dos modos de permissão), que o bloqueia na análise somente leitura, e dê a ele uma hipótese estruturada antes de pedir o plano:
Hipótese:
Se a etapa de conta explicar para o que os dados de endereço são usados,
mais usuários a completarão, porque o valor fica claro
antes do comprometimento.
Fluxo atual:
O usuário é solicitado a criar uma conta com endereço completo na etapa de checkout 2.
Objetivo do negócio: conversão
Métrica primária: taxa de conclusão da etapa
Métricas de proteção: tempo de carregamento de página, latência de clique do CTA
Duas regras mantêm isso honesto. Use exatamente uma métrica primária, porque uma simulação solicitada a otimizar quatro números ao mesmo tempo começa a alucinar trade-offs entre eles. E defina métricas de proteção, os números operacionais que expõem vitórias falsas. Uma variante que eleva a conclusão carregando um script mais pesado falhou, e sem uma proteção no plano, o relatório a chamará de vencedora.
Com a hipótese aprovada, peça o plano real: faça referência a ambos os arquivos de variante, declare suas diferenças em uma linha, e solicite a lógica de atribuição, o próprio plano de teste, os eventos de análise, e as condições para reversão. Revise-o como reveria um plano de migração de um dev junior, porque é funcionalmente isso que é.
Passo 3: execute a simulação e a proteja
O prompt de execução tem um trabalho além de executar o teste: forçar o relatório a separar fato de ficção. Este é o formato de prompt que uso, adaptado do original de Babich:
Use o plano aprovado de testes A/B como fonte de verdade.
Simule o teste descrito nesse plano.
Não modifique código do produto. Não altere o plano.
O relatório deve claramente separar:
- o que veio do plano original
- o que foi assumido para a simulação
- o que os resultados simulados sugerem
- o que ainda precisa ser validado em um experimento real
Confirme que nenhum código do produto foi modificado.
Quando o relatório diz que a variante B vence por 4 pontos, você precisa ver, por escrito, que os números de tráfego foram assumidos e o cálculo de significância rodou em dados sintéticos. Observei output de IA suficiente ser colado em decks de clientes como fato para insistir nisso. Repita a instrução "não modifique código" mesmo que o Modo Plano já tivesse restringido a fase de planejamento, porque a execução do teste acontece fora dele.
Se o vencedor simulado sobrevive ao seu ceticismo, o follow-up é mecânico: promova a variante vencedora para padrão, remova a lógica de branching e configuração de experimento, atualize os testes, execute lint e typecheck. Claude Code lida bem com essa limpeza, da mesma forma que lida com o trabalho de migração e refatoração em meus fluxos de trabalho Claude Code WordPress.
O que fazer com um resultado simulado
Trate a simulação como um filtro, e a árvore de decisão fica simples. Se a simulação mostrar uma variante claramente perdendo por uma razão concreta e explicável, mate-a e não gaste tráfego nela. Se ambas as variantes parecerem próximas, envie a mais simples e siga em frente. Se a simulação mostrar um vencedor forte e a página importa comercialmente, essa é a variante que ganha seu um teste real, com eventos de análise reais, em usuários reais.
Se sua loja está fazendo decisões de conversão por instinto porque testes A/B reais nunca foram viáveis em seu nível de tráfego, configurar esse tipo de loop de validação assistido por IA é exatamente o trabalho de consultoria que faço. Entre em contato.