Pesquisa Automática Com Claude Code: O Loop de Karpathy Que Roda Enquanto Você Dorme

Andrej Karpathy fez push de um script Python de 630 linhas no GitHub em 7 de março de 2026. Ele foi dormir. Quando acordou, seu agente de IA tinha executado mais de 100 experimentos de machine learning, descoberto 20 otimizações que realmente funcionaram e compilado os resultados em um log limpo — tudo sem uma única tecla pressionada por um humano durante a noite. O repositório atingiu 25.000 estrelas em cinco dias. O CEO da Shopify, Tobi Lutke, apontou-o para o motor de templates deles e obteve renderização 53% mais rápida a partir de 93 commits automatizados. E de repente, um conceito que vinha circulando nos círculos de pesquisa em IA — o loop de melhoria autônomo — tinha um nome que todos conseguiam lembrar: auto research. Eu venho acompanhando isso do meu terminal Claude Code. E o que me empolga não são os experimentos de ML. É o que acontece quando você pega o mesmo padrão — muda uma coisa, mede o resultado, mantém ou descarta, repete — e aponta para problemas de negócio. Conversões de landing pages. Linhas de assunto de e-mail. Textos de anúncios. Layouts de páginas de preço. Qualquer coisa com um número atrelado. Essa é a versão que Jack Roberts recentemente detalhou em um walkthrough completo, e é a versão que venho testando nas últimas duas semanas. Os resultados não são tão dramáticos quanto os do Karpathy — não estou treinando modelos de linguagem durante a noite. Mas eu estou assistindo o Claude melhorar autonomamente meus textos de conversão através de um loop estruturado que roda semanalmente sem eu tocar nele. E a matemática composta disso é genuinamente impressionante. Aqui está como todo o sistema funciona, como eu configurei o meu, e os erros específicos que cometi para que você não os repita.

O Modelo Mental: Por Que 1% Composto Vira 37x

Antes de tocar em qualquer código, você precisa internalizar por que essa abordagem funciona — porque o instinto que a maioria das pessoas tem está errado. A maior parte da otimização acontece em surtos. Você redesenha uma landing page a cada seis meses. Reescreve sequências de e-mail uma vez por trimestre. Atualiza textos de anúncios quando o desempenho despenca. Entre esses surtos? Nada muda. Você roda os mesmos textos, o mesmo layout, os mesmos títulos por semanas ou meses. Auto research inverte esse modelo. Em vez de mudanças grandes e infrequentes, você faz mudanças pequenas e contínuas. E a matemática da melhoria contínua é contraintuitiva. Uma melhoria de 1% ao dia — composta ao longo de um ano — não dá um ganho de 365%. Dá um ganho de 37x. Isso é 1,01 elevado à 365ª potência. James Clear popularizou isso em Atomic Habits, mas Karpathy transformou em um padrão de engenharia. O loop de auto research é o mecanismo que torna a melhoria composta mecânica em vez de aspiracional. O inverso é igualmente brutal. Um declínio de 1% ao dia composto resulta em uma perda de 97%. Estagnação não é neutra — é erosão lenta enquanto concorrentes iteram ao seu redor. O número de 37x é teórico. Você não vai sustentar melhorias de 1% ao dia em qualquer métrica individual para sempre. Retornos decrescentes são reais. Mas o padrão de iteração automatizada contínua? Esse é o diferencial. Mesmo uma melhoria média de 0,1% por iteração, rodando duas vezes por semana, produz ganhos significativos ao longo de um trimestre. E a parte crítica: a IA cuida da iteração, não você. A história do WD-40 captura isso perfeitamente. O produto recebeu seu nome porque foram necessárias 40 tentativas para acertar a fórmula de deslocamento de água. Quarenta iterações. A maioria das pessoas teria parado na quinta. Auto research remove a tendência humana de desistir cedo tornando cada iteração praticamente gratuita. Essa é a teoria. Aqui está como o sistema real se parece.

Três Componentes, Um Loop: A Arquitetura de Auto Research

O framework de auto research — seja aplicando-o ao treinamento de ML como Karpathy ou a métricas de negócio como eu — sempre se reduz a três componentes: Uma coisa para mudar. Uma única variável ou elemento que você está disposto a deixar o Claude modificar. Um título. O texto de um botão CTA. Uma linha de assunto de e-mail. A ordem dos benefícios de uma página de preço. Não cinco coisas de uma vez — uma coisa. Isolamento importa porque se você muda três variáveis e o desempenho melhora, você não sabe qual mudança causou isso. Uma métrica para medir. Um número objetivo e quantitativo que diz se a mudança ajudou ou prejudicou. Taxa de conversão. Taxa de cliques. Taxa de rejeição. Taxa de abertura. Não "vibes." Não "parece melhor." Um número. Um método para ler os resultados. Uma forma do Claude realmente acessar os dados de desempenho sem você copiar manualmente em um prompt. É aqui que a maioria das pessoas trava, e vou mostrar a solução que encontrei na seção de implementação. O loop em si é extremamente simples:

1. Claude lê os dados de desempenho atuais (o "controle")
2. Claude gera uma variante (o "desafiante")
3. Você implanta o desafiante
4. Aguarda dados acumularem
5. Claude lê os novos dados de desempenho
6. Se desafiante > controle → desafiante vira a nova baseline
7. Se controle > desafiante → reverter, tentar abordagem diferente
8. Repetir a partir do passo 1

Isso é lógica de A/B testing, mas com a IA cuidando dos passos 1, 2, 5, 6, 7 e 8 autonomamente. Seu trabalho se reduz ao passo 3 (implantar a mudança) e ao passo 4 (esperar). E com as ferramentas certas — a automação de navegador do Claude Co-work, por exemplo — até a implantação pode ser automatizada. O repositório original do Karpathy implementa isso para treinamento de ML. Seus três arquivos mapeiam diretamente para este framework:

• prepare.py — Preparação de dados fixa e utilitários. O agente nunca toca nisso. É a base estável.
• train.py — O único arquivo que o agente edita. Contém a arquitetura do modelo, hiperparâmetros, otimizador e loop de treinamento. Tudo pode ser modificado.
• program.md — O arquivo de instruções. Diz ao agente o que otimizar, como medir sucesso e quais restrições respeitar. O agente modifica train.py, roda um ciclo de treinamento de 5 minutos, verifica se a perda de validação melhorou, mantém ou descarta a mudança e repete. Em dois dias, o agente do Karpathy rodou 700 experimentos e encontrou 20 otimizações genuínas. Quando esses 20 ajustes foram aplicados a um modelo maior, a velocidade de treinamento melhorou 11%. A versão de negócio segue a mesma estrutura — arquivos diferentes, mesmo padrão. Deixe-me mostrar como adaptei.

Configurando Seu Ambiente de Auto Research

Vou descrever a configuração que realmente uso, não um ideal teórico. Parte disso é improvisado. Funciona.

Passo 1: Defina Sua Métrica e Crie um Arquivo de Contexto de Negócio

Escolha uma métrica. Eu escolhi a taxa de cliques em um botão CTA de landing page porque o loop de feedback é rápido (tenho tráfego suficiente para leituras semanais) e a variável é isolada (texto do botão e contexto ao redor). Depois crie um arquivo business.md que dê ao Claude o contexto necessário para tomar decisões inteligentes. Essa é a parte que a maioria das pessoas pula, e é a parte que mais importa. Sem contexto de negócio, o Claude gera textos de marketing genéricos. Com ele, o Claude gera textos que realmente se encaixam na sua audiência. Aqui está uma versão simplificada do meu:

# Business Context
## Who We Are
Ramlit Limited — software development agency serving B2B clients.
Primary service: custom web application development.
Average project size: $15K-$50K.
## Target Audience
- CTOs and engineering leads at mid-size companies (50-500 employees)
- Evaluating build-vs-buy for internal tools
- Pain points: slow development cycles, technical debt, unreliable freelancers
## Current Landing Page Performance
- Monthly visitors: ~2,400
- Current CTA click-through rate: 3.2%
- Primary CTA: "Get a Free Quote"
- Traffic sources: 60% organic, 25% referral, 15% direct
## Brand Voice
Professional but direct. No buzzwords. Results-focused.
Reference tone: ramlit.com existing copy.
## Constraints
- Do not change the core value proposition
- Do not use urgency tactics ("limited time", "act now")
- Keep CTA under 6 words
- All changes must maintain professional tone

Quanto mais específico seu arquivo de contexto, mais inteligentes ficam as sugestões do Claude. Aprendi isso com meu trabalho em sistemas de IA auto-aprimoráveis — a qualidade do documento de contexto determina diretamente a qualidade do output da IA. Contexto genérico produz resultados genéricos.

Passo 2: Configure Seu Pipeline de Dados

É aqui que a coisa fica séria — e onde a maioria das configurações de auto research quebra. A versão do Karpathy tem facilidade. A métrica (perda de validação) é computada pelo próprio script de treinamento. O agente roda o script, lê a saída e sabe imediatamente se o desempenho melhorou. Limpo, contido, sem dependências externas. Métricas de negócio não são tão organizadas. Seus dados de conversão vivem no Google Analytics. Ou Stripe. Ou um dashboard de plataforma que não tem API. Colocar esses dados em um formato que o Claude consiga ler é o primeiro desafio técnico real. Testei três abordagens: Opção A: Integração direta com API. Se sua plataforma de analytics tem uma API (Google Analytics 4, Mixpanel, Amplitude), você pode escrever um script que puxa a métrica relevante e despeja em um arquivo que o Claude consegue ler. Essa é a abordagem mais limpa, mas requer alguma configuração.

# Example: Pull GA4 data into a metrics file
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import RunReportRequest
import json
from datetime import datetime
client = BetaAnalyticsDataClient()
request = RunReportRequest(
    property=f"properties/YOUR_PROPERTY_ID",
    dimensions=[{"name": "pagePath"}],
    metrics=[
        {"name": "screenPageViews"},
        {"name": "conversions"},
    ],
    date_ranges=[{"start_date": "7daysAgo", "end_date": "today"}],
)
response = client.run_report(request)
# Format for Claude consumption
metrics = {
    "date_pulled": datetime.now().isoformat(),
    "period": "last_7_days",
    "landing_page": "/services",
    "pageviews": int(response.rows[0].metric_values[0].value),
    "conversions": int(response.rows[0].metric_values[1].value),
    "conversion_rate": round(
        int(response.rows[0].metric_values[1].value)
        / int(response.rows[0].metric_values[0].value) * 100, 2
    )
}
with open("metrics/current_performance.json", "w") as f:
    json.dump(metrics, f, indent=2)

Opção B: Automação de navegador com Claude Co-work. Quando APIs não estão disponíveis — e para um número surpreendente de plataformas, não estão — o Claude Co-work pode fazer scraping de dados do dashboard diretamente. Cobri isso no meu post sobre tarefas agendadas com Claude Co-work. Você configura uma tarefa agendada que abre seu dashboard de analytics, lê os números relevantes e os escreve em um arquivo ou página do Notion. Opção C: Assistida manualmente (a versão honesta). Nas minhas primeiras duas semanas, simplesmente copiei os números em um arquivo metrics.json toda segunda-feira de manhã. Levava 90 segundos. Não é glamuroso. Mas me permitiu validar o loop em si antes de investir tempo em automação. Não deixe que a infraestrutura perfeita impeça você de começar. Comecei com a Opção C e migrei para a Opção B depois do primeiro mês quando confirmei que o loop estava produzindo ganhos reais. Se você está começando, faça o mesmo. Automatize o pipeline de dados depois de ter provado que o loop de otimização funciona.

Passo 3: Crie Seu Arquivo de Programa

Esse é seu program.md — o conjunto de instruções que diz ao Claude como rodar o loop. Aqui está a estrutura que uso:

# Auto Research: Landing Page CTA Optimization
## Objective
Improve the click-through rate on the /services landing page CTA.
## Current Baseline
- Control CTA: "Get a Free Quote"
- Control CTR: 3.2% (last 7 days, from metrics/current_performance.json)
## Rules
1. Read the current metrics from metrics/current_performance.json
2. Read the business context from business.md
3. Analyze why the current CTR might be underperforming
4. Generate ONE challenger variant — a new CTA copy and 2-3 sentences
   of surrounding context
5. Explain WHY you expect the challenger to outperform (hypothesis)
6. Write the challenger to variants/challenger_[date].md
7. After deployment and data collection, compare challenger vs control
8. If challenger wins: update baseline in this file
9. If control wins: log the failed hypothesis and try a different approach
## Change Constraints
- CTA must be under 6 words
- Surrounding copy changes limited to the 3 sentences nearest the CTA
- No urgency language, no discount offers
- Maintain professional B2B tone
## Experiment Log
| Date | Variant | Hypothesis | Result | CTR |
|------|---------|-----------|--------|-----|
| Baseline | "Get a Free Quote" | — | Control | 3.2% |

O log de experimentos no final é crítico. Ele dá ao Claude memória entre iterações. Sem ele, o agente poderia sugerir a mesma mudança duas vezes ou não aprender com falhas anteriores. Cada vez que o loop roda, o Claude lê o log, vê o que foi testado, o que funcionou e o que não funcionou — e então gera uma variante que se baseia nesse conhecimento acumulado.

Passo 4: Configure a Frequência do Loop

Com que frequência o loop deve rodar? Depende do seu tráfego e velocidade de feedback. Para minha landing page com ~2.400 visitantes mensais, iterações semanais me dão dados suficientes para medir diferenças significativas. Sites de alto tráfego (10.000+ visitantes diários) poderiam rodar diariamente. Campanhas de e-mail poderiam rodar por envio. A restrição principal: você precisa de dados suficientes entre iterações para distinguir sinal de ruído. Se está testando uma mudança de CTA e apenas 50 pessoas a veem antes da próxima iteração, seus dados não significam nada. Espere significância estatística — ou pelo menos significância prática. Configurei o meu como uma tarefa agendada semanal no Claude Co-work. Toda segunda-feira às 8h, o Claude lê as métricas mais recentes, compara com o controle da semana anterior e gera o próximo desafiante se os dados são conclusivos. Se você tem curiosidade sobre a mecânica de agendamento, eu passo pela configuração exata do Claude Co-work no meu guia de automação de tarefas agendadas. A versão curta: você cria uma tarefa agendada no painel do Co-work, aponta para o diretório do seu projeto e configura a recorrência.

O Que Realmente Aconteceu Quando Rodei Isso Por Duas Semanas

Aqui eu paro de falar sobre teoria e mostro a realidade. Incluindo as partes constrangedoras. Semana 1: A Baseline Métricas iniciais: 3,2% CTR em "Get a Free Quote." 587 pageviews. 19 cliques no CTA. O Claude leu o contexto de negócio, analisou a baseline e gerou seu primeiro desafiante:

CTA Desafiante: "See What We'd Build For You" Hipótese: O CTA atual implica uma interação de venda transacional ("orçamento"). O público-alvo (CTOs, líderes de engenharia) está em modo de avaliação, não de compra. Reformular o CTA como um convite para ver uma solução personalizada reduz o comprometimento percebido e aumenta a curiosidade. Troquei o texto do CTA na segunda à tarde. Levou dois minutos no CMS. Resultados Semana 1: 612 pageviews. 27 cliques. 4,4% CTR. Uma melhoria de 37,5% sobre a baseline. Minha reação imediata foi suspeita. Um aumento de 37,5% mudando cinco palavras? Pareceu alto demais. Poderia ser ruído. Poderia ser um mix de tráfego diferente naquela semana. Anotei e segui em frente. Semana 2: O Desafiante Confiante Demais O Claude leu os resultados da Semana 1, notou a melhoria e ficou — vou antropomorfizar aqui — ambicioso. A próxima sugestão: CTA Desafiante: "Your Custom Build Starts Here" Hipótese: Construindo sobre o sucesso do enquadramento de personalização ("What We'd Build For You"), esta variante adiciona momentum para frente ("Starts Here") mantendo baixo comprometimento. O possessivo "Your" aumenta a psicologia de propriedade. Hipótese razoável. Implantei. Resultados Semana 2: 591 pageviews. 22 cliques. 3,7% CTR. Melhor que a baseline original, mas pior que o desafiante da Semana 1. Então o Claude reverteu para o vencedor da Semana 1 ("See What We'd Build For You") como nova baseline, registrou o experimento falho e anotou no log de experimentos: "Enquadramento possessivo + linguagem de ação teve desempenho inferior ao enquadramento de curiosidade. A próxima iteração deve explorar variações da abordagem de curiosidade em vez de mudar para linguagem de ação." Essa anotação — essa análise autocorretiva — é o que torna auto research diferente de um humano fazendo testes A/B. Eu não teria escrito essa síntese. Teria olhado o número, pensado "isso não funcionou," e seguido em frente sem extrair a lição. O Claude captura sistematicamente por que algo falhou e usa isso para informar a próxima tentativa. Os Resultados Correntes Após Duas Semanas: | Semana | CTA | CTR | vs. Baseline | |------|-----|-----|-------------| | 0 (Controle) | "Get a Free Quote" | 3,2% | — | | 1 | "See What We'd Build For You" | 4,4% | +37,5% | | 2 | "Your Custom Build Starts Here" | 3,7% | +15,6% | | 3 (atual) | "See What We'd Build For You" (revertido) | Em andamento | — | Duas iterações. Um vencedor, um perdedor. O sistema aprendeu com ambos. E minha nova baseline está 37,5% acima de onde comecei. Agora imagine isso rodando por 26 semanas — meio ano — com o efeito composto de cada variante vencedora se tornando o novo piso. Isso é auto research.

O Repositório do Karpathy: Traduzindo Experimentos de ML para Uso Empresarial

Deixe-me fazer a ponte entre o que Karpathy construiu e o que você realmente vai usar, porque as implementações parecem diferentes mesmo que o padrão seja idêntico. O repositório autoresearch do Karpathy é focado na otimização de treinamento de redes neurais. O agente modifica decisões de arquitetura, hiperparâmetros, configurações de otimizador — escolhas técnicas que afetam uma única métrica: perda de validação. Todo o loop de feedback é autocontido. train.py roda por 5 minutos, gera um valor de perda, e o agente decide se mantém a mudança. O repositório viralizou (49.800+ estrelas no GitHub no momento desta escrita) porque demonstrou algo que as pessoas teorizavam mas não tinham visto funcionar de forma limpa: um agente de IA que genuinamente melhora um sistema através de experimentação autônoma, não apenas prompting. Mas a menos que você esteja treinando redes neurais, precisa adaptar o padrão. Aqui está a tabela de tradução:

O Problema de Dados Que Ninguém Comenta (E Minha Solução)

Aqui está a verdade inconveniente sobre aplicar auto research a métricas de negócio: a maior parte dos seus dados importantes vive atrás de dashboards que não foram projetados para acesso programático. Google Analytics tem API. Stripe tem API. Mas Skool? Os dados detalhados de engajamento do ConvertKit? Seu dashboard do WordPress? Seu editor de temas do Shopify? Metade das ferramentas que founders realmente usam não expõem as métricas que você precisa através de APIs limpas. Jack Roberts destacou exatamente esse problema no seu walkthrough, e a solução dele é a correta: automação de navegador. As capacidades de navegador do Claude Co-work podem navegar até um dashboard, ler os números e escrevê-los em um arquivo. Não é elegante. Não é uma integração adequada. Mas funciona de forma confiável para o passo de "ler a métrica" do loop. A configuração fica assim:

1. Crie uma tarefa no Co-work que navegue até seu dashboard de analytics
2. Faça login usando credenciais salvas (ou, melhor, uma sessão que permanece autenticada)
3. Leia a métrica específica da página — o Claude consegue identificar e extrair números de interfaces de dashboard
4. Escreva a métrica em um arquivo JSON ou página do Notion que seu loop principal de auto research lê Testei isso com um dashboard do Google Analytics e um banco de dados do Notion. O Claude Co-work abriu a página do GA, encontrou a taxa de conversão para minha página-alvo, extraiu o número e escreveu numa tabela do Notion. Levou cerca de 45 segundos por execução. Não é rápido, mas para uma cadência semanal? Tranquilo. Para plataformas que requerem navegação mais complexa — múltiplos cliques, filtros dropdown, seleções de período — você precisará ser mais explícito nas instruções da tarefa do Co-work. Descreva cada clique. Especifique com qual elemento interagir. Quanto mais precisas suas instruções, mais confiável a automação. Se você prefere que alguém construa todo esse pipeline de dados e loop de auto research do zero, eu aceito exatamente esse tipo de projetos de automação com IA. Você pode ver o que construí em fiverr.com/s/EgxYmWD. Uma alternativa que vale mencionar: Google Sheets como camada intermediária. Você pode configurar uma planilha que importa dados de várias fontes (usando conectores nativos, Zapier ou entrada manual) e depois fazer o Claude ler a planilha via API do Google Sheets. É um adaptador universal. Bagunçado, mas universalmente compatível.

Escolhendo a Métrica Certa: Onde Auto Research Funciona (e Onde Não)

Nem toda métrica é boa candidata para auto research. Aprendi isso tentando otimizar a coisa errada primeiro. Candidatos de alto valor:

• Taxas de conversão de landing pages — Feedback rápido, métrica clara, variável isolada. Minha principal recomendação para seu primeiro loop de auto research.
• Taxas de abertura de linhas de assunto de e-mail — Cada envio é um novo experimento. Alto volume de dados se sua lista tem 1.000+.
• Taxas de cliques de textos de anúncios — Plataformas como Google Ads e Meta já fornecem a métrica. Você só precisa que o Claude gere variantes e leia resultados.
• Taxas de conclusão de página de checkout — Alto impacto no negócio, mensurável, e pequenas mudanças de texto/layout podem mover a agulha significativamente.
• Taxas de adoção de funcionalidades em SaaS — Se você consegue medir quantos usuários ativam uma funcionalidade, pode otimizar o texto de onboarding ou a UI que leva até ela. Candidatos de baixo valor (evite estes para auto research):
• Rankings SEO — Ciclo de feedback muito lento (semanas a meses). Muitas variáveis confundidoras. Você não consegue isolar o que causou uma mudança de ranking.
• Reconhecimento de marca — Não é quantificável de forma significativa para loops de iteração.
• Scores NPS — Muito subjetivos e muito infrequentes para iteração rápida.
• Receita — Alto nível demais. Receita é um output de muitos inputs. Otimize os inputs individualmente.
• Engajamento em redes sociais — Muito ruidoso. Mudanças de algoritmo, aleatoriedade viral e humor da audiência confundem os dados. A métrica ideal de auto research tem quatro propriedades:

1. Alto volume — Eventos suficientes por ciclo para medir diferenças
2. Feedback rápido — Resultados disponíveis em dias, não meses
3. Variável isolada — Você pode mudar uma coisa e medir o impacto
4. Dados acessíveis — Você consegue ler a métrica programaticamente (ou via automação de navegador) Se sua métrica escolhida não atende os quatro critérios, escolha outra. O loop só funciona se os dados são limpos, rápidos e atribuíveis.

A Qualidade das Perguntas Importa Mais Que a Qualidade das Respostas

Isso é algo que Jack Roberts enfatizou e que merece sua própria seção, porque é o insight mais subestimado em todo o framework de auto research. Quando você escreve seu program.md, não está apenas dando instruções ao Claude. Está definindo o espaço do problema. E a qualidade dessa definição do problema determina o teto do que o Claude pode descobrir. Definição ruim do problema:

"Melhore a taxa de conversão do nosso site." Boa definição do problema: "Melhore a taxa de cliques no CTA da página /services. O público-alvo são CTOs avaliando decisões de build-vs-buy. O CTR atual é 3,2% com 600 pageviews semanais. O CTA aparece abaixo de uma seção de benefícios e acima de um bloco de depoimentos. O tráfego é 60% busca orgânica." A diferença? A segunda versão dá ao Claude contexto suficiente para formar hipóteses inteligentes. Ele conhece a mentalidade da audiência. Conhece a estrutura da página. Conhece a fonte de tráfego, o que sugere intenção de busca. Cada um desses detalhes molda as sugestões que o Claude gera. Descobri que investir 30 minutos escrevendo um business.md e program.md detalhados produz melhores resultados ao longo de 10 iterações do que investir 5 minutos em um briefing vago e rodar 50 iterações. Contexto é alavancagem. Isso se conecta a um princípio mais amplo que tenho observado em todo meu trabalho com Claude Code: o gargalo quase nunca é a capacidade da IA. É a capacidade do humano de definir o problema com precisão. Auto research amplifica qualquer sinal que você fornecer — então se o sinal é vago, você obtém otimização vaga. Se o sinal é preciso, você obtém ganhos precisos.

Escalando Além de Uma Única Métrica: A Arquitetura Multi-Loop

Uma vez que seu primeiro loop de auto research está funcionando e produzindo ganhos, a pergunta natural é: posso rodar múltiplos loops simultaneamente? Sim. Mas com cuidado. O risco com múltiplos loops de otimização simultâneos são os efeitos de interação. Se você está otimizando o CTA da sua landing page e seu título hero e sua seção de depoimentos ao mesmo tempo, uma mudança em um pode afetar o desempenho de outro. Sua melhoria do CTA pode parecer uma regressão porque a mudança no título acima deslocou a atenção do usuário. Minha abordagem: sequencial, não paralela. Rode um loop até ele se estabilizar (significando que as melhorias chegam a um platô e os desafiantes param de bater o controle consistentemente). Então trave essa variável, defina a versão vencedora como permanente e inicie um novo loop na próxima variável. Para minha landing page, a sequência fica assim:

1. Texto do CTA (rodando agora)
2. Título hero (próximo)
3. Seção de prova social (depois que o título estabilizar)
4. Ordem do bloco de benefícios (por último) Cada loop roda por 4-8 semanas antes de eu passar para a próxima variável. Paciente? Sim. Mas preserva a clareza causal que torna os dados confiáveis. Se você absolutamente precisa rodar loops paralelos, faça em páginas diferentes ou canais diferentes. Otimize o CTA da sua landing page e as linhas de assunto dos seus e-mails simultaneamente — são sistemas independentes com métricas independentes. Só não otimize dois elementos na mesma página ao mesmo tempo.

O Que a Maioria das Pessoas Vai Errar

Venho testando isso há duas semanas e conversando com outros três builders fazendo o mesmo. Aqui estão os padrões que vejo falhando: Mudar muitas variáveis por iteração. A tentação de "melhorar" mudando cinco coisas de uma vez é forte. Resista. Você precisa de isolamento para aprender o que funciona. Uma mudança. Uma medição. Uma decisão. Ignorar significância estatística. Se 50 pessoas viram seu novo CTA e 3 clicaram (6% CTR) versus 2 clicando no antigo (4% CTR), isso não é uma diferença significativa. Você precisa de volume de dados suficiente por iteração para confiar no resultado. Para sites de baixo tráfego, isso significa ciclos de iteração mais longos — semanal no mínimo, quinzenal para tráfego muito baixo. Usar métricas subjetivas. "A página parece melhor" não é uma métrica. "O novo texto está mais alinhado com a marca" não é uma métrica. O loop de auto research requer um número. Se você não consegue expressar seu objetivo como um número, o loop não pode otimizar para ele. Pular o contexto de negócio. Rodar auto research sem um arquivo business.md é como contratar um copywriter e não contar quem são seus clientes. O Claude vai gerar algo. Não vai gerar nada particularmente útil. Desistir após a primeira iteração falha. O desafiante da Semana 2 no meu teste teve desempenho pior que o vencedor da Semana 1. Se eu tivesse parado ali, teria perdido o aprendizado que informou a abordagem da Semana 3. Experimentos falhos não são fracassos — são pontos de dados que estreitam o espaço de busca para a próxima iteração. O agente do Karpathy rodou 700 experimentos. Muitos deles pioraram as coisas. Esse é o processo.

O Quadro Geral: Por Que Isso Muda Minha Forma de Pensar Sobre Otimização

Antes de auto research, meu processo de otimização era assim: ter uma ideia, implementar, verificar resultados em duas semanas, esquecer de verificar, verificar um mês depois, não lembrar o que mudei, recomeçar. Depois de auto research, meu processo de otimização é assim: definir a métrica, definir as restrições, deixar o Claude rodar o loop, revisar o log de experimentos semanalmente, intervir apenas quando algo parece errado. A diferença na carga cognitiva é enorme. Não gasto energia mental em "o que devo testar em seguida?" Esse é o trabalho do Claude. Gasto energia mental em "o framework está corretamente definido?" — que é uma pergunta com muito mais alavancagem. E o efeito composto é real. Não o teórico 37x. Mas uma melhoria de 37,5% em duas semanas em uma única métrica, com um sistema que vai continuar iterando? Projete isso seis meses à frente. Mesmo com retornos decrescentes, o impacto cumulativo em uma métrica de negócio que importa — conversões, cliques, cadastros — é significativo. O padrão de auto research não é complicado. Três arquivos. Uma métrica. Um loop. A parte difícil não é construir. A parte difícil é escolher a métrica certa, escrever contexto preciso e ser paciente o suficiente para deixar o efeito composto funcionar. Karpathy mostrou que isso funciona para pesquisa em ML em uma escala que impressionou a indústria. A versão de negócio é mais lenta, mais bagunçada e menos dramática. Também é acessível a qualquer pessoa com uma assinatura do Claude e uma métrica que importa para ela. Comece com uma métrica. Escreva seu arquivo de contexto hoje à noite. Configure o loop neste fim de semana. Depois deixe rodar enquanto você dorme. Daqui a seis meses, você vai desejar ter começado hoje — ou vai ficar feliz por ter começado.

Perguntas Frequentes

O que é auto research no Claude Code?

Auto research é um loop de otimização autônomo onde o Claude Code testa iterativamente mudanças contra uma métrica mensurável, mantém melhorias, descarta falhas e repete. Andrej Karpathy popularizou o padrão em março de 2026 com seu repositório autoresearch no GitHub, que rodou 700 experimentos de ML em dois dias. Para aplicações de negócio, o mesmo padrão otimiza taxas de conversão, taxas de cliques e outras métricas quantificáveis.

Preciso de experiência em programação para configurar um loop de auto research?

Gerenciamento básico de arquivos e conforto com um editor de texto são suficientes para uma configuração assistida manualmente onde você copia métricas em um arquivo JSON semanalmente. Para automação completa — integrações de API, scraping de navegador, tarefas agendadas — você precisará de habilidades intermediárias em Python ou familiaridade com os recursos de automação de navegador do Claude Co-work. Os arquivos program.md e business.md são Markdown puro.

Quanto tráfego preciso para auto research funcionar?

Você precisa de eventos suficientes por ciclo de iteração para distinguir sinal de ruído. Para otimização de landing page com ciclos semanais, 500+ pageviews por semana é um mínimo razoável. Otimização de e-mail precisa de 1.000+ destinatários por envio. Testes de texto de anúncios funcionam com volumes menores porque plataformas de anúncios fornecem medição robusta. Sites de baixo tráfego devem usar ciclos quinzenais ou mensais.

Posso rodar auto research em múltiplas métricas ao mesmo tempo?

Rode loops paralelos em sistemas independentes — otimize sua landing page e suas linhas de assunto de e-mail simultaneamente. Evite rodar loops paralelos na mesma página ou funil, porque mudanças em um elemento podem afetar o desempenho de outro, tornando impossível atribuir resultados. Otimização sequencial com uma variável por vez produz dados mais limpos e confiáveis.

Como o repositório autoresearch do Karpathy se relaciona com otimização empresarial?

O repositório do Karpathy otimiza o treinamento de redes neurais deixando um agente de IA modificar train.py, rodar um ciclo de treinamento, medir a perda de validação e manter ou descartar mudanças. A versão de negócio usa o mesmo padrão de controle-vs-desafiante mas troca treinamento de ML por textos de negócio, perda de validação por taxa de conversão e execuções de treinamento de 5 minutos por coleta semanal de dados. O framework central — mudar, medir, decidir, repetir — é idêntico.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura tech? Adoraria ajudar.

• Fiverr (soluções sob medida e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções enterprise): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io