Por que o seu agente nunca para

Por que o seu agente nunca para Image: AI generated

A gabarolice do 24/7

“Estou rodando o agente 24 horas por dia.”

É uma frase que se vê com frequência no X. Como se quanto mais tempo o agente rodasse, mais trabalho ele fizesse. Como se uma pessoa fosse mais produtiva por não dormir.

Mas diante dessa frase a sensação não é admiração e sim dúvida.

“Por que ainda não terminou?”

Um sistema que consegue parar é um sistema saudável

Deleguei a um agente a tarefa de escrever testes para 527 funções. Resultado:

Agente autônomo:  declara "está pronto" após 40 / 527 concluídas
Loop de CLI:      encerra após percorrer 527 / 527

O loop de CLI levou 1 hora. Não 24 horas. Processa uma função, verifica, se passa avança para a próxima, e quando tudo termina, para. O cerne desse loop não é a velocidade, mas o fato de que a condição de término está definida mecanicamente.

TODO → escreve teste → mede cobertura → PASS/DONE → próxima → ... → tudo concluído → para

finite. measurable. monotonic. Por isso converge. Por isso para.

Conseguir parar não é uma fraqueza. Significa estar saudável.

As três razões para não parar

Quando um agente roda por muito tempo, normalmente é por uma de três razões.

1. O verificador é fraco

"looks good"
"seems better"
"more scalable"
"clean architecture"

Coisas assim não são critérios de convergência. São julgamentos subjetivos. go test devolve pass/fail, mas “clean architecture”, quem julga? Outro LLM? Isso é perguntar a um amigo bêbado “eu estou bêbado?”.

A evidência empírica sustenta isso. Juízes LLM para avaliação de código se enviesam até diante de variações superficiais de código semanticamente idêntico, inflando ou cortando injustamente as notas (Moon et al. 2025), e os modelos dobram a própria resposta para concordar em 58,19% dos casos (SycEval, Fanous et al. 2025). “looks good” não tem relação com correção. Além disso, critérios fracos não param por aí — quando a medição vira meta, a medição se quebra (lei de Goodhart; Manheim & Garrabrant 2018), e modelos de raciocínio capazes, em vez de resolver a tarefa de frente, hackeiam o próprio procedimento de verificação (Bondarenko et al. 2025).

Sem critério de convergência, não há fim.

2. Não há fronteira de tarefa

"melhore a base de código"
"deixe a arquitetura mais limpa"
"continue otimizando"

São tarefas sem condição de término. Até um desenvolvedor humano se perde sem fim com objetivos assim. Com o agente não é diferente. “Melhorar” é uma direção, não um destino.

3. A entropia supera a velocidade de correção

É o padrão mais comum e mais traiçoeiro.

Ao fazer alterações, o agente adiciona abstrações. Insere indireções. Cria generalizações desnecessárias. O código parece “ficar melhor”, mas na prática a nova entropia cresce mais rápido do que o verificador a remove.

a abstração criada hoje → é removida de novo amanhã → e adicionada de novo depois de amanhã

Isto é otimização não monotônica (non-monotonic optimization). Parece ir para frente, mas está parado no lugar. Parece uma máquina de movimento perpétuo, mas só consome energia. E aqui a energia são tokens.

Estudos empíricos de larga escala capturam esse drift. A adoção do Cursor elevou a velocidade de curto prazo, mas os avisos de análise estática e a complexidade do código cresceram continuamente, e esse acúmulo foi a principal causa da desaceleração de longo prazo (He et al. 2025, 807 repositórios open-source). Em mais de 300 mil commits escritos por IA, 22,7% dos problemas introduzidos sobreviveram como dívida técnica até a versão mais recente (Liu et al. 2026). A correção não acompanha a entropia.

Não é um problema de busca, é um problema de satisfação de restrições

É aqui que aparece a diferença fundamental de perspectiva.

“Rodar o agente por mais tempo gera um resultado melhor” é um olhar que vê a engenharia de software como um problema de busca (search problem). A expectativa de que, ao explorar por muito tempo um espaço amplo, se encontre uma solução melhor.

Mas a engenharia de software é, em essência, um problema de satisfação de restrições (constraint satisfaction problem).

os tipos têm de bater
os testes têm de passar
a cobertura tem de ser atendida
o schema tem de coincidir
as regras de lint têm de ser respeitadas

Quando todas essas restrições são satisfeitas, acabou. Não há necessidade de “explorar mais”. Definir as restrições, satisfazê-las e parar. É só isso.

Código já é um domínio verificável por máquina (machine-checkable domain). Compilador, type checker, testes, cobertura, linter, validação de schema — tudo isso são verificadores determinísticos. Se esses verificadores existem, por que fazer o agente explorar sem fim?

A pesquisa em aprendizado aponta na mesma direção. Quando se usa um verificador determinístico, como testes unitários, como recompensa — uma recompensa verificável (verifiable reward) —, a correção do código fica maior do que com geração aberta (CodeRL, Le et al. 2022; RLTF, Liu et al. 2023). O verificador não é uma ferramenta para estreitar a busca. É a evidência de que, desde o início, este problema não é busca, mas satisfação.

As condições de um bom loop

Um bom loop de agente se fecha em cinco etapas:

1. Definir a tarefa  — o que deve ser alcançado (meta julgável mecanicamente)
2. Limitar o escopo  — uma unidade por vez (função, endpoint, arquivo)
3. Verificação simbólica — uma ferramenta determinística decide pass/fail
4. Convergência      — se passa, próxima; se falha, retenta com feedback
5. Término           — se não restam itens, para

Nessa estrutura, o LLM cuida apenas da etapa 3 (geração). Todo o resto é feito pela máquina. Em especial, o cerne é que a “máquina decide o ‘fim’”. Se você deixar o julgamento de término a cargo do LLM, vai ouvir um “está pronto” em 40/527.

Os experimentos apontam na mesma direção. Quando se acopla autocrítica (self-critique) ao LLM, o desempenho em tarefas de raciocínio e planejamento na verdade desaba, e só melhora muito quando se acopla um verificador externo sólido (Stechly et al. 2024). A autocorreção intrínseca sem feedback externo falha ou, às vezes, piora após a correção (Huang et al. 2023). Há razão para não deixar o término a cargo do LLM.

creative writing e código são coisas diferentes

Há uma exceção. Nem todo domínio é assim.

Escrita, marketing, design — nesses domínios o verificador é fraco. Não dá para julgar mecanicamente “esta frase é boa?”. Nesses domínios uma busca longa pode fazer sentido. O modo em que o agente gera várias variações e a pessoa escolhe.

Mas código é diferente. Código já é um mundo repleto de verificadores determinísticos. Nesse mundo, vagar (wandering) por longas horas não é busca, é deriva (drift).

A pergunta

Há quantas horas o seu agente está rodando agora?

Ele está convergindo, ou está à deriva?

Ele consegue parar?

Se consegue parar, por que ainda não parou?

Leituras adicionais (externas)

Designing agentic loops — Simon Willison. É preciso ter critérios claros de sucesso e uma suíte de testes que passe para que o loop do agente se autoverifique e pare — o par construtivo deste texto.
Building Effective Agents — Anthropic. A razão de a codificação ser ideal para agentes é que a solução é verificável por testes automatizados — o verificador determinístico vira o sinal de parada.
Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. A decisão de design central não é um modelo melhor, e sim uma condição de término mensurável, alertando para o “confidence laundering” em que uma saída fluente esconde a não convergência.
Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. A confiabilidade não vem do modelo, mas de um harness de ferramentas determinísticas (computational controls) — distinto do controle inferencial baseado em IA.
Reward Hacking in Reinforcement Learning — Lilian Weng. “Quando a medição vira meta, deixa de ser uma boa medição” — uma síntese técnica do mecanismo de gaming do proxy quando se usa um verificador fraco como recompensa.
Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. Quanto mais tokens de entrada se acumulam, mais a saída se degrada — a causa mecânica de um loop que adiciona, remove e readiciona se tornar não autocorreção, mas autorreforço.
Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. A IA amplifica o rigor existente — uma perspectiva prática do fenômeno em que, com baixo rigor, ela acelera o caos e a entropia ultrapassa a correção.

Fontes

Julgamento de término · limites da autoverificação

Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · falta de confiabilidade da autocrítica

Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

Drift · aumento da complexidade do código de IA

He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

Recompensa verificável · geração de código baseada em verificador

Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

Reward hacking · specification gaming

Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)