Um dos ensaios mais lúcidos de 2026 — 'The Coming Loop', de Armin Ronacher — argumenta que harnesses externos vão manter agentes trabalhando muito além do ponto em que diriam 'terminei'. Ele acerta o diagnóstico e erra a unidade de análise. O perigo não está no loop que gera código. Está no gate por onde esse código entra na sua infraestrutura sem que ninguém responsável consiga explicá-lo.
Ronacher move o eixo da discussão do 'agente melhor' para a orquestração. Está certo. Mas conclui pela inevitabilidade do loop quando deveria concluir pelo desenho do gate.
A tese de Ronacher é precisa em três pontos. Primeiro: o próximo salto não é o modelo, é o harness externo — a fila, a máquina que tenta, o sistema que decide se continua, injeta contexto ou escala. Segundo: o modo de falha atual não é o erro, é a compreensibilidade — modelos têm 'pavor mortal de exceções' e empilham defesas locais que deixam o sistema mais robusto na aparência e menos legível na essência. Terceiro: há um risco real de dependência — 'pessoas cada vez mais dão merge em código que não conseguem explicar'.
O deslize é tratar como propriedade do paradigma o que é propriedade do momento. 'Pavor de exceções' é uma falha do nível de capacidade atual, não do loop. E 'inevitável' faz trabalho pesado demais: prova que alguém vai fazer loop em algum domínio — não que você deva fazê-lo no código que sustenta seu negócio.
Reposicionado: o loop é só uma bomba de geração. O que determina se ele constrói ou destrói valor é o portão de controle entre o que a máquina produz e o que entra em produção. A pergunta de engenharia não é 'vamos fazer loop?' — é 'como projetamos o gate?'.
O loop não é a unidade de risco. O gate é.
— Tese Stickybit, em releitura de 'The Coming Loop' (A. Ronacher, jun/2026)
Todo agente já tem um loop interno (lê, edita, testa). O harness adiciona um loop externo que mantém a tarefa viva. Entre o que sai do loop e o que entra no sistema há um único ponto que decide tudo — o gate.
O agente lê, edita, roda testes. Já existe hoje.
Fila, retry, injeção de contexto, escalonamento. Mantém a tarefa viva além do 'terminei'.
O ponto onde código entra em produção. Se ele só checa 'compila e passa', a dívida de compreensão entra junto. É aqui que se ganha ou se perde.
Infraestrutura duradoura, que alguém terá de manter.
A parte mais acionável do ensaio é a fronteira que ele desenha. Loops brilham onde o artefato é temporário ou verificável por máquina. Acumulam dívida onde o artefato é infraestrutura que humanos vão manter por anos.
Tradução mecanicamente verificável: a saída ou compila e passa nos testes, ou não.
Achados são checáveis; o artefato é um relatório, não código permanente.
Benchmark é o juiz. O loop propõe, a medição decide.
O valor é o aprendizado, não o código que sobrevive.
Código que dezenas de pessoas vão ler e alterar por anos. Compreensibilidade é o ativo.
Onde um estado inválido custa caro e a verificação não é mecânica.
Se 'correto' não é verificável barato, o loop só multiplica ambiguidade.
O critério — A fronteira não é 'loop sim ou não'. É: o gate consegue verificar esta saída de forma barata e confiável? Se sim, soltar o loop. Se não, o humano é o gate — e isso precisa ser desenhado, não improvisado.
O próprio exemplo do curl, citado por Ronacher, derruba a leitura ingênua de 'loops são ótimos onde há verificação'. O loop do atacante/reporter é barato. A verificação do mantenedor é cara. O loop não democratiza — ele transfere custo para quem revisa.
Tokens caem de preço, paralelizável, roda a noite toda. O custo marginal de mais uma tentativa tende a zero.
Exige atenção humana — o recurso mais escasso. Cada PWR não-trivial consome o tempo do engenheiro que entende o sistema.
Soltar o loop sem dimensionar o gate é mover o gargalo, não eliminá-lo — e estourar o orçamento de atenção (e de tokens) da equipe. O gasto com IA explodindo nas engenharias em 2026 é exatamente esse erro em escala.
Se o gate é a unidade de risco, ele é também a unidade de projeto. Não é um checklist — é arquitetura. Quatro princípios que aplicamos, conectados ao que já publicamos.
Quebrar o trabalho em fases cujo entregável é spot-checkável em minutos: diffs pequenos, com citações e testes que o humano valida sem reler tudo. O loop roda dentro da fase; o gate vive na costura entre fases.
Ver Frontier OperationsSeparar prompt, contexto recuperado e dados de execução em zonas distintas — para que código gerado por máquina não atravesse para produção sem um portão que valide proveniência e intenção.
Ver Trust ArchitectureDecidir, por domínio e por release, o que o agente faz sozinho e o que exige humano no loop — e recalibrar quando a capacidade do modelo move a fronteira. Gate fixo apodrece; gate calibrado dura.
Ver Frontier OperationsTriagem em camadas: automático (testes), revisão humana (caminhos críticos), engajamento profundo (arquitetura). Gastar atenção onde a verificação é cara e barata onde a máquina já é confiável.
Ver Agent Control PlaneProjetamos o portão de controle do seu fluxo agêntico: o que o loop pode mergear sozinho, o que para no humano e como cada saída é verificada barato.
Liberamos automação total onde o artefato é verificável ou descartável — migração, varredura, exploração — e contemos onde é infraestrutura duradoura.
Nenhum merge que ninguém consiga explicar. Mantemos a compreensão humana como pré-requisito — o seguro contra o código que só a máquina sustenta.
Fontes desta releitura crítica.
Ensaio-base: loops de harness externo, o modo de falha de compreensibilidade e o risco de dependência de máquina.
Bifurcação social ('agent goes brrr' vs. revisores exaustos) e o contraponto empírico do loop com fase de review rigorosa.
Caso citado por Ronacher: a assimetria de custo entre gerar (barato) e verificar (caro) na prática.
Evidência de que soltar o loop sem dimensionar custo (tokens + atenção) estoura orçamentos em escala.
A questão não é se sua equipe vai usar agentes em loop. É se existe um portão de controle desenhado entre o que a máquina gera e o que entra em produção. A Stickybit projeta esse gate. Vamos conversar.