A descoberta de conversão mais útil da minha carreira veio de um painel que ninguém me pediu pra abrir. Na Namu, a aquisição dependia inteira de anúncio no Facebook, e quando comparei os segmentos, os visitantes orgânicos convertiam bem melhor que os pagos. Essa comparação sozinha acabou mudando toda a estratégia de conteúdo, que passou a apostar em posts de blog com CTA em vez de landing pages pagas.
Agora o Claude Code consegue rodar esse tipo de comparação antes de um único visitante real ver a sua página. Você passa o contexto do negócio e uma hipótese, aprova um plano de teste, e ele simula um teste A/B entre duas variantes e aponta a vencedora projetada. A simulação serve de triagem, e quem dá a palavra final continuam sendo os usuários reais.
O que é uma simulação de teste A/B com o Claude Code?
No fundo, é o modelo de linguagem fazendo o papel do seu usuário diante de duas versões de uma página e estimando qual versão ganha numa métrica que você definiu. O Claude Code lê as duas variantes no seu repositório, aplica a persona e o contexto de negócio que você passou e gera um relatório com números de conversão projetados.
Esses números são sintéticos. Eles vêm do que o modelo entende sobre como as pessoas se comportam, que é amplo, mas genérico. O que faz o exercício valer mesmo assim é que quase toda variante perdedora perde por motivos chatos e previsíveis: proposta de valor confusa, formulário pedindo demais cedo demais, CTA abaixo da dobra, nenhum sinal de confiança perto da etapa de pagamento. Um modelo enxerga isso na hora.
A grande diferença: um painel de usuários reais custa dinheiro e semanas. Uma simulação custa alguns prompts.
Por que se dar ao trabalho, se existe teste A/B de verdade?
Porque a maioria dos sites não consegue rodar um teste A/B de verdade que signifique alguma coisa. Jogue os números em qualquer calculadora de tamanho de amostra: detectar um aumento relativo de 10% sobre uma taxa de conversão de 3%, com as configurações padrão de significância e poder, exige umas 50.000 sessões por variante. Uma loja cliente com 20.000 sessões por mês precisaria de cinco meses por teste, supondo que nada mais mudasse nesse período.
Ou seja: ou você tem volume, ou qualquer decisão pende pro seu gosto pessoal. Na prática, os times pulam o teste de vez ou rodam testes sem amostra suficiente e publicam a variante que estava na frente quando alguém perdeu a paciência. Já escrevi sobre por que demos de IA falham em produção, e teste A/B sem amostra falha pela mesma raiz: a distância entre o que foi validado e o que foi publicado. A simulação pelo menos impede você de gastar o seu pouco tráfego real numa variante que nunca ia funcionar.
Passo 1: monte o contexto antes de pedir qualquer coisa
O Claude Code só simula usuários tão bem quanto entende quem eles são. Antes de mexer no teste em si, passe pra ele o modelo de negócio, a persona, o objetivo daquela tela específica e acesso de leitura à implementação.
O padrão que funciona é uma descrição curta no próprio prompt junto com referências @file pros documentos mais detalhados:
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 o Claude Code abre esses arquivos sozinho quando precisa de detalhe, então o prompt fica curto sem deixar ele sem contexto. A linha "faça-me perguntas" importa na mesma medida, e segue o mesmo princípio dos prompts cheios de restrições que eu mostrei no PACREF para prompts no Claude Code: o modelo trabalha melhor quando os limites estão explícitos.
Passo 2: primeiro a hipótese, depois o plano
Teste sem hipótese escrita gera um relatório com o qual você não consegue fazer nada. Passe o Claude Code pro Modo Plano (o Shift+Tab alterna entre os modos de permissão), que prende ele numa análise só de leitura, e entregue 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 principal, porque uma simulação que precisa otimizar quatro números ao mesmo tempo começa a inventar compensações entre eles. E defina métricas de proteção, os números operacionais que desmascaram vitória falsa. É a mesma disciplina de avaliação que a arquitetura de sistemas de IA coloca em volta de qualquer sistema em produção. Uma variante que aumenta a conclusão carregando um script mais pesado falhou, e sem uma métrica de proteção no plano, o relatório vai chamar ela de vencedora.
Com a hipótese aprovada, peça o plano de verdade: aponte os dois arquivos de variante, descreva a diferença entre eles numa linha e peça a lógica de distribuição, o plano de teste, os eventos de analytics e as condições pra reverter. Revise como você revisaria um plano de migração escrito por um dev júnior, porque na prática é isso que ele é.
Passo 3: rode a simulação e proteja o resultado
O prompt de execução tem uma função além de rodar o teste: obrigar o relatório a separar fato de ficção. Este é o formato de prompt que eu 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 ganha por 4 pontos, você precisa ver, por escrito, que os números de tráfego foram supostos e que o cálculo de significância rodou em cima de dados sintéticos. Já vi resultado de IA suficiente ser colado em apresentação de cliente como se fosse fato pra fazer questão disso. Repita o "não modifique código" mesmo com o Modo Plano tendo restringido a fase de planejamento, porque a execução do teste acontece fora dele.
Se a vencedora simulada sobreviver ao seu ceticismo, o resto é mecânico: transforme a variante vencedora em padrão, tire a lógica de ramificação e a configuração do experimento, atualize os testes, rode lint e typecheck. O Claude Code faz essa limpeza bem, do mesmo jeito que faz o trabalho de migração e refatoração nos meus fluxos de WordPress com Claude Code.
O que fazer com um resultado simulado
Trate a simulação como filtro, e a árvore de decisão fica simples. Se a simulação mostrar uma variante perdendo claramente por um motivo concreto e explicável, mate essa variante e não gaste tráfego com ela. Se as duas parecerem empatadas, publique a mais simples e siga em frente. Se a simulação mostrar uma vencedora forte e a página importar comercialmente, essa é a variante que merece o seu único teste de verdade, com eventos de analytics reais, com usuários reais.
Se a sua loja decide conversão no feeling porque teste A/B de verdade nunca coube no seu volume de tráfego, montar esse ciclo de validação é trabalho de arquitetura de IA. Me conta o que você está tentando decidir.