OpenAI põe o GPT-6 Astra para limpar código legado: 800 mil linhas a menos em duas semanas

A equipe Core Experimentation da OpenAI é responsável pelo sistema de experimentos de toda a empresa. Ela mostrou como o GPT-6 Astra limpa código antigo, em vez de escrever código novo. Em duas semanas, cinco engenheiros fizeram merge de mais de 1 400 PRs e removeram mais de 800 mil linhas. A imagem de um serviço foi de 3,31 para 1,72 GB, e o tempo de CI caiu quase pela metade. A história foi publicada no blog da OpenAI para desenvolvedores e é um dos casos mais pé no chão de uso de agentes em uma base de código grande.

Prompt com erros de digitação no lugar de análise estática

Antes, o código morto era buscado com análise estática e logs de runtime. Mesmo assim, ainda aconteciam incidentes causados por remoções equivocadas. Desta vez, os engenheiros escreveram para o modelo um pedido descuidado, com erros de digitação, e o mantiveram no blog exatamente como estava: “Can you help identify and clean up dead code in the repo please, feel free to check slack, statsig [a feature flag and experimentation platform we use], or any other source you need to confirm that things are indeed no longer being used and can be cleaned up or simplified”.

O modelo não se limitou ao repositório. Ele foi por conta própria a PRs antigos, threads do Slack, trackers de tarefas e profiling de produção, e anexou a cada remoção uma explicação de por que aquele código era considerado morto. O revisor recebia argumentos e fontes, não um diff cru. Cerca de 400 variantes de snapshots visuais saíram dos testes.

A flag “Permanent” que consumia CPU havia anos

Experimentos e feature flags obsoletos são mais difíceis: esse tipo de código ainda pode estar rodando em produção. Os engenheiros pediram que o próprio modelo escrevesse o prompt da auditoria completa. Foi ele também quem calculou o custo de cada flag em CPU.

O modelo encontrou uma flag que, havia anos, multiplicava discretamente as verificações em todas as features ao mesmo tempo. Como ela estava marcada como “Permanent”, o modelo não a removeu por conta própria e levou a questão para revisão humana. Depois da remoção, o serviço economizou cerca de 0,42% de CPU. Na escala da OpenAI, isso representa dinheiro relevante, e o limite de autonomia do modelo parece razoável.

A conta da auditoria: Astra, Sol e o custo por achado

A parte mais prática do caso é a comparação entre modelos em uma mesma auditoria: 6 000 arquivos, 1 milhão de linhas em Python, TypeScript, Go e Rust.

• GPT-6 Astra Ultra: $109,06, 142 achados, $0,77 por achado
• GPT-6.1 Sol Ultra: $15,12, 131 achados, $0,12 por achado
• GPT-6.1 Sol Medium: $5,27, 86 achados, $0,06 por achado

O Sol Ultra entrega 92% dos achados por 14% do preço. A análise da diferença mostrou que o Sol deixava passar flags das quais outras flags dependem. Isso foi compensado com um ajuste no prompt. A conclusão prática: um modelo intermediário com instruções bem escritas alcança o topo de linha em tarefas desse tipo.

A mesma abordagem foi usada para acelerar o CI. O modelo foi instruído a sugerir otimizações e ranqueá-las pela economia esperada de minutos de CI por dia, com base no histórico de execuções do repositório. O pedido foi este: “What ideas do you have to relieve CI load in this repository? List your ideas in a table and rank all of them by estimated CI minutes saved per day based on this repo's CI run history”. Resultados:

• cerca de 30 PRs com merge feito
• a mediana do CI caiu de ~10 para 4,5 minutos
• o p90 baixou de 12,5 para 6 minutos
• um conjunto de 63 testes passou de 592,6 para 29,8 segundos, cerca de 20 vezes mais rápido

Os autores admitem que parte das sugestões adicionava mais complexidade do que benefício. O modelo encontra tantas otimizações que, sem priorização e métricas, a equipe se afoga nelas.

Se você tem código legado, a receita é simples. Pegue uma tarefa pequena: código morto, flag obsoleta ou teste instável (flaky). Rode-a em vários modelos e níveis de effort e compare o custo por achado. Leve os comentários da revisão para o prompt seguinte, para que o modelo aprenda com as suas regras, por exemplo sobre flags com dependências. Quando o resultado estiver estável, escale para partes maiores da base de código. Marque os pontos críticos, como foi feito com “Permanent”, para que a decisão fique com uma pessoa. Para empresas com dívida técnica acumulada, esse talvez seja o ROI mais rápido de agentes: o resultado se mede em linhas, gigabytes de imagem e minutos de CI.