Será que tudo se resolve quando o modelo ficar mais inteligente?
A narrativa dominante nas ferramentas de programação com IA é esta: quando o modelo for bom o suficiente, ele escreverá código, testes e fará refatorações por conta própria. O que não funcionou com GPT-4 funcionará com GPT-5. O que o Claude não conseguiu, um Claude maior conseguirá.
Será mesmo?
Pedi ao Claude Opus 4.7 para refatorar o filefunc. Concluiu em uma hora, sem revisão humana. Passou no validate, passou no pytest, manteve o coverage. Olhando apenas o resultado, encaixa-se na narrativa de que “basta o modelo ser bom”.
Mas e se pedirmos ao mesmo modelo a mesma refatoração sem as regras do filefunc? Sem validate? Sem feedback de coverage? O resultado é completamente diferente. Entra em doom loop. Corrige um bug e quebra outro lugar, corrige esse e quebra um terceiro.
O mesmo modelo. O que mudou foi o ambiente.
“Terminei” — O instinto de encerramento prematuro do agente
Fiz outro experimento com o mesmo modelo. Lancei um agente autônomo em um projeto com 527 funções. “Escreva testes para todas as funções.” O agente concluiu o trabalho e reportou: “Concluído.”
Funções que realmente receberam testes: 40. Quarenta de 527.
O agente não mentiu. Depois de fazer 40, julgou que “já tinha feito o suficiente”. A tendência padrão do LLM é o encerramento prematuro otimista. Quando encontra uma função difícil, pula; depois de mais algumas, conclui que “o restante segue o mesmo padrão, então está bom”.
Depois de forçar o loop via ferramenta CLI:
Agente autônomo: 40 / 527 (7.6%) — agente declara "concluído"
Loop CLI: 527 / 527 (100%) — máquina declara "ainda faltam 487"
O mesmo modelo. O mesmo projeto. A diferença é quem decide quando “terminou”.
O ambiente faz o modelo
Os dois experimentos apontam para a mesma conclusão. O Opus 4.7 não completou a tarefa porque é inteligente. Completou porque a specification surface era machine-checkable.
filefunc validate → O código cumpre as regras de estrutura?
pytest → O comportamento existente foi preservado?
coverage → Quais branches ficaram de fora?
Esses três forneceram feedback imediato a cada modificação. O modelo recebia o feedback, corrigia, recebia novamente, corrigia novamente. self-correcting loop.
O ponto essencial é este:
A topologia do feedback determina o resultado mais do que o QI do modelo.
O LLM tem forte capacidade de geração, mas é fraco em garantir correctness. Porém, com um deterministic verifier, seu desempenho se estabiliza drasticamente. lint, typecheck, test, coverage — estes se tornam o gradient signal que corrige a saída do modelo.
“Vai se resolver quando o modelo for inteligente o suficiente” é uma tese errada. O correto é: “Quando o feedback for rápido o suficiente, resolve-se com o modelo atual”.
broad exploration vs local correction
O ponto forte do LLM não é broad exploration, mas sim local correction.
“Escreva testes para este projeto” — isso é broad exploration. O LLM perde a direção.
“A linha 41 não está coberta” — isso é local correction. O LLM escreve exatamente o teste que cobre aquela linha.
Números verificados em projeto real:
Sem feedback: para em 60~70% de coverage
Com feedback: atinge 100% (para funções alcançáveis)
O mesmo modelo. Uma única linha “line 41 not covered” funciona como gradient signal. Esse feedback direciona as correções do LLM na direção certa.
Symbolic Feedback Loop
Há uma estrutura que atravessa todas essas observações.
LLM gera → ferramenta determinística julga → resultado retorna ao LLM → repete
Chamo isso de Symbolic Feedback Loop.
O mainstream atual da indústria é o LLM Feedback Loop. IA verificando IA. Como um bêbado perguntando ao amigo bêbado: “Eu tô bêbado?” Ambos são probabilísticos, então os erros se acumulam.
O Symbolic Feedback Loop é diferente. pytest não alucina. go test não fica bêbado. A medição de coverage não mente. A verificação de especificação não deriva.
Essa estrutura funciona em domínios onde correctness pode ser julgada mecanicamente — código, testes, especificações, tipos. A elegância do design de uma API ou a naturalidade de uma 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 dos limites da verificação.
Tornar o modelo mais inteligente é menos eficaz do que tornar o feedback que retorna a ele mais preciso.
Delegação de decisões
É evidente que decisões não devem ser delegadas à IA. Porém, o humano verificar e decidir tudo é um trabalho árduo. Certas decisões repetitivas e padronizadas podem ser executadas por ferramentas simbólicas em nome do humano.
“Este teste cobre todos os branches?” — não precisa de leitura humana. A ferramenta de coverage julga. “Este código cumpre as regras de estrutura?” — não precisa de revisão humana. validate julga. “Ainda restam funções não processadas?” — não precisa de contagem humana. 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 que fazer o trem mais rápido é assentar os trilhos.
Muitos estão construindo trens. Quem assenta trilhos ainda são poucos.