Image: AI generated
Modelos mais inteligentes resolverão tudo?
A narrativa dominante em torno das ferramentas de codificação com IA é esta: quando o modelo for bom o suficiente, ele escreverá código, escreverá testes e fará refatoração sozinho. Se o GPT-4 não conseguiu, o GPT-5 conseguirá. Se o Claude ficou aquém, um Claude maior dará conta.
Isso é realmente verdade?
Encarreguei o Claude Opus 4.7 com uma refatoração do filefunc. Ele terminou em uma hora sem revisão humana. validate passou, pytest passou, cobertura mantida. Na superfície, isso se encaixa na narrativa do “basta conseguir um modelo melhor”.
Mas e se você der ao mesmo modelo a mesma refatoração sem as regras do filefunc? Sem validate? Sem feedback de cobertura? O resultado é completamente diferente. Ele cai em um doom loop — corrigir um bug quebra outro lugar, corrigir esse quebra mais outro.
O mesmo modelo. O que mudou é o ambiente.
“Pronto” — O instinto de terminação prematura do agente
Outro experimento com o mesmo modelo. Soltei um agente em um projeto com 527 funções. “Escreva testes para cada função.” O agente terminou e reportou: “Feito.”
Funções que realmente receberam testes: 40. 40 de 527.
O agente não estava mentindo. Fez 40 e decidiu “é suficiente”. A disposição padrão de um LLM é a terminação prematura otimista. Quando encontra uma função difícil, pula, faz mais algumas, e conclui “o resto segue o mesmo padrão, então estamos bem”.
Depois de forçar um loop com uma ferramenta CLI:
Agente autônomo: 40 / 527 (7.6%) — agente declara "pronto"
Loop CLI: 527 / 527 (100%) — máquina declara "faltam 487"
O mesmo modelo. O mesmo projeto. A diferença é quem decide quando está “pronto”.
O ambiente faz o modelo
Ambos os experimentos apontam para a mesma conclusão. O Opus 4.7 não terminou porque era inteligente. Terminou porque a superfície de especificação era verificável por máquina.
filefunc validate → A estrutura do código satisfaz as regras?
pytest → O comportamento existente foi preservado?
coverage → Quais branches estão faltando?
Esses três deram feedback imediato a cada edição. O modelo recebeu o feedback, fez correções, recebeu feedback novamente, corrigiu novamente. Um loop autocorretor.
Aqui está o insight chave:
A topologia de feedback determina os resultados mais do que o QI do modelo.
LLMs são fortes em geração mas fracos em garantir correção. Huang et al. (2024) provaram experimentalmente que quando LLMs tentam autocorrigir seu raciocínio sem feedback externo (oracle feedback), o desempenho pode na verdade degradar. No entanto, quando um verificador determinístico está presente, o desempenho se estabiliza drasticamente. lint, typecheck, test, coverage — estes se tornam o sinal de gradiente que corrige a saída do modelo.
“Será resolvido quando os modelos forem inteligentes o suficiente” é uma proposição falsa. A afirmação precisa é: “Se o feedback for rápido o suficiente, os modelos atuais já podem resolver.”
broad exploration vs local correction
A força dos LLMs não é broad exploration — é local correction.
“Escreva testes para este projeto” — isso é broad exploration. O LLM perde a direção.
“line 41 não está coberta” — isso é local correction. O LLM escreve um teste que cobre exatamente aquela linha.
Números verificados em projetos reais:
Sem feedback: para em 60–70% de cobertura
Com feedback: alcança 100% (para funções alcançáveis)
O mesmo modelo. A simples linha “line 41 not covered” atua como sinal de gradiente. Esse feedback direciona as correções do LLM exatamente na direção certa.
Symbolic Feedback Loop
Uma estrutura percorre todas essas observações.
LLM gera → ferramenta determinística julga → resultado devolvido ao LLM → repetir
Chamo isso de Symbolic Feedback Loop.
O mainstream da indústria hoje é o LLM Feedback Loop — IA verificando IA. É como um bêbado perguntando a um amigo bêbado: “Estou bêbado?” Ambos são probabilísticos, então os erros se acumulam.
O Symbolic Feedback Loop é diferente. Chen et al. (2023) provaram que a depuração iterativa — devolver mensagens de erro do compilador e de tempo de execução ao modelo — melhora dramaticamente a precisão do código. pytest não alucina. go test nunca está bêbado. Medição de cobertura não mente. Verificação de especificação não desvia.
Essa estrutura funciona em domínios onde a correção pode ser julgada mecanicamente — código, testes, especificações, tipos. A elegância do design de APIs ou a naturalidade da UX ainda não podem ser julgadas por ferramentas simbólicas. Expandir essa fronteira é o próximo desafio. Acredito que existe um caminho para trazer até a linguagem natural para dentro de limites verificáveis.
O que o AlphaCode (Li et al., 2022) demonstrou em programação competitiva segue o mesmo princípio. Não foi a capacidade de geração do modelo em si, mas o design do ambiente — gerar milhões de candidatos e filtrar através de testes — que determinou o desempenho. Em vez de tornar o modelo mais inteligente, é mais eficaz tornar mais preciso o feedback devolvido ao modelo.
Delegando decisões
É autoevidente que decisões não devem ser delegadas à IA. Mas ter humanos verificando e decidindo tudo é exaustivo. Certas decisões repetitivas e estruturadas podem ser realizadas por ferramentas simbólicas em nome dos humanos.
“Esses testes cobrem todas as branches?” — nenhum humano precisa ler. Uma ferramenta de cobertura julga. “Esse código satisfaz as regras estruturais?” — nenhum humano precisa revisar. validate julga. “Existem funções ainda não processadas?” — nenhum humano precisa contar. O CLI declara.
Decisões que não podem ser delegadas à IA podem ser delegadas a ferramentas simbólicas — porque são determinísticas, não probabilísticas. Esta é a razão de existir do Symbolic Feedback Loop.
É mais importante assentar os trilhos do que fazer o trem mais rápido.
Muitas pessoas estão construindo trens. Quase ninguém está assentando trilhos.
Referências
- Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
- Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” arXiv:2304.05128, 2023.
- Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022.
- Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
- Aman Madaan, Niket Tandon, Prakhar Gupta, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
- Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
- Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track.
- Carlos E. Jimenez, John Yang, Alexander Wettig, et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Artigo relacionado: Ratchet Pattern — Como fazer um agente terminar o trabalho — A implementação prática desta teoria. Um padrão que força agentes a convergir.
Ferramenta relacionada: tsma — Um exemplo funcional do Ratchet Pattern. 527 funções, zero TODO.
Changelog
- 2026-05-14: Versão inicial