“Eu não dou mais prompts pro Claude. Eu tenho loops rodando que dão prompts pro Claude e decidem o que fazer. Meu trabalho é escrever loops.” — essa frase de Boris Cherny não é ficção científica. É o dia a dia de quem trabalha com engenharia de software em 2026.

Armin Ronacher — o cara por trás do Flask, Jinja2, Rye e uv — publicou hoje um dos textos mais importantes do ano sobre o futuro da profissão de desenvolvedor. Em “The Coming Loop”, ele descreve uma mudança fundamental na forma como código é produzido: não são mais humanos escrevendo código com ajuda de IA. São loops automatizados que orquestram agentes de IA, decidem se o trabalho está pronto e, se não estiver, reiniciam o processo — tudo sem intervenção humana.

E a parte que assusta? Ronacher não acha isso necessariamente bom. Mas acha inevitável.

O que é o “harness loop” e por que ele muda tudo

Pra entender o que Ronacher está falando, precisa separar dois conceitos que todo mundo mistura.

O primeiro é o agent loop — o ciclo interno de qualquer agente de código. O modelo recebe uma tarefa, chama ferramentas, lê arquivos, edita código, roda testes, itera. Isso é o que o Claude Code, Cursor, Copilot e qualquer coding agent já fazem. Nada novo aqui.

O segundo é o harness loop — e é aqui que a coisa fica interessante (e assustadora). É um loop externo ao agente. Um sistema de orquestração que:

• Coloca tarefas numa fila
• Inicia um agente para executar a tarefa
• Avalia se o resultado está satisfatório
• Se não estiver, reinicia o agente com contexto modificado
• Se estiver, pega a próxima tarefa da fila

A diferença crucial: quem decide se o trabalho terminou não é o modelo, nem o humano. É o harness. O agente pode achar que finalizou, mas o harness olha os testes, analisa a cobertura, checa o lint — e manda o agente de volta pro trabalho.

Pense num gerente de projeto robótico que nunca dorme, nunca aceita “tá bom o suficiente” e tem paciência infinita para mandar refazer.

Os números que ninguém quer aceitar

Um estudo do MIT de 2026 jogou um balde de água fria na euforia dos loops: agentes de IA aumentaram o volume de código escrito em 180% — mas o código que efetivamente chegou a produção subiu apenas 30%.

Ou seja: as máquinas estão produzindo 6x mais código do que antes, mas 5 dessas 6 partes são descartadas, retrabalhadas ou simplesmente nunca fazem merge.

Enquanto isso, a Anthropic reportou que mais de 80% do código merged nos repositórios internos é escrito por IA. O Google está em ~75%. Esses números são reais. A migração já aconteceu.

A pergunta que Ronacher levanta não é “devemos usar IA para código?” — isso já foi decidido. A pergunta é: quando 80% do código é escrito por máquinas rodando em loops autônomos, quem realmente entende o que esse código faz?

O problema do código “medroso”

Aqui Ronacher destaca algo que qualquer dev que usa IA já percebeu, mas poucos verbalizam tão bem.

Modelos de linguagem são mortalmente aterrrorizados por exceções. Quando um agente em loop encontra um teste falhando por conta de uma edge case, ele não redesenha a solução. Ele adiciona um try/catch. Depois outro. Depois um fallback. Depois uma validação redundante.

O resultado é código que funciona — tecnicamente. Mas que é:

• Defensivo demais: cada função tem 3 camadas de validação que nunca serão atingidas
• Localmente racional, globalmente caótico: cada trecho faz sentido isolado, mas o sistema todo é um frankenstein
• Invariantes fracos: ao invés de tornar estados inválidos impossíveis de representar, o código simplesmente checa e ignora
• Duplicado: o agente não tem a visão macro do codebase, então reimplementa o que já existe em outro módulo

# O que um humano escreveria
def process_payment(amount: Decimal) -> Receipt:
    assert amount > 0, "Amount must be positive"
    return gateway.charge(amount)

# O que o loop de IA produz
def process_payment(amount):
    try:
        if amount is None:
            logger.warning("Amount is None, returning empty receipt")
            return Receipt.empty()
        if not isinstance(amount, (int, float, Decimal)):
            logger.warning(f"Invalid amount type: {type(amount)}")
            return Receipt.empty()
        amount = Decimal(str(amount))
        if amount <= 0:
            logger.warning(f"Non-positive amount: {amount}")
            return Receipt.empty()
        try:
            result = gateway.charge(amount)
            if result is None:
                logger.error("Gateway returned None")
                return Receipt.empty()
            return result
        except GatewayError as e:
            logger.error(f"Gateway error: {e}")
            return Receipt.empty()
        except Exception as e:
            logger.error(f"Unexpected error: {e}")
            return Receipt.empty()
    except Exception as e:
        logger.critical(f"Critical error in process_payment: {e}")
        return Receipt.empty()

Exagero? Nem tanto. Eu já vi loops gerarem código com 4 níveis de try/except aninhados onde bastava um assert.

Ronacher chama isso de “fazer fallback ao invés de tornar estados ruins impossíveis”. É a antítese de boa engenharia de software — mas é exatamente o que um loop de IA incentiva, porque o critério de sucesso do harness geralmente é “os testes passaram”, não “o código é elegante e manutenível”.

Onde loops funcionam (e funcionam muito bem)

Seria desonesto não reconhecer que loops autônomos já produziram resultados impressionantes. Ronacher lista vários cenários onde o padrão funciona:

Migração de código — o caso mais emblemático é a reescrita do Bun de Zig para Rust. 960 mil linhas de código portadas em 6 dias por agentes em loop. O tipo de trabalho mecânico, repetitivo, com testes claros de sucesso (compila? passa nos testes? mesma saída?) é perfeito pra loops.

Exploração de performance — rodar benchmarks, testar otimizações, medir impacto. O loop gera uma variante, roda o benchmark, compara, e itera. Não precisa de julgamento estético sobre o código.

Scanning de segurança — pesquisa de vulnerabilidades onde o critério é binário (encontrou ou não encontrou). A Anthropic mesmo já soltou agentes em 1.000 projetos open source e encontrou 6.202 bugs críticos usando exatamente esse padrão.

Provas de conceito — código que vai ser jogado fora. Se o objetivo é validar uma ideia rapidamente, a qualidade do código é irrelevante. Loops são perfeitos pra isso.

O padrão é claro: loops brilham quando o artefato é temporário ou quando o critério de sucesso é verificável mecanicamente. Quando o código precisa durar anos e ser mantido por humanos… é aí que a coisa desanda.

Software como organismo vs. software como máquina

Essa talvez seja a reflexão mais profunda do texto de Ronacher. Historicamente, engenharia de software era sobre entender a máquina. Invariantes claros, documentação, arquitetura intencional. Você podia abrir qualquer módulo e entender o que ele fazia e por quê.

Ronacher argumenta que estamos migrando de software-como-máquina para software-como-organismo. Um sistema que cresce, muta, se adapta — mas que ninguém mais compreende por inteiro. Quando algo quebra, você não debugga. Você joga pra outra IA diagnosticar.

Codebases estão se tornando “organismos obscuros e confusos que só podem ser diagnosticados por mais máquinas.”

Isso já está acontecendo. Times inteiros mergem PRs que foram escritas, testadas e revisadas por agentes. O humano faz um code review superficial — porque, sejamos honestos, quem vai ler 2.000 linhas de diff gerado por máquina com o mesmo cuidado que leria 200 linhas de um colega?

O resultado prático: estamos construindo sistemas que dependem de máquinas para serem compreendidos. E se amanhã o acesso a esses modelos ficar mais caro, for restringido por regulação, ou simplesmente sair do ar?

A armadilha da dependência cognitiva

Esse ponto do Ronacher me parece o mais subestimado. Ele lista cenários que poucos estão discutindo:

Restrições comerciais: se o seu time depende de Claude ou GPT rodando em loops para entender o próprio codebase, o que acontece se a Anthropic ou OpenAI mudar os termos de uso? Ou se o preço subir 10x?

Sanções e regulação: modelos de IA são controlados pelas mesmas regras de exportação que chips. Hoje o DeepSeek é acessível. Amanhã pode não ser.

Perda de habilidade: se durante 3 anos ninguém no time leu realmente o código — só revisou outputs de agentes — alguém ainda sabe como o sistema funciona? Ou a empresa inteira virou refém de um serviço terceirizado de IA?

É como depender do Google Maps pra ir ao supermercado. Funciona perfeitamente… até o GPS cair. E aí você descobre que não sabe nem em que rua mora.

A pressão competitiva que torna isso inevitável

Aqui está o ponto que torna o texto de Ronacher diferente dos típicos artigos “IA vai destruir tudo”. Ele não é um luddita. Ele reconhece que não adotar loops é suicídio competitivo.

Times pequenos com harness loops bem configurados estão entregando o volume de código de times 5x maiores. Se seu concorrente automatizou o ciclo inteiro de feature → testes → deploy com loops, e você ainda está fazendo code review manual de cada PR… boa sorte.

O exemplo do Daniel Stenberg com o curl é perfeito. O mantenedor do curl — a biblioteca mais instalada do mundo, presente em literalmente bilhões de dispositivos — publicou um desabafo sobre a avalanche de reports gerados por IA. Pessoas rodando loops de scanning de segurança e jogando os resultados sem filtro. O volume de “falsos positivos inteligentes” é tão alto que o trabalho de manutenção ficou insustentável.

E o problema vai dos dois lados: se atacantes usam loops pra encontrar vulnerabilidades (e já usam), defensores precisam de loops equivalentes. Você não traz uma faca pra uma guerra de drones.

Loop Engineering: a nova disciplina

O que antes era “prompt engineering” está se transformando em algo fundamentalmente diferente. Já tem gente chamando de loop engineering — a arte de projetar harnesses que:

1. Definem critérios claros de sucesso/falha
2. Injetam contexto adequado no agente a cada iteração
3. Sabem quando parar (evitando loops infinitos que geram lixo)
4. Preservam artefatos intermediários para debug
5. Escalam horizontalmente (múltiplos agentes em paralelo)

# Exemplo simplificado de um harness loop
while true; do
  # Agente tenta implementar a feature
  claude-code --task "$TASK" --output /tmp/result

  # Harness avalia
  if make test && make lint && check_coverage > 80; then
    echo "Done. Creating PR."
    gh pr create --title "$TASK" --body "$(cat /tmp/result/summary.md)"
    break
  fi

  # Falhou: injeta feedback e recomeça
  TASK="$TASK\n\nPrevious attempt failed:\n$(cat /tmp/result/errors.log)"
done

Claro que na prática é mais sofisticado — mas a essência é essa. Um loop que não desiste até que critérios objetivos sejam atingidos.

A questão que Ronacher levanta: se o harness mede “testes passam + lint ok + coverage > 80%”, e tudo isso é atingido com código defensivo cheio de fallbacks… o loop vai declarar vitória. Mesmo que o código resultante seja um pesadelo de manutenção.

Os critérios do harness definem a qualidade do output. E a maioria dos harnesses hoje tem critérios mecânicos, não qualitativos.

O que fazer: a proposta de Ronacher

Ronacher não propõe abandonar loops (impossível). Ele propõe uma postura diferente:

Manter o julgamento humano no circuito — não como revisor passivo de PRs gigantes, mas como arquiteto que define as restrições do harness. O humano não escreve o código, mas define as invariantes que o código deve respeitar.

Preservar legibilidade como critério — se o harness não avalia legibilidade, adicione essa avaliação. Use um segundo agente para revisar se o código gerado é compreensível. Sim, máquinas revisando máquinas. Mas pelo menos com o critério certo.

Tratar código de loop como temporário — se o artefato vai viver mais de 6 meses, um humano precisa realmente entender e aprovar cada linha. Loops pra PoCs e migrações. Humanos pra arquitetura e APIs públicas.

Investir em compreensão, não só em produção — o fato de que 80% do código é escrito por IA não significa que 80% da compreensão pode ser delegada. Alguém precisa saber como o sistema funciona. Se não sabe, a empresa tem uma dívida técnica invisível que vai cobrar juros compostos.

E se Ronacher estiver errado?

O cenário otimista: modelos ficam tão bons que o código gerado por loops é indistinguível do código humano de alta qualidade. Os harnesses evoluem pra medir não só “funciona?” mas “é elegante, manutenível e idiomático?”. A dependência cognitiva não é problema porque a IA está sempre disponível e acessível.

Pode acontecer. Mas apostar a infraestrutura inteira da sua empresa nesse cenário otimista é como construir uma casa sem seguro contra incêndio porque “provavelmente não vai pegar fogo”.

O texto de Ronacher é um alerta — não contra IA, mas contra a preguiça intelectual de aceitar loops sem pensar nas consequências. De mergear sem entender. De delegar não só a escrita, mas a compreensão do que foi escrito.

A loop está chegando. A questão é se você vai ser o engenheiro que controla o harness, ou o dev que foi substituído por ele.

—

Fonte de inspiração: The Coming Loop — Armin Ronacher