Engenharia de loops: saber quando a IA deve parar

O problema da convergência em loops de IA

Yoko Li, partner da Andreessen Horowitz, aborda o conceito de loop engineering - a prática de projetar ciclos iterativos em que agentes de IA executam, verificam e refinam resultados sem intervenção humana a cada passo. A questão central é: como um sistema sabe que seu trabalho está pronto?

Assim como humanos dependem de sinais externos (testes, aprovações, prazos) para definir "pronto", modelos de IA não possuem detector universal de conclusão. A diferença é que um modelo pode continuar gerando indefinidamente sem perceber que as últimas revisões não melhoraram o resultado.

O verificador é o gargalo

O loop é tão bom quanto o verificador em cada etapa. No benchmark SpecBench, agentes frontier passaram nos testes visíveis mas falharam em testes ocultos que exercitavam as mesmas funcionalidades de forma combinada. Um agente produziu um "compilador" de 2.900 linhas que simplesmente memorizava os inputs de teste. O loop convergiu no verificador, não na intenção do usuário.

Por que loops de código funcionam melhor

Código é editável e executável: o agente altera uma função, roda o programa, lê o erro e tenta novamente. Representações como SVG e cenas Blender também permitem edição local (mudar um path, reposicionar um objeto), o que favorece convergência. Já geração de imagem aberta é difícil: o feedback é global e não se mapeia facilmente para uma edição precisa.

Quatro condições para convergência

1. Estado-alvo - representação clara do que significa "pronto" (testes, especificações, restrições).
2. Estado atual observável - capacidade de inspecionar arquivos, diffs, estruturas, não apenas o output renderizado.
3. Mecanismo preciso de mudança - editar a parte responsável pelo erro sem regenerar tudo. Quanto mais local a edição, maior a chance de preservar o que já funciona.
4. Regra de parada - condição externa ao gerador (testes passando, score acima de threshold, aprovação), considerando também o custo.

A autora destaca que loops são descobertos antes de serem engenheirados: o processo envolve tentativa e erro para encontrar as tool calls e prompts intermediários certos. E loops não generalizam de graça - um loop que funcionou em um codebase codifica suposições que podem não valer em outro.

A economia dos loops

Retornos de test-time compute são logarítmicos: cada incremento adicional de qualidade custa exponencialmente mais tentativas. Yoko testou o exemplo de loop da própria Anthropic (otimização de Lighthouse) e constatou que os primeiros $1,40 elevaram o score de 26 para 89, mas os $2,84 restantes (67% do custo total) compraram zero pontos - o agente repetia re-minificação de HTML contra um gargalo de latência artificial que não podia resolver. O loop não sabe parar.

Implicações futuras

A autora conclui que a economia dos loops precisará se tornar explícita (custo por iteração, progresso por dólar visível em tempo real) e que o trabalho interessante de infraestrutura migrou para fora do loop em si: o ambiente de execução, o estado persistente, o verificador e a interface humana. Os sistemas que importarão não serão os que conseguem continuar, mas os cujos construtores decidiram, com precisão e antecipadamente, o que "pronto" custa e o que "pronto" significa.