Um novo relatório de campo da OpenAI e de colaboradores acadêmicos argumenta que ferramentas de codificação com IA estão se tornando úteis para um problema negligenciado, mas importante, na ciência: manter e modernizar o software de pesquisa do qual muitos laboratórios dependem, mas que poucos equipes têm tempo de apoiar adequadamente. Ao longo de oito estudos de caso, pesquisadores usaram agentes de codificação para atualizar sistemas de instalação, portar código legado para frameworks mais novos, otimizar desempenho e até reescrever ferramentas envelhecidas em novas linguagens.

A conclusão central é mais cautelosa do que triunfal. Segundo o relatório, sistemas como Codex, Claude Code, GPT-5.5 e GPT-5.2 podem acelerar o trabalho de implementação, às vezes em grande medida, mas não se pode confiar neles para determinar se o software resultante está cientificamente correto. Na prática, isso desloca o gargalo da escrita de código para o desenho de testes, validação de resultados e atribuição de responsabilidade pela manutenção de longo prazo.

O que o relatório diz ter mudado

O relatório, descrito pelo The Decoder como um relato de campo e não como um estudo formal representativo, concentra-se sobretudo em software relacionado à biologia. Isso importa porque muitas ferramentas de pesquisa começaram como código escrito para um único artigo ou projeto e depois foram incorporadas a fluxos de trabalho mais amplos sem a equipe ou a disciplina de engenharia típicas do software comercial.

Nesse cenário, os agentes de codificação parecem mais úteis quando a tarefa é clara e o alvo de validação pode ser definido com antecedência. Um exemplo foi o cyvcf2, uma biblioteca em Python para ler dados genéticos, em que o GPT-5.5 foi usado para substituir uma configuração de build e instalação desatualizada por uma mais moderna.

Um exemplo mais complexo foi o MHCflurry, um modelo de imunologia usado para prever quais alvos as células imunes podem reconhecer. Segundo o relatório, Claude Code e Codex alternaram entre funções de implementação e revisão enquanto portavam cerca de 10.000 linhas de código do TensorFlow para o PyTorch. Esse tipo de migração costuma ser necessário para manutenção e desempenho, mas também é arriscado porque o software científico pode parecer executar corretamente enquanto produz saídas sutilmente erradas.

O caso mais ambicioso foi o rustar-aligner, uma reescrita do STAR em Rust. O STAR é amplamente usado para mapear leituras de sequenciamento para posições no genoma, e o relatório diz que a base de código original tem mais de 20.000 linhas de C e C++ e não é mais mantida ativamente. Em testes com 10.000 leituras curtas de sequenciamento de células de levedura, o rustar-aligner igualou o STAR em 99,815 por cento dos casos single-end e em 99,883 por cento dos casos paired-end, com base nos critérios de comparação do relatório. Os autores também afirmaram que nenhum dos dois ferramentas mapeou leituras que a outra deixou completamente de mapear.

Grandes ganhos de velocidade vieram com um porém

Os ganhos de desempenho destacados no relatório são substanciais, mas vêm de projetos individuais e não de um benchmark controlado entre muitas equipes.

O RustQC, que consolidou 15 ferramentas de controle de qualidade em um único programa, teria reduzido o tempo de execução em um grande conjunto de dados de 15 horas e 34 minutos para 14 minutos e 54 segundos, ou seja, mais de 60 vezes mais rápido. Outro projeto, o HelixForge, substituiu o BamSurgeon para geração de dados genômicos sintéticos por uma versão baseada em GPU. No teste citado, usando dados de um doador e uma região genômica de dez milhões de pares de bases, o pipeline completo rodou 59,6 vezes mais rápido e sua principal etapa computacional 98,6 vezes mais rápido do que o BamSurgeon.

Outros projetos foram menos dramáticos, mas ainda notáveis. No hifiasm, uma ferramenta de montagem de genoma, o GPT-5.5 teria encontrado otimizações que reduziram o tempo de execução em dados reais do genoma humano em quase 15 por cento depois que o pesquisador primeiro construiu conjuntos separados de treinamento e validação. No HI.SIM, o GPT-5.2 e depois um modelo mais novo otimizaram partes diferentes do programa, com ganhos combinados de tempo de execução de cerca de 31 por cento sem alterar a saída, segundo o relatório.

Esses resultados sugerem um papel prático de curto prazo para agentes de IA em engenharia de pesquisa: não ciência autônoma, mas modernização de código, reparo de dependências, ajuste de desempenho e migração de frameworks. Para laboratórios com pipelines frágeis, isso pode ser significativo mesmo quando os ganhos ficam aquém dos melhores exemplos do relatório.

Onde os modelos falharam

A mensagem mais importante do relatório é que passar em testes ou produzir saídas plausíveis não basta quando o software incorpora pressupostos científicos.

O estudo de caso do bayesm ilustra o problema. Sua reescrita em Rust teria rodado entre duas e vinte vezes mais rápido que o original, mas as primeiras versões de dois métodos avançados ainda continham erros difíceis de detectar apenas pelas saídas. Em um caso, o agente de codificação inverteu um parâmetro de controle e usou o recíproco do valor pretendido. Outro erro de cálculo também passou despercebido. Os pesquisadores só encontraram esses problemas depois de executar uma calibração detalhada com milhares de conjuntos de dados sintéticos com resultados conhecidos.

Um segundo método do bayesm, o HART, entregou resultados que pareciam amplamente plausíveis, mas ainda continha várias falhas, incluindo cálculos excessivamente caros e um fator de correção com escala incorreta. A lição desse exemplo é contundente: o software pode parecer numericamente estável e até cientificamente razoável, mas ainda estar errado de maneiras que importam para a interpretação posterior.

As pessoas envolvidas nos projetos deixaram essa preocupação explícita. Brent Pedersen, desenvolvedor do cyvcf2, escreveu que agentes de codificação facilitam avançar rápido, mas que a ciência ainda exige “expert guidance, understanding, taste, and care.” Philip Ewels, que liderou o RustQC, descreveu os sistemas como “eloquent, convincing, and confidently wrong in ways that are easy to miss.” Segundo o relato do The Decoder, ele não deixou os modelos avaliarem sua própria correção e, em vez disso, usou um ambiente de testes independente.

Essa divisão de trabalho aparece repetidamente nos estudos de caso: humanos definem metas, critérios de aceitação e métodos de validação; os agentes produzem implementações; então especialistas verificam se o software realmente está fazendo o trabalho científico certo.

Evidências, limites e de quem são essas alegações

As alegações mais fortes nesta história vêm de um relatório de campo produzido com OpenAI e parceiros acadêmicos, conforme descrito pelo The Decoder. Os estudos de caso são relatos retrospectivos dos participantes, não uma pesquisa aleatória ou representativa sobre trabalho com software de pesquisa. Essa limitação importa.

As cifras de desempenho para RustQC, HelixForge, hifiasm, HI.SIM, bayesm, rustar-aligner, MHCflurry e cyvcf2 são, portanto, resultados específicos de projetos relatados pelas equipes envolvidas. Elas devem ser lidas como exemplos do que é possível sob condições cuidadosamente delimitadas, não como prova geral de que agentes de codificação entregarão de forma confiável os mesmos ganhos em outras bases de código.

A mesma cautela se aplica às estimativas econômicas do relatório. Os autores sugerem que, se os agentes resolvessem um quarto a metade dos problemas de instalação em 100 pacotes de pesquisa, o tempo de pesquisa recuperado poderia valer entre US$ 600 mil e quase US$ 5 milhões. Eles também estimam cerca de 650 horas de manutenção economizadas por ano para o NumPy. Esses números são estimativas indicativas do relatório, não dados de mercado verificados externamente.

O relatório também observa um risco organizacional importante: reescritas baratas podem criar fragmentação. Se laboratórios gerarem versões alternativas de ferramentas estabelecidas mais rápido do que as comunidades conseguem mantê-las, podem dividir usuários e consumir ainda mais tempo dos mantenedores. Essa preocupação apareceu nos exemplos. Algumas melhorias foram incorporadas de volta aos projetos originais, outras não. Como o STAR não era mais mantido, o rustar-aligner foi transferido para o scverse. Em outro caso, o autor do FastQC recusou substituir a ferramenta original por sua reescrita em Rust, e a equipe aplicou as melhorias descobertas à versão Java existente, obtendo o mesmo aumento de velocidade de três vezes.

Por que isso importa para construtores e equipes corporativas de IA

Para construtores de IA, o relatório reforça o argumento de que agentes de codificação são assistentes de infraestrutura, e não desenvolvedores autônomos de ponta a ponta. O padrão útil não é “o agente escreve o código, faça o deploy”, mas “o agente propõe mudanças dentro de um ciclo rigoroso de validação”. Isso é especialmente relevante para equipes corporativas de IA que trabalham em áreas reguladas ou de alto risco, como saúde, biotecnologia, finanças e sistemas industriais.

Para equipes de produto avaliando Codex, Claude Code, GPT-5.5 ou GPT-5.2, a conclusão prática é que a confiabilidade depende menos do modelo sozinho do que do processo ao redor. Ambientes de teste independentes, conjuntos de dados de referência, critérios formais de aceitação e revisão humana continuam essenciais. Quanto melhor a tarefa puder ser especificada, mais valor um agente de codificação parece entregar.

Para organizações de pesquisa e compradores corporativos, o aspecto da manutenção pode ser ainda mais importante do que os ganhos brutos de velocidade. Muitas instituições dependem de software antigo, mas essencial, cujos autores originais seguiram adiante. Se ferramentas de codificação com IA puderem reduzir o custo de upgrades, ports de frameworks, correções de dependências ou ajuste de desempenho, elas poderão estender a vida útil de ferramentas críticas. Mas o comprador também herda o ônus da verificação e da gestão futura.

O que observar a seguir

O próximo sinal a monitorar é se esses métodos de estudo de caso se transformam em fluxos de trabalho repetíveis. Isso exige mais do que modelos melhores. Exige ambientes de avaliação padronizados, modelos de responsabilidade mais claros e práticas mais fortes para comparar ferramentas reescritas com referências confiáveis.

Também vale observar se mais comunidades seguem o modelo do scverse ao dar um lar institucional para reescritas assistidas por IA, em vez de deixá-las como experimentos pontuais. Outro indicador será se mantenedores de projetos importantes como NumPy ou bibliotecas científicas próximas ao PyTorch adotam manutenção orientada por agentes para tarefas rotineiras, mantendo revisão humana mais rigorosa para mudanças algorítmicas.

Por fim, o progresso dos modelos ainda importa. Uma pessoa envolvida no esforço do MHCflurry teria dito que uma tentativa anterior, no início de 2025, falhou porque os modelos disponíveis ainda não eram capazes o suficiente. Se essa avaliação estiver correta, gerações mais recentes podem ampliar o conjunto de tarefas que os agentes conseguem lidar. Mas o relatório sugere que uma maior fluência em codificação não resolve o problema mais difícil do julgamento científico.

Perspectiva da Creati.ai

Este relatório chega em um momento importante no debate sobre agentes de IA porque separa duas ideias que costumam ser confundidas: gerar software com aparência correta e produzir software cientificamente confiável. Em contextos de pesquisa, isso não é a mesma coisa. Quanto mais convincentes se tornam os agentes de codificação, mais perigoso é confundir qualidade de implementação com correção do domínio.

Para a indústria de IA, isso aponta para uma oportunidade mais concreta. O mercado imediato não é a engenharia de pesquisa totalmente autônoma. É a criação de ferramentas que ajudem especialistas a modernizar pilhas de software frágeis, migrar código legado e reduzir filas de manutenção, ao mesmo tempo em que tornam a validação mais sistemática. Fornecedores que combinem forte geração de código com testes robustos, rastreabilidade e fluxos de revisão provavelmente criarão valor mais duradouro do que aqueles que vendem apenas autonomia.