Loop Engineer: o método de Andrej Karpathy para criar agentes que melhoram sistemas em ciclos autônomos

Durante bastante tempo, a maior parte do mercado usou IA como uma ferramenta passiva.

O fluxo era quase sempre o mesmo:

1. você escreve um prompt;
2. o modelo responde;
3. você avalia;
4. você tenta outro prompt.

Isso funciona. Mas funciona como uma ferramenta manual. O humano continua sendo quem observa, decide, testa, corrige e repete cada passo. A IA ajuda, mas ainda opera como um componente reativo.

O salto proposto por Andrej Karpathy em 2026 com autoresearch muda esse enquadramento. Em vez de perguntar "qual prompt gera uma boa resposta?", o engenheiro passa a perguntar "qual loop faz o agente propor uma mudança, executar o teste certo, medir o resultado e decidir se mantém ou reverte?".

Esse deslocamento parece pequeno. Não é.

Ele muda o papel do desenvolvedor de operador de prompts para designer de sistemas de trabalho. O futuro passa menos por escrever prompts heroicos e mais por projetar loops bons o bastante para que agentes consigam melhorar um sistema com autonomia limitada, rastreabilidade e critério técnico.

Esse artigo chama isso pelo nome certo: Loop Engineering.

Principais aprendizados

• Loop Engineering não substitui Prompt Engineering nem Context Engineering; ele orquestra os dois em um ciclo executável.
• O autoresearch do Karpathy prova o padrão em um ambiente mínimo: um arquivo editável, uma métrica objetiva e um budget fixo de experimento.
• O valor real não está em "deixar a IA solta", mas em desenhar escopo, métricas, rollback e verificação.
• O mesmo padrão funciona fora do treino de LLM: build, bundle size, testes, segurança, SEO técnico e qualidade de produto.
• Ferramentas como spec-loop são úteis porque formalizam runbooks, cenários e verificações para esses loops em times reais.

O que é Loop Engineering

Loop Engineering é a disciplina de projetar o ciclo no qual um agente trabalha.

Em um loop bem desenhado, o agente não recebe apenas um prompt. Ele recebe um ambiente operacional:

• um objetivo claro;
• um contexto inicial suficiente;
• um conjunto limitado de arquivos, ferramentas e permissões;
• uma métrica explícita de sucesso;
• um processo de verificação;
• uma política de aceite e rejeição;
• um critério de parada;
• logs e rastreabilidade.

Prompt Engineering pergunta:

qual prompt eu escrevo para conseguir uma boa resposta?

Loop Engineering pergunta:

qual sistema eu desenho para que o agente gere, teste, corrija e melhore continuamente?

Essa diferença é decisiva. Quando o problema é complexo, uma boa resposta isolada quase nunca basta. O que você precisa é de um processo que suporte iteração, comparação, reversão e aprendizado.

O experimento de Andrej Karpathy: Autoresearch

No README público de karpathy/autoresearch, publicado em março de 2026, Karpathy resume a ideia de forma direta: dar a um agente de IA um setup pequeno, real e hackeável de treino de LLM e deixar que ele experimente sozinho durante a noite.

O loop base funciona assim:

1. o agente lê program.md;
2. modifica train.py;
3. roda um treino curto;
4. mede val_bpb;
5. mantém a mudança se a métrica melhorar;
6. reverte se piorar;
7. repete.

O ponto mais interessante aqui não é só a automação do treino. O ponto central é a mudança de interface.

O humano para de editar diretamente cada detalhe técnico e passa a programar o ambiente onde o agente pesquisa. O artefato mais importante deixa de ser apenas o código do modelo e passa a ser o contrato operacional do loop.

No repositório, Karpathy deixa três decisões muito fortes:

• o experimento roda em um setup pequeno o bastante para iterar rápido;
• o treino tem budget fixo de 5 minutos por rodada;
• a métrica é objetiva e comparável: val_bpb, menor é melhor.

Isso transforma "tentar ideias" em uma máquina de comparação disciplinada.

Os três arquivos centrais do Autoresearch

Karpathy mantém o repositório deliberadamente pequeno. O README destaca três arquivos que concentram o padrão.

prepare.py

prepare.py é a infraestrutura fixa do experimento. Ele prepara dados, organiza dataset, treina tokenizador BPE e define utilitários de runtime e avaliação.

Esse arquivo quase nunca deve ser alterado pelo agente porque ele representa as condições do experimento. Em termos práticos, ele estabiliza o tabuleiro.

train.py

train.py é o campo de jogo do agente.

Ali entram:

• arquitetura;
• hiperparâmetros;
• otimizador;
• batch size;
• learning rate;
• loop de treinamento;
• escolhas de performance.

Ao restringir a área de mudança a um único arquivo, o loop fica mais auditável. O diff é menor. O rollback é mais claro. O erro de escopo cai.

program.md

program.md é o prompt operacional do sistema.

Ele precisa dizer com precisão:

• qual é o objetivo;
• o que pode e o que não pode mudar;
• qual é a métrica;
• quais comandos existem;
• como o sucesso será avaliado;
• como registrar resultados;
• quando parar.

Em outras palavras: no Loop Engineering, o humano não otimiza apenas o prompt. Ele otimiza o contrato do loop.

O diagrama do loop

Em linguagem natural, esse diagrama descreve um sistema simples e poderoso:

• o humano define a regra do jogo;
• o agente formula uma hipótese;
• o ambiente executa a verificação;
• a métrica decide;
• o histórico vira memória operacional.

O segredo não está em uma inteligência "mística". O segredo está em fechar o ciclo de feedback.

O que torna esse padrão poderoso

O ganho de Loop Engineering vem de trocar improviso por sistema.

Benefícios reais:

• iteração contínua;
• otimização baseada em métrica;
• menos tentativa manual repetitiva;
• capacidade de testar muitas hipóteses em pouco tempo;
• melhor uso do tempo humano para decisões estratégicas;
• formação de um registro incremental do que funcionou e do que falhou.

A maior vantagem, no entanto, é conceitual: melhoria deixa de ser uma sequência de prompts soltos e passa a ser um processo comparável.

Prompt Engineering, Context Engineering e Loop Engineering

As três disciplinas se complementam.

Sem Prompt Engineering, o agente interpreta mal.

Sem Context Engineering, o agente trabalha no escuro.

Sem Loop Engineering, o agente até pode produzir algo bom, mas dificilmente produz melhoria contínua com critério.

Loop Engineering aplicado a software

O erro mais comum é achar que esse padrão só serve para treino de modelo. Não serve.

Agente de performance

Objetivo: reduzir tempo de build, tempo de teste, bundle size ou latência de endpoint.

Métricas possíveis:

• tempo médio de build;
• tempo médio da suite crítica;
• Lighthouse;
• tamanho do bundle;
• latência P95.

Loop:

1. o agente identifica gargalos;
2. propõe uma mudança pequena;
3. executa benchmark;
4. compara com baseline;
5. abre PR ou mantém patch se melhorar.

Agente de qualidade

Objetivo: reduzir bugs e aumentar confiabilidade.

Métricas possíveis:

• testes passando;
• cobertura;
• erros de TypeScript;
• erros de ESLint;
• falhas de CI.

Agente de segurança

Objetivo: reduzir risco operacional.

Métricas possíveis:

• achados de SAST;
• dependências vulneráveis;
• falhas de testes de segurança;
• alertas de secret scanning.

Agente de produto

Objetivo: melhorar ativação, onboarding ou conversão.

Métricas possíveis:

• taxa de conversão;
• tempo até primeiro valor;
• queda por etapa;
• taxa de ativação.

Aqui existe um cuidado óbvio: quanto mais próximo o loop estiver de impacto em usuário ou negócio, mais importante fica o human-in-the-loop.

Aplicando a ideia no Lemon AI Hub

No contexto do Lemon AI Hub, Loop Engineering pode virar uma skill ou plugin dedicado a loops de melhoria.

Uma estrutura plausível seria:

skills/
  loop-engineer/
    README.md
    skill.md
    examples/
      performance-loop.md
      test-loop.md
      seo-loop.md
      security-loop.md
    templates/
      program.md
      metrics.md
      verifier.md

Papel de cada arquivo:

• README.md: explica o padrão, os casos de uso e os guardrails.
• skill.md: define quando acionar a skill e como o agente deve operar.
• examples/*.md: mostram loops concretos por domínio.
• templates/program.md: entrega o contrato base do loop.
• templates/metrics.md: padroniza o que medir e como comparar baseline.
• templates/verifier.md: define como validar sem deixar o próprio agente se autoaprovar.

Esse tipo de skill é útil para:

• refatoração;
• performance;
• testes;
• documentação;
• SEO técnico;
• geração de conteúdo;
• auditoria de arquitetura;
• correção de bugs;
• hardening de segurança;
• preparação para marketplace.

Loop de categorização financeira

Objetivo: melhorar a classificação automática de transações.

Métricas:

• taxa de acerto;
• volume sem categoria;
• número de correções manuais.

Loop de insights financeiros

Objetivo: melhorar qualidade e clareza das recomendações da Auri/Holo.

Métricas:

• feedback positivo;
• utilidade percebida;
• taxa de respostas genéricas;
• clareza e responsabilidade financeira.

Loop de importação de arquivos

Objetivo: melhorar parser de CSV, XLS e PDF.

Métricas:

• taxa de importação concluída;
• erros de parsing;
• campos reconhecidos corretamente.

O cuidado aqui é ético e de produto: o loop pode otimizar análise, clareza e automação, mas não deve tomar a decisão financeira final pelo usuário.

Um template prático de program.md

# Loop Program

## Objetivo
Reduzir o tamanho do bundle inicial da aplicação Next.js em pelo menos 8% sem quebrar funcionalidades críticas.

## Contexto
- Projeto: app Next.js com App Router
- Baseline atual: 312 kB no bundle inicial da homepage
- Gargalos suspeitos: imports pesados, componentes client sem necessidade, duplicação de dependências

## Arquivos permitidos
- app/**/*
- components/**/*
- lib/**/*
- package.json

## Arquivos proibidos
- infra/**/*
- scripts/deploy/*
- .github/workflows/*
- envs e secrets

## Comandos de verificação
- npm run lint
- npm run typecheck
- npm run test
- npm run build
- npm run analyze

## Métricas
- bundle inicial da homepage
- tamanho total do vendor chunk
- regressão visual zero nas telas críticas

## Critério de aceite
- bundle menor que o baseline
- build, lint, typecheck e testes passando
- sem regressão visual nas telas listadas

## Critério de rejeição
- bundle não melhora
- qualquer comando falha
- alteração aumenta complexidade sem ganho mensurável

## Política de commit
- apenas diffs pequenos
- uma hipótese por iteração
- registrar baseline, resultado e decisão

## Relatório final
- hipótese testada
- arquivos alterados
- métrica antes/depois
- decisão: manter ou reverter
- riscos residuais

Exemplo prático: loop para reduzir bundle size

Suponha um projeto Next.js com baseline de 312 kB na homepage.

O loop poderia ser:

• objetivo: reduzir pelo menos 8%;
• comandos: npm run build, npm run analyze, npm run test;
• restrições: não alterar infra, CI ou rotas de pagamento;
• estratégia: remover imports desnecessários, dividir componentes client, lazy load de bibliotecas pesadas;
• avaliação: comparar bundle e validar build/testes.

Pseudocódigo:

while (true) {
  const hypothesis = agent.createHypothesis(context)
  const patch = agent.modifyCode(hypothesis)
  const result = runBenchmark()

  if (result.bundleSize < baseline.bundleSize) {
    keepPatch()
    updateBaseline(result)
  } else {
    revertPatch()
  }
}

Na prática, isso pode ser orquestrado com Claude Code, Codex, OpenCode, GitHub Actions ou um orquestrador próprio. O ponto não é a ferramenta. O ponto é a estrutura do loop.

Implementando seu primeiro loop do zero

A teoria é clara, mas a execução exige alguns cuidados práticos. Aqui vai um roteiro testado em projetos reais:

1. Escolha o problema certo

Nem todo problema merece um loop. Bons candidatos têm:

• métrica clara: algo mensurável em segundos, kilobytes, pass/fail;
• feedback rápido: o experimento roda em menos de 5 minutos;
• escopo isolado: o agente mexe em poucos arquivos;
• baixo risco de quebra: rollback não afeta produção.

Maus candidatos: decisões de produto, mudanças que exigem revisão legal, alterações em pipelines de deploy.

2. Prepare o ambiente

Crie uma branch separada. Configure um diretório de trabalho com os arquivos que o agente pode ler e modificar. Garanta que os comandos de verificação rodem sem interação humana.

3. Escreva o program.md

Use o template acima como ponto de partida. Seja explícito sobre o que não pode mudar — agentes são literais e vão testar os limites.

4. Execute a primeira iteração manualmente

Antes de automatizar, rode o loop com supervisão. Observe:

• o agente interpretou o objetivo corretamente?
• as ferramentas estão disponíveis?
• a métrica é coletada sem ruído?
• o rollback funciona?

5. Automatize só depois

Com o ciclo validado, conecte a um scheduler, CI ou orquestrador. Defina um budget de iterações e um limite de tempo. Configure notificações para cada decisão de manter ou reverter.

6. Revise os resultados

Mesmo com automação, revise periodicamente:

• o loop está convergindo ou oscilando?
• a métrica ainda representa o objetivo real?
• o custo de execução compensa o ganho?

Padrões de loop que funcionam na prática

A comunidade vem experimentando com loops desde a publicação do autoresearch. Alguns padrões se destacam:

Loop de profundidade fixa

O agente tem um número limitado de tentativas (ex: 10 iterações). Depois disso, o melhor resultado é aceito. Útil quando o custo por iteração é alto.

Loop com pausa estratégica

Após cada melhoria, o loop para e aguarda revisão humana antes de continuar. Indicado para mudanças em produção ou domínios regulados.

Loop de varredura

O agente testa N variações de um mesmo parâmetro em paralelo e escolhe a melhor. Útil quando o espaço de busca é pequeno e bem definido.

Loop adaptativo

O agente mantém um histórico de hipóteses e ajusta a estratégia com base no que já aprendeu. A cada iteração, ele evita repetir abordagens que falharam e explora variações das que funcionaram.

Cuidados e riscos

Loop Engineering funciona muito bem quando a métrica representa o que realmente importa. Quando ela não representa, o sistema otimiza a direção errada.

Riscos principais:

• métrica errada gera otimização errada;
• o agente pode fazer overfitting no benchmark;
• requisitos não medidos podem quebrar;
• a manutenção pode piorar;
• o benchmark pode melhorar enquanto a experiência real piora;
• arquivos sensíveis podem ser alterados por engano;
• custo de execução pode aumentar;
• permissões excessivas ampliam risco de segurança.

Boas práticas:

• escopo limitado;
• métricas explícitas;
• testes automatizados;
• revisão humana;
• diffs pequenos;
• logs obrigatórios;
• rollback automático;
• ambiente isolado;
• permissões mínimas;
• humano decidindo nos pontos de alto impacto.

Loop Engineering vs AutoML

AutoML tradicional geralmente opera dentro de um espaço de busca mais fechado.

Ou seja: Loop Engineering não substitui AutoML. Ele cobre um terreno mais amplo, porque o agente pode agir sobre código, contexto, verificação e estratégia.

Onde spec-loop entra nessa conversa

https://andersonlimahw.github.io/spec-loop

A biblioteca spec-loop, publicada por mim como um CLI e protocolo aberto para QA loops orientados por especificação, é um bom exemplo de como levar essa mentalidade para times de produto.

No README público do projeto, a proposta é clara:

• rodar loops provider-agnostic de QA;
• usar specs, regras de negócio e fluxos críticos como insumo;
• gerar contexto em .specloop/;
• validar cenários locais ou remotos com runbooks e scripts.

Isso é relevante porque mostra uma extensão natural do Karpathy Loop: sair do treino de modelo e aplicar o mesmo princípio à validação de produto e qualidade operacional.

Em termos práticos, spec-loop ajuda quando você quer:

• transformar critérios de aceite em execução repetível;
• registrar iterações e achados;
• separar cenário, loop e relatório;
• tornar QA com agentes mais auditável.

Níveis de maturidade em Loop Engineering

Assim como adoção de testes automatizados ou CI/CD, a maturidade em loops segue uma escala:

Nível 1: Artesanal

O engenheiro escreve um prompt, roda um script, avalia manualmente. Não há estrutura de loop. O conhecimento fica na cabeça de quem executou. É o ponto de partida de todo mundo.

Nível 2: Ad-hoc

Há um program.md e um script de verificação, mas o loop é executado manualmente. As métricas são anotadas em um arquivo. O processo já é rastreável, mas não escala.

Nível 3: Automatizado

O loop roda sem supervisão humana. O agente executa, mede e decide manter ou reverter. Há logs e um relatório ao final. O humano só intervém em decisões de alto impacto.

Nível 4: Orquestrado

Múltiplos loops rodam em paralelo, cada um com seu escopo. Um orquestrador distribui orçamento de iterações entre eles, evita conflitos de arquivos e consolida resultados. O time opera um ecossistema de agentes de melhoria.

Nível 5: Adaptativo

Os loops aprendem com o histórico de outros loops. O orquestrador ajusta dinamicamente quais domínios recebem mais iterações com base no retorno observado. A organização desenvolve uma "memória de melhoria" institucional.

A maioria dos times que experimenta loops hoje está entre os níveis 1 e 2. O objetivo deste artigo é ajudar a chegar pelo menos no nível 3.

O novo papel do engenheiro

Esse padrão muda o que significa "trabalhar com IA".

O desenvolvedor deixa de ser apenas quem escreve código e passa a ser quem projeta sistemas que escrevem, testam e melhoram código sob controle.

Isso puxa o papel do engenheiro para mais perto de:

• designer de sistemas de trabalho;
• definidor de métricas;
• arquiteto de contexto;
• curador de restrições;
• revisor de resultados;
• criador de ambientes seguros para agentes;
• orquestrador de loops.

Em times maduros, a vantagem competitiva deixa de ser apenas "quem usa o melhor modelo" e passa a ser "quem desenha o melhor sistema de melhoria".

Como aplicar hoje

Se você quiser aplicar isso sem teatralidade:

1. escolha um loop pequeno;
2. defina uma única métrica simples;
3. limite os arquivos que o agente pode tocar;
4. rode algumas iterações manualmente;
5. registre baseline, resultado e rollback;
6. automatize só depois que o ciclo estiver confiável.

Boas primeiras apostas:

• reduzir bundle size;
• acelerar uma suite crítica de testes;
• melhorar lint/typecheck em um módulo;
• validar um fluxo crítico de produto;
• revisar acessibilidade em uma tela importante.

Conclusão

Loop Engineering não é mágica. É engenharia aplicada a agentes.

O trabalho continua sendo o mesmo, só que melhor estruturado:

• definir objetivo;
• dar contexto;
• restringir escopo;
• medir resultado;
• validar melhoria;
• repetir.

Quem dominar esse padrão tende a ganhar vantagem real em produtividade, automação e construção de produtos com IA, porque deixa de depender de inspiração pontual e passa a operar com sistemas de melhoria contínua.

Comece pequeno. Escolha uma métrica simples. Limite arquivos. Rode manualmente. Depois automatize.

Trocar prompts soltos por loops bem desenhados é uma das mudanças mais importantes da engenharia com IA em 2026.

Referências

• Andrej Karpathy, karpathy/autoresearch README (março de 2026): https://github.com/karpathy/autoresearch
• Andrej Karpathy, karpathy/nanochat README e leaderboard (consultado em 9 de julho de 2026): https://github.com/karpathy/nanochat
• Shopify Engineering, Autoresearch isn't just for training models (15 de abril de 2026): https://shopify.engineering/autoresearch
• Anderson Lima, Andersonlimahw/spec-loop README (consultado em 9 de julho de 2026): https://github.com/Andersonlimahw/spec-loop
• Anderson Lima, Andersonlimahw/lemon-ai-hub README (consultado em 9 de julho de 2026): https://github.com/Andersonlimahw/lemon-ai-hub/blob/main/plugins/karpathy-loop/SKILL.md