É o mesmo modelo. Aquele que alucinava no chat web agora sobe uma funcionalidade de 200 linhas de uma vez no Claude Code. O /goal do Codex resolve uma issue inteira. O modelo não ficou mais inteligente de repente. O que mudou foi a estrutura.
Por que funciona
O loop da IA conversacional é este:
LLM → pessoa → LLM → pessoa
Todo o feedback é linguagem natural. Uma geração probabilística seguida de uma avaliação probabilística. A precisão se degrada multiplicativamente.
O loop do agente de codificação é diferente:
LLM → geração de código → salvar arquivo → executar testes → pass/fail → LLM
LLM → modificação de código → build → sucesso/falha → LLM
LLM → type check → mensagem de erro → LLM
Há gates determinísticos dentro do loop. O sistema de arquivos salva exatamente o que foi escrito. O teste é pass ou fail. O compilador diz que está errado quando está errado. Esses mecanismos funcionam inadvertidamente como um ratchet.
O LLM é um unreliable component. Mas construir um reliable protocol sobre um unreliable component é engenharia básica. O TCP cria reliable delivery sobre uma unreliable network. O RAID cria reliable storage sobre unreliable disks. O ECC cria reliable computation sobre unreliable memory.
A razão pela qual o agente de codificação funciona é a mesma. Porque colocou deterministic verifiers (testes, build, linter, type checker) sobre um unreliable LLM. Não é a performance do modelo — é a topology que causa o sucesso.
Mas então por que quebra?
Eu disse que funciona. Mas às vezes quebra. Por quê?
Porque existe uma diferença entre um ratchet que aparece por acidente e um que é projetado conscientemente.
Existem trechos sem ratchet
O que acontece quando o agente modifica código sem testes? O build passa, o lint passa, mas a funcionalidade está quebrada. Em trechos onde não há gate determinístico, o LLM julga probabilisticamente, e o julgamento probabilístico se degrada multiplicativamente.
De 200 endpoints, 180 têm testes e 20 não têm. O agente processa os 180 perfeitamente e planta bugs silenciosamente nos 20. É por isso que surge a sensação de “quase pronto, mas algo está estranho”.
A quantidade de informação no feedback é insuficiente
Fiz um experimento de ordenar 1000 palavras. A CPU fez em 0,08ms com 100%. O LLM levou 438 segundos com 97,7%. Isso por si só é impressionante — 97,7% por cognição pura. Mas a verdadeira descoberta estava em outro lugar.
Variei apenas o nível de feedback para o mesmo resultado:
| Feedback | Resultado |
|---|---|
| Nenhum | 6 erros (99,4%) |
| “Há erros” | 10 erros (99,0%) — piorou |
| “Há 23 erros” | 1 erro (99,9%) |
| “6, estão aqui” | 0 erros (100%) |
Se você apenas diz “está errado”, a sobre-correção piora as coisas. Se informa a quantidade de erros, surge um objetivo e o modelo busca persistentemente. Se indica a localização, corrige perfeitamente.
A maioria dos agentes atuais está no segundo nível. Quando um teste falha, eles sabem que “algo está errado”, mas não transmitem a razão estrutural de por que está errado. Mensagens de erro existem, mas são sintomas, não causas.
Existem pontos cegos, e a repetição não os resolve
No experimento de ordenação, o LLM deixou 6 erros em R2. Em R3, reportou “sem erros”. Em R4b, também reportou “sem erros”. Perdeu os mesmos 6 da mesma maneira.
Sem dicas, convergiu em 99,4% não importa quantas repetições. Quando informei “restam 6”, finalmente alcançou 100%.
O mesmo acontece com agentes de codificação. O agente cria um bug, faz self-review e julga “sem problemas”, e mesmo quando pedimos para corrigir novamente, perde o mesmo ponto. É por isso que retry não é solução. O ponto cego é uma limitação estrutural que vem da natureza probabilística do modelo, não falta de esforço.
Na escala, a multiplicação age
Encadeie duas etapas com 97,7% de precisão: 0,977² = 95,4%. Três vezes: 93,2%. Dez vezes: 79,2%.
O agente modifica bem um único arquivo. Mas e uma refatoração em 100 arquivos? Mesmo que cada etapa tenha 97%, após 100 etapas: 0,97¹⁰⁰ = 4,8%. O fracasso é praticamente garantido.
Esta é a explicação matemática de “vibe coding quebra em 200 endpoints”. Em projetos pequenos, o número de encadeamentos é baixo e a probabilidade aguenta. Em projetos grandes, a multiplicação age de forma devastadora.
O que é necessário
A razão de funcionar e a razão de quebrar apontam para o mesmo lugar: a presença ou ausência de gates de verificação determinísticos.
Os agentes atuais dependem de ratchets que apareceram por acidente (testes, build, linter). Se projetarmos isso conscientemente, ficam mais fortes.
Projetar ratchets conscientemente significa:
Primeiro, identificar trechos sem ratchet. Código sem testes, APIs sem schema, dados sem tipos. Todo lugar onde o agente julga probabilisticamente é um ponto vulnerável.
Segundo, aumentar a quantidade de informação no feedback. Retornar apenas pass/fail provoca sobre-correção. É preciso estruturar e transmitir “onde, por que, e o que difere do esperado”.
Terceiro, inserir gates determinísticos entre os encadeamentos. Se rodar 10 etapas de uma vez, a multiplicação é devastadora, mas se fixar com um ratchet a cada etapa, a degradação é resetada.
O LLM é um gerador impressionante. Ordena 1000 palavras com 97,7% de precisão por puro raciocínio. Algo que nem humanos conseguem. Mas tudo que não é 100% desmorona na repetição. 0,977 ao quadrado é 0,954.
O agente de codificação funciona não porque o modelo é inteligente. Funciona porque há gates determinísticos dentro do loop. Quebra porque esses gates estão ausentes.
A geração pode ser probabilística. A verificação deve ser determinística.
Artigos relacionados
- Ratchet Pattern — Como fazer agentes terminarem o trabalho — Estrutura e princípios do padrão ratchet
- QI do modelo importa menos que a topologia do feedback — A estrutura do feedback determina o desempenho
- Restrições são contratos — Restrições racionais libertam os sistemas
- filefunc — Um arquivo, um conceito — Estrutura de código nativa para LLM
- Pensamento AI a partir de primeiros princípios — Como pensar com IA