Durante muito tempo, a conversa sobre IA em programação ficou presa na geração de código. Todo mundo quer saber se o modelo escreve função, passa em benchmark, resolve issue, fecha ticket.

Pra mim, essa pergunta já ficou pequena.

A pergunta certa é outra: como um LLM depura sistemas complexos no mundo real?

Foi exatamente isso que eu medi no TML, minha linguagem de programação orientada a sistemas e pensada para code generation por LLMs. Em vez de usar benchmark sintético, eu instrumentei o ambiente real de desenvolvimento com MCP e observei o comportamento do modelo durante 30 dias de trabalho orgânico em compilador, biblioteca padrão, codegen, SIMD, banco de dados e runtime. O resultado foi um dataset com 3.251 chamadas de ferramenta em 300 sessões, capturando como o modelo realmente trabalha quando encontra bugs de verdade.

O primeiro achado é brutal: LLMs são viciados em teste.

Mais da metade de todas as chamadas foi para test (52,7%). check ficou em 17,4%. emit-ir, que dá acesso muito mais direto ao diagnóstico interno do compilador, ficou em só 7,2%. Em outras palavras: sem orientação forte, o modelo tende a operar como um programador iniciante — muda código, roda teste, observa, repete. Menos diagnóstico. Mais tentativa e erro.

Isso bate com algo que muita gente ainda finge não ver: o gargalo do agente não é só o modelo. É o ecossistema de ferramentas e o fluxo cognitivo que você constrói em volta dele. O modelo até tem acesso a ferramentas melhores, mas isso não garante adoção. Ferramenta disponível não significa ferramenta usada.

Foi aí que entrou a parte mais interessante do estudo.

Eu comecei a alterar o prompt do sistema com intervenções comportamentais explícitas. A principal foi simples: use check antes de test, com uma justificativa quantitativa clara — check é 10x mais rápido. O efeito foi mensurável. A adoção de check saiu de 8,8% na linha de base para 25,3% nas sessões mais recentes, em apenas 10 dias. E mais importante: não foi um efeito pontual. A curva acelerou. O modelo não estava só obedecendo regra; estava internalizando padrão.

Esse ponto importa muito.

A maioria das discussões sobre prompt engineering é rasa. Parece que prompt é só “escrever melhor a instrução”. Não é. Prompt é política operacional. Quando bem desenhado, ele muda estratégia, ordem de validação e custo computacional do agente. No meu estudo, uma regra simples mudou a distribuição real de ferramentas ao longo do tempo.

Mas nem toda regra tem o mesmo efeito.

Quando a funcionalidade exige pouca fricção cognitiva, a adoção dispara. structured=true, por exemplo, chegou a 95,7% de uso sem regra explícita. Já debug_layers, que exige o modelo perceber a falha, trocar de modo mental e pedir diagnóstico multicamada, ficou em 11,1% mesmo depois de regra explícita. A lição aqui é simples: feature opcional morre. Se uma saída diagnóstica é realmente valiosa, ela tem que vir ligada por padrão.

Esse talvez seja o ponto mais forte do paper: atrio cognitivo derruba adoção.

A indústria está enchendo agentes de ferramentas e parâmetros, mas ignora o fato de que cada etapa extra tem custo mental. O agente não “vai lembrar” de usar tudo só porque você documentou. Ele vai preferir o caminho familiar, curto e definitivo. No meu caso, isso significa escolher test mesmo quando check é mais barato, ou ignorar debug_layers mesmo quando ele reduz chamadas diagnósticas posteriores.

Outro dado importante: a estratégia do modelo começou a mudar estruturalmente ao longo do estudo.

No começo, o padrão era dominado por test: cerca de 60% das chamadas. Nas sessões mais recentes, isso caiu para 44%, enquanto check subiu para 25,3% e emit-ir para 9,2%. Não é detalhe estatístico. Isso é uma transição real de comportamento: sair de “executar e observar” para “analisar e depois verificar”. É exatamente a diferença entre um fluxo de depuração reativo e um fluxo de depuração orientado a hipótese.

Em sessões mais pesadas, como o trabalho com SIMD e bugs de codegen, esse comportamento ficou ainda mais nítido. Em uma das sessões, check passou o próprio test em frequência, e o padrão de depuração virou quase um pipeline: check -> emit-ir -> corrigir -> invalidar cache -> check -> test. Isso já não parece um agente chutando. Parece um agente operando com método.

Agora vem a parte que considero mais prática de todas: latência manda na estratégia.

A ferramenta mais usada, test, também era a mais lenta: cerca de 37 segundos por chamada. Já check e ferramentas de documentação ficavam na faixa de milissegundos. Mesmo assim, test dominava o fluxo. Isso mostra que o modelo prefere feedback definitivo, mesmo pagando caro. A implicação é óbvia: reduzir latência de teste é provavelmente a melhoria de maior alavancagem em qualquer stack de agentic coding. No paper, a projeção é clara: levar test de 37 segundos para algo próximo de 2 segundos com execução JIT mudaria completamente a velocidade do ciclo de desenvolvimento.

O que sai disso tudo?

Minha leitura é direta:

LLM não vira engenheiro melhor só com modelo melhor.
Ele melhora quando você mexe em três coisas ao mesmo tempo: ferramenta, latência e política de uso.

Esse é o erro da maior parte do mercado hoje. Tem gente treinando modelo maior para resolver um problema que, na prática, é de arquitetura de workflow. O modelo já consegue bastante coisa. O que falta é um ambiente que empurre o comportamento certo, reduza fricção e entregue diagnóstico útil no momento exato.

Também vale ser honesto sobre as limitações. Esse estudo foi feito em um único projeto, com um único desenvolvedor, uma única família de LLM e um domínio muito específico: compiladores. Então não dá para sair vendendo generalização universal. Mas dá, sim, para tirar uma conclusão forte: o comportamento de depuração de um LLM é moldável, mensurável e altamente sensível ao design do ambiente.

A próxima fronteira de AI coding não é só gerar código melhor. É construir ecossistemas onde o modelo pare de agir como alguém apertando “run” sem parar e comece a operar como um engenheiro que sabe formular hipótese, validar barato, inspecionar a camada certa e reduzir o custo de cada iteração.

Quem entender isso antes vai construir agentes melhores.
Quem não entender vai continuar confundindo benchmark com engenharia.