Avaliando os principais modelos de código para geração de código efêmero

A categoria

O que é "código efêmero"

Código efêmero é código de propósito único e vida curta, gerado sob demanda para fazer um só trabalho — processar um arquivo, chamar uma API, transformar um payload, controlar um navegador — e então descartado ou regenerado, em vez de mantido como uma base de código.

Esses programas são pequenos: quase sempre com menos de mil linhas, geralmente menos de cem. Têm um contrato estreito — algumas entradas, um efeito colateral ou um resultado — e nenhuma necessidade da arquitetura, abstração ou longevidade de código de aplicação. São o encanamento que conecta um sistema a outro para uma única execução.

Esse tamanho é exatamente a faixa em que os modelos de hoje são mais fortes. Uma tarefa que cabe em um arquivo, não exige raciocínio entre módulos e pode ser verificada rodando-a está perto do ponto ideal da geração de código atual. A pergunta interessante já não é mais se um modelo de topo consegue escrevê-la — vários conseguem, quase sempre — mas qual modelo a produz de forma confiável, barata e correta o suficiente para se confiar sem supervisão.

O argumento

Guarde o prompt, não o código

Se um modelo consegue regenerar uma integração correta de 80 linhas a partir de um parágrafo de intenção, o código deixa de ser o ativo. A especificação passa a ser. Ela é menor, é legível, não apodrece e não está presa a uma linguagem ou versão de biblioteca.

Isso só funciona se a geração for confiável. Um micro-prompt que produz código funcional 70% das vezes é um passivo; a 99%+, com uma passada de reparo automático e barata para cobrir o resto, ele vira infraestrutura. Então a pergunta prática que este benchmark responde é: quão confiável é cada modelo exatamente nessa classe de trabalho, e a que custo?

Método

Como as tarefas foram medidas

Cada modelo recebeu a instrução e a spec de uma tarefa — nada sobre implementação — e a tarefa de produzir um programa completo mais o esquema de entrada. O programa foi então executado em um sandbox local isolado e avaliado em quatro eixos.

• Roda — ele executa sem quebrar e emite um resultado bem-formado?
• Correto — a saída corresponde ao resultado esperado e — nas tarefas de integração — um serviço simulado confirmou que a requisição foi autenticada corretamente? Uma resposta chumbada no código não passa.
• Qualidade — verificações estáticas de contrato mais um revisor LLM pontuando tratamento de erros, limpeza e robustez.
• Custo — gasto real de API, reportado por modelo e por resposta correta.

As 40 tarefas abrangem três famílias: processamento de arquivos e dados (parsear, transformar, agregar), integração com APIs externas em cinco esquemas reais de autenticação — bearer token, HTTP basic, cabeçalho de API-key, OAuth2 client-credentials e mutual TLS com certificados de cliente em PEM e em PKCS#12 — e correção de bugs de defeitos plantados. Cada concorrente rodou três amostras; um estudo de refinamento rodou uma.

Conclusão

Gere na hora, e barato

Para código efêmero — os programas pequenos e de propósito único que conectam sistemas por uma única execução — a economia se inverteu. O código já não vale a pena guardar; o prompt que o produz, sim.

O benchmark torna concreto o argumento prático. A confiabilidade nessa classe de trabalho é alta em todo modelo de topo e praticamente perfeita assim que você adiciona uma única passada de reparo automático. Essa passada funciona mesmo sem a capacidade de rodar o código, então cabe dentro de um pipeline de geração. E a diferença de custo entre a fronteira e o nível de valor é de uma ordem de grandeza, sem penalidade de correção.

Então a arquitetura eficiente não é uma biblioteca de utilitários mantidos, nem um modelo de fronteira chamado uma vez e cegamente confiado. É um micro-prompt compacto, um modelo barato e capaz, e um laço de auto-revisão — código invocado quando preciso, verificado e descartado. Você mantém a intenção. O modelo mantém todo o resto.

Para onde isso aponta

Estenda a ideia e a própria ferramenta muda de forma. Controle de versão e sistemas de build tratam o código como fonte da verdade — mas se o código é efêmero, a fonte da verdade sobe um nível, para os prompts e o estado atual do projeto. O precedente já existe: frameworks de migração de banco de dados não guardam o banco, guardam as instruções ordenadas que o constroem mais um marcador de onde você está na sequência. O banco é derivado; as migrações são o ativo.

É razoável esperar frameworks de código construídos sobre o mesmo princípio — que versionam um projeto como uma sequência de micro-prompts e um estado resolvido, e regeneram o código de fato sob demanda a partir deles. O código vira um artefato de build, como um binário compilado é hoje. A engenharia difícil e duradoura se desloca para como esses prompts são capturados, ordenados, reproduzidos e armazenados — é aí que o valor se assenta quando o código deixa de valer a pena guardar.