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

flowchart TD
    A[Humano define program.md] --> B[Agente lê contexto e objetivo]
    B --> C[Agente propõe hipótese]
    C --> D[Agente modifica arquivo permitido]
    D --> E[Executa experimento ou teste]
    E --> F[Calcula métrica]
    F --> G{Melhorou?}
    G -->|Sim| H[Mantém alteração e registra aprendizado]
    G -->|Não| I[Reverte alteração e registra falha]
    H --> B
    I --> B

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.

Disciplina	Pergunta principal	Unidade de trabalho	Papel do humano	Papel da IA	Exemplo prático
Prompt Engineering	"Como peço isso bem?"	Interação isolada	escrever instruções claras	responder bem a uma chamada	pedir um resumo técnico de um diff
Context Engineering	"Qual contexto preciso fornecer?"	Setup de informação	selecionar arquivos, docs, memória e restrições	usar contexto para responder melhor	abrir o repo, docs e arquitetura certos antes de codar
Loop Engineering	"Qual ciclo garante melhoria verificável?"	Ciclo de hipótese, execução e avaliação	desenhar regras, métricas e limites	propor mudanças, testar e aprender	reduzir bundle size com benchmark e rollback automático

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.

Aspecto	AutoML tradicional	Loop Engineering com LLM
Espaço de busca	hiperparâmetros e arquiteturas predefinidas	pode ler código e alterar lógica
Unidade de ação	busca automatizada em parâmetros	hipótese textual + patch executável
Interpretação de logs	limitada ou inexistente	pode ler logs e adaptar estratégia
Testes e verificação	focados no pipeline de ML	podem incluir build, testes, QA e regras de produto
Registro de aprendizado	geralmente experimental	pode ser narrativo, operacional e versionado

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.

Conclusão

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

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