Image: AI generated
O mesmo modelo. O que alucinava no chat web entrega uma funcionalidade de 200 linhas no Claude Code de primeira. O /goal do Codex resolve uma issue inteira. O modelo não ficou inteligente de repente. O que mudou é a estrutura.
Por que funcionam
O loop da IA conversacional é assim:
LLM → humano → LLM → humano
Todo feedback é linguagem natural. Geração probabilística seguida de avaliação probabilística. A precisão degrada como produto.
O loop dos agentes de codificação é diferente:
LLM → geração de código → salvar arquivo → executar teste → pass/fail → LLM
LLM → edição de código → build → sucesso/falha → LLM
LLM → type check → mensagem de erro → LLM
Portões determinísticos estão dentro do loop. O sistema de arquivos salva exatamente o que foi escrito. Um teste é pass ou fail. O compilador diz errado quando está errado. Esses inadvertidamente servem como ratchets.
Um LLM é um componente não confiável. Mas construir um protocolo confiável sobre componentes não confiáveis é um fundamento da engenharia. Von Neumann provou matematicamente em 1956 que apenas com votação por maioria, componentes ruidosos podem realizar computação confiável (Von Neumann, 1956). TCP constrói entrega confiável sobre uma rede não confiável. RAID constrói armazenamento confiável sobre discos não confiáveis. ECC constrói computação confiável sobre memória não confiável.
A razão pela qual agentes de codificação funcionam é a mesma. Um LLM não confiável é complementado com verificadores determinísticos (testes, builds, linters, type checkers). O estudo SWE-agent demonstrou que até o mesmo modelo mostra desempenho dramaticamente diferente dependendo do design da Agent-Computer Interface (Yang et al., NeurIPS 2024). É a topologia, não a capacidade do modelo, que causa o sucesso.
Mas por que quebram?
Funcionam, eu disse. Mas às vezes quebram. Por quê?
Porque ratchets que estão presentes por acaso e ratchets conscientemente projetados são coisas diferentes.
Existem zonas sem ratchet
Quando um agente edita código sem testes? O build passa, lint passa, mas a funcionalidade está quebrada. Em zonas sem portões determinísticos, o LLM julga probabilisticamente, e julgamentos probabilísticos degradam como produto.
De 200 endpoints, 180 têm testes e 20 não. O agente lida com 180 perfeitamente e planta bugs silenciosamente nos 20. Por isso você obtém “quase pronto, mas algo está errado.”
A informação do feedback é insuficiente
Fiz um experimento de ordenação com 1.000 palavras. CPU: 0,08ms a 100%. LLM: 438 segundos a 97,7%. Isso por si só é notável — 97,7% por cognição pura. Mas a verdadeira descoberta estava em outro lugar.
Variei apenas o nível de feedback sobre o mesmo resultado:
| Feedback | Resultado |
|---|---|
| Nenhum | 6 erros (99,4%) |
| “Há erros” | 10 erros (99,0%) — pior |
| “Há 23 erros” | 1 erro (99,9%) |
| “6 erros, aqui estão” | 0 erros (100%) |
Dizer apenas “você está errado” causa sobrecorreção e piora as coisas. Dar uma contagem cria um alvo para perseguir. Dar localizações alcança a perfeição.
A maioria dos agentes hoje opera no segundo nível. Quando um teste falha, sabem “algo está errado”, mas não transmitem a razão estrutural. Mensagens de erro existem, mas são sintomas, não causas.
Pontos cegos existem e repetição não os corrige
No experimento de ordenação, o LLM deixou 6 erros no R2. No R3, reportou “sem erros.” No R4b, reportou novamente “sem erros.” Perdeu os mesmos 6 da mesma maneira.
Sem dicas, não importa quantas repetições, convergiu em 99,4%. Só quando disse “restam 6” finalmente alcançou 100%.
O mesmo acontece com agentes de codificação. O agente cria um bug, auto-revisa com “parece bom”, e quando mandado corrigir novamente, perde o mesmo ponto. Huang et al. (2024) mostraram que sem feedback externo, LLMs autocorrigindo seus erros de raciocínio na verdade degrada o desempenho (Huang et al., ICLR 2024). Por isso retry não é a resposta. Pontos cegos são uma limitação estrutural da natureza probabilística do modelo, não falta de esforço.
Multiplicação funciona em escala
97,7% de precisão encadeada duas vezes: 0,977² = 95,4%. Três vezes: 93,2%. Dez vezes: 79,2%.
Um agente editando um único arquivo se sai bem. Mas pedir para refatorar 100 arquivos? Mesmo a 97% por passo, 100 passos dão 0,97¹⁰⁰ = 4,8%. Falha é virtualmente garantida.
Esta é a explicação matemática para “vibe coding quebra em 200 endpoints.” Em projetos pequenos, o número de encadeamentos é baixo o suficiente para a probabilidade aguentar. Em projetos grandes, a multiplicação se torna catastrófica.
O que é necessário
As razões para funcionar e as razões para quebrar apontam para o mesmo lugar: a presença ou ausência de portões de verificação determinística.
Agentes atuais dependem de ratchets que estão presentes por acaso (testes, builds, linters). Projetá-los conscientemente os torna mais fortes.
O que significa projetar ratchets conscientemente:
Primeiro, identificar zonas sem ratchet. Código sem testes, APIs sem schemas, dados sem tipos. Todo lugar onde o agente julga probabilisticamente é uma vulnerabilidade.
Segundo, aumentar o conteúdo informativo do feedback. Retornar apenas pass/fail induz sobrecorreção. “Onde, por que e como o real difere do esperado” deve ser entregue de forma estruturada.
Terceiro, inserir portões determinísticos entre etapas de encadeamento. Rodar 10 etapas de uma vez torna a multiplicação catastrófica, mas travar com ratchet a cada etapa reseta a degradação.
LLMs são geradores notáveis. Ordenam 1.000 palavras a 97,7% de precisão por cognição pura. Humanos não conseguem fazer isso. Mas qualquer coisa menos de 100% colapsa sob repetição. 0,977 ao quadrado é 0,954.
Agentes de codificação funcionam não porque o modelo é inteligente. Funcionam porque portões determinísticos estão dentro do loop. Quebram porque esses portões estão ausentes.
Geração pode ser probabilística. Verificação deve ser determinística.
Artigos relacionados
- Ratchet Pattern — Como fazer um agente terminar o trabalho — A estrutura e princípios do padrão ratchet
- Topologia de Feedback Importa Mais que o QI do Modelo — Por que a estrutura de feedback importa mais que a capacidade do modelo
- Restrições são contratos — Como restrições racionais libertam sistemas
- filefunc — Um arquivo, um conceito — Estrutura de código nativa para LLM
- Pensamento AI: 5 passos para quebrar premissas com primeiros princípios — Como pensar com IA
Referências
- Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
- Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
- Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
- Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
- Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
- Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
- Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
- Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
- Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
- Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
- Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
- Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.
Changelog
- 2026-05-16: Versão inicial