Computação Científica da OpenAI Fica Mais Rápida, mas a Verificação se Torna o Gargalo

A OpenAI publicou oito estudos de caso sobre computação científica em 28 de julho, mostrando agentes de programação lidando com projetos que vão da manutenção rotineira à reescrita completa de softwares de genômica. Os resultados trazem alguns ganhos de desempenho marcantes. Também expõem uma limitação mais difícil: produzir código está se tornando mais fácil mais rapidamente do que validá-lo.

O novo relatório de campo examina projetos realizados principalmente nas ciências da vida. Cinco usaram apenas Codex, enquanto três combinaram Codex com Claude Code. Pesquisadores aplicaram os agentes a empacotamento, otimização, migração de frameworks, tradução de linguagem e reformulação voltada a GPU.

Essa combinação torna o relatório científico da OpenAI mais útil do que outro benchmark de programação. Esses agentes trabalharam em software com consequências científicas reais, e não em exercícios isolados de programação. Ainda assim, a OpenAI e os pesquisadores colaboradores não reproduziram independentemente todos os benchmarks relatados. A maioria dos resultados continua sendo relatos específicos dos casos, fornecidos pelas equipes responsáveis por cada projeto.

Portanto, o conflito central não é Codex contra Claude Code. É implementação rápida contra verificação científica lenta. Os agentes agora podem alterar milhares de linhas, traduzir sistemas maduros e gerar extensões estatísticas plausíveis. Os cientistas ainda precisam determinar se essas mudanças preservam o significado de um experimento.

A Anthropic chegou a uma conclusão semelhante por outro caminho. Seu trabalho sobre agentes de longa duração argumenta que a programação científica autônoma depende de oráculos de teste, mecanismos objetivos que indicam a um agente se ele está progredindo. As duas empresas apontam para a mesma divisão de trabalho. Os agentes implementam, enquanto especialistas especificam, testam e avaliam.

A Computação Científica da OpenAI Vai Além de Sugestões de Código

A mudança mais importante do relatório é a escala de trabalho que os cientistas estão dispostos a delegar.

As ferramentas de programação com IA começaram como sistemas de preenchimento automático que sugeriam uma função ou completavam uma linha. Em vez disso, os projetos do relatório da OpenAI usaram agentes em repositórios inteiros. Esses sistemas podiam inspecionar código existente, editar vários componentes, executar testes, interpretar falhas e continuar trabalhando em direção a um resultado definido.

Os oito estudos de caso abrangem seis tipos sobrepostos de projetos. Eles incluem manutenção leve, otimização direcionada, migração de compatibilidade, tradução para novas linguagens de programação, reescritas voltadas ao desempenho e novas capacidades científicas.

Um projeto modernizou o cyvcf2, uma biblioteca Python para ler e gravar arquivos de variantes genômicas. Após uma década de mudanças no Python, no gerenciamento de dependências e nos sistemas de empacotamento, a biblioteca se tornou mais difícil de compilar e lançar. GPT-5.5 ajudou a substituir seu processo legado de empacotamento por um sistema unificado, e as mudanças foram incorporadas ao projeto upstream.

Esse exemplo importa porque a manutenção raramente recebe o mesmo reconhecimento acadêmico que um novo método ou publicação. No entanto, sistemas de compilação desatualizados podem impedir que outros cientistas instalem ou reutilizem softwares de pesquisa que, de outra forma, seriam valiosos. Agentes de programação podem absorver trabalhos necessários, repetitivos e difíceis de financiar.

O caso MHCflurry foi muito além. MHCflurry prevê quais fragmentos de proteínas provavelmente aparecerão nas superfícies celulares, uma tarefa relevante para a imunologia e a pesquisa sobre câncer. Suas dependências envelhecidas de TensorFlow e Keras criaram um problema crescente de manutenção.

Os agentes ajudaram a migrar o pacote para PyTorch preservando os modelos lançados e suas previsões. A reescrita alterou quase 10.000 linhas em aproximadamente 130 arquivos, segundo os colaboradores. Ela foi lançada no MHCflurry 2.2.0 depois que revisores verificaram que os pesos existentes carregavam corretamente e que as previsões permaneciam dentro das tolerâncias definidas.

Esses projetos representam o centro prático da ciência com IA agêntica. O agente não decide se uma hipótese biológica é significativa. Ele reduz o esforço de engenharia necessário para manter utilizável o software que sustenta essa hipótese.

Os casos da OpenAI também mostram por que ferramentas científicas conhecidas são alvos atraentes. Pacotes maduros contêm comportamentos funcionais, conjuntos de testes existentes e saídas de referência. Esses artefatos dão aos pesquisadores uma base para avaliar as mudanças de um agente.

O desenvolvimento científico do zero é menos permissivo. Quando não existe uma implementação aceita, os pesquisadores precisam projetar simulações, verificações estatísticas ou outros critérios de aceitação antes de confiar no resultado. Quanto menos objetivo for o alvo, mais difícil se torna a supervisão de agentes.

O relatório, portanto, descreve progresso com limites. Os agentes realizaram implementação em superfícies maiores do que assistentes comuns. Eles não eliminaram a necessidade de orientação científica e tiveram melhor desempenho quando o sucesso podia ser medido externamente.

Código de Pesquisa Antigo se Tornou uma Infraestrutura Cara

Os agentes de programação estão chegando quando o crescimento dos dados tornou mais difícil tolerar softwares científicos negligenciados.

Softwares de pesquisa frequentemente começam como material de apoio para um artigo. Uma pequena equipe acadêmica desenvolve código suficiente para testar um método, publica o resultado e passa ao próximo problema financiado. Outros pesquisadores podem então adotar esse código, até que um protótipo silenciosamente se transforme em infraestrutura compartilhada.

Os incentivos continuam desalinhados. Universidades recompensam artigos, bolsas e contribuições científicas inovadoras de forma mais direta do que empacotamento, documentação, testes ou atualizações de dependências. O suporte profissional de engenharia de software também é escasso em muitos laboratórios.

Evidências coletadas antes da atual onda de IA agêntica mostram a escala do problema. Um estudo sobre código de pesquisa testou mais de 9.000 scripts R publicados em ambientes computacionais limpos. Ele constatou que 74 por cento falharam na primeira execução, enquanto 56 por cento ainda falhavam após limpeza automatizada.

Uma análise separada de 98 ferramentas de biologia computacional constatou que 57,1 por cento falharam quando os pesquisadores seguiram suas instruções documentadas de instalação. Outros 27,6 por cento não puderam ser instalados mesmo após intervenção manual. Uma falha de instalação automática acrescentava cerca de 70 minutos de trabalho, em média, segundo o estudo sobre software de ômicas.

Esses números não significam que cada falha tenha corrompido um resultado científico. Eles mostram quanto tempo de pesquisa pode desaparecer antes mesmo de a análise começar. Dependências quebradas, detalhes de configuração ausentes e premissas não documentadas transformam a reutilização de software em trabalho investigativo.

A genômica torna essa pressão especialmente visível. Os custos de sequenciamento caíram mais rapidamente do que os custos de análise posterior na última década. Os laboratórios podem gerar dados em escalas que sobrecarregam os pipelines de armazenamento, computação e software usados para processá-los.

O problema não é simplesmente código lento. Um pipeline de análise frágil pode reduzir a reprodutibilidade, dificultar a revisão de resultados antigos e criar diferenças sutis entre laboratórios. A implementação torna-se parte do método experimental, mesmo quando os incentivos acadêmicos a tratam como um artefato descartável.

A ciência com IA agêntica altera a economia de lidar com essa dívida. Um pesquisador pode pedir a um agente que atualize dependências, adicione testes, migre frameworks ou inspecione gargalos de desempenho. Um trabalho que antes competia com o prazo de um artigo ou de uma bolsa se torna mais fácil de tentar.

Essa mudança pressiona tanto universidades, financiadores e líderes de laboratório quanto desenvolvedores de software. Se a implementação se torna menos cara, as expectativas aumentam. Pesquisadores terão menos desculpas para distribuir código que não pode ser instalado, testado ou reproduzido.

No entanto, custos menores de desenvolvimento não criam automaticamente uma infraestrutura duradoura. Uma reescrita gerada ainda precisa de revisores, lançamentos, documentação, suporte aos usuários e manutenção futura. O agente pode reduzir um acúmulo de tarefas sem criar uma instituição responsável pelo resultado.

Para laboratórios que tentam preservar decisões, benchmarks e contexto experimental, uma base de conhecimento de engenharia pesquisável pode apoiar essa gestão. Ela não pode validar resultados científicos, mas pode manter escolhas de design e evidências de revisão conectadas ao código.

Os Ganhos Mais Rápidos Vieram com Respostas Claras

Os agentes entregaram seus resultados mais fortes quando os pesquisadores puderam definir o sucesso antes do início da implementação.

HI.SIM fornece o exemplo mais claro. O simulador de genômica continha cálculos repetidos, cópias desnecessárias de dados e muitas pequenas gravações de arquivos. GPT-5.2 recebeu um pedido de otimização zero-shot e produziu mudanças locais sem intervenção humana adicional.

Em um conjunto de benchmarks com quatro cargas de trabalho, os colaboradores relataram uma redução de 30,97 por cento no tempo de execução agregado. O software otimizado produziu saída idêntica byte a byte, o que significa que cada byte de saída correspondia à versão de referência. Essa comparação rigorosa reduziu drasticamente a ambiguidade sobre se a velocidade havia alterado a ciência.

O projeto hifiasm usou um alvo mais flexível. Hifiasm monta genomas a partir de longas leituras de sequenciamento de DNA, e seu tempo de execução se concentra em várias operações computacionalmente exigentes. GPT-5.5 otimizou caminhos críticos selecionados dentro da implementação C existente.

Os colaboradores relataram uma redução de 25,1 por cento no tempo de execução em dados sintéticos retidos para teste. Em leituras registradas do cromossomo humano 20, a redução foi de 14,7 por cento. As mudanças também precisavam satisfazer limites de ordenação de leituras definidos antes da avaliação.

RustQC produziu a maior aceleração relatada. Ele substituiu 15 etapas de controle de qualidade pós-alinhamento em um fluxo de trabalho de sequenciamento de RNA por um programa Rust de passagem única. Em um conjunto de dados contendo 186 milhões de leituras, o tempo de execução sequencial das tarefas caiu de 15 horas e 34 minutos para 14 minutos e 54 segundos.

Esse resultado representa uma redução de mais de 60 vezes. O tráfego de disco relatado também caiu de 2,5 terabytes para 0,1 terabytes, enquanto as saídas numéricas testadas permaneceram equivalentes. Os colaboradores relataram ainda execução sete vezes mais rápida para Trim Galore e ganhos de três vezes para FastQC-Rust.

HelixForge adotou uma abordagem voltada ao hardware. O projeto substituiu um pipeline de CPU para inserir mutações conhecidas em leituras de sequenciamento por uma implementação nativa de GPU. Esses dados sintéticos ajudam pesquisadores a testar se ferramentas de chamada de variantes conseguem encontrar mutações em locais conhecidos.

Em um doador e uma região de 10 megabases, os colaboradores relataram que a etapa de edição foi executada 98,6 vezes mais rapidamente. O tempo de execução de ponta a ponta melhorou 59,6 vezes. O erro médio de frequência de mutação caiu de 0,076 para 0,034, enquanto um artefato detectável de realinhamento foi quase eliminado.

Esses resultados são substanciais, mas não devem se tornar afirmações universais sobre a produtividade de agentes de programação. O relatório completo rotula explicitamente suas conclusões numéricas como relatadas pelos colaboradores e específicas de cada caso. As equipes usaram diferentes modelos, escopos de projeto, conjuntos de dados e alvos de validação.

O padrão importa mais do que uma média combinada. A equivalência exata de saída funcionou bem para otimização delimitada. Tolerâncias de previsão ajudaram na migração de frameworks. Conjuntos de dados simulados com respostas conhecidas apoiaram projetos que introduziram novos comportamentos.

Este é o mecanismo por trás de projetos bem-sucedidos de computação científica da OpenAI. Os agentes não reconheceram de forma independente a verdade científica. Pesquisadores traduziram requisitos científicos em testes executáveis e, em seguida, usaram agentes para explorar o espaço de implementação.

Os casos também dependeram de iteração em etapas. As equipes dividiram objetivos amplos em mudanças menores, criaram benchmarks intermediários e revisaram seus sistemas de validação à medida que surgiam falhas. As implementações iniciais chegaram rapidamente, mas diferenças numéricas sutis e casos extremos realistas consumiram mais tempo.

Essa etapa final impede que o relatório sustente uma narrativa simples de automação. A ciência com IA agêntica acelera a parte intermediária do processo, em que uma especificação se transforma em código. Ela não elimina o trabalho necessário para criar a especificação nem para estabelecer evidências convincentes depois.

Código Plausível Não É Evidência Científica

O alerta mais contundente do relatório é que um agente pode soar confiante enquanto produz um resultado cientificamente defeituoso.

O caso bayesm-rs expõe esse risco com clareza. Pesquisadores usaram o GPT-5.2 para traduzir modelos estatísticos bayesianos e amostradores selecionados de um pacote R para Rust. A reescrita de base contava com uma implementação de referência madura, permitindo que a equipe comparasse o comportamento posterior ao original.

Os problemas apareceram quando o agente adicionou novas extensões estatísticas. Os resultados iniciais pareciam plausíveis, mas as implementações continham defeitos nos amostradores e na lógica específica de HART. Os revisores corrigiram esses problemas antes que os amostradores testados passassem nas verificações de convergência e de calibração baseada em simulação.

Um gráfico plausível ou um programa estável não é suficiente. Um software estatístico pode executar com sucesso enquanto amostra a distribuição errada, aplica uma simplificação inadequada ou oculta viés por trás de médias aparentemente razoáveis.

O projeto rustar-aligner apresentou outro desafio de verificação. STAR, um alinhador de sequenciamento de RNA amplamente usado, contém mais de 20.000 linhas de comportamento acumulado em C e C++. Agentes ajudaram a construir uma substituição em Rust destinada a reproduzir esse comportamento.

Em 10.000 leituras de sequenciamento de RNA de levedura, os colaboradores relataram taxas de concordância de 99,815 por cento para dados single-end e 99,883 por cento para dados paired-end em vários campos de alinhamento. Esses números parecem próximos de uma equivalência completa. Em pipelines científicos, porém, as discrepâncias restantes ainda podem exigir investigação.

Uma diferença pode refletir uma escolha de implementação inofensiva, um bug na reescrita ou uma convenção não documentada no original. Um agente não consegue resolver essa questão apenas a partir de uma porcentagem. Especialistas do domínio precisam rastrear as diferenças nas análises posteriores e decidir qual comportamento é cientificamente aceitável.

Essa limitação também aparece em avaliações independentes. FrontierSWE testa agentes de programação em problemas amplos de implementação e de nível de pesquisa. O relatório observa que os agentes não concluíram integralmente nenhuma de suas cinco tarefas de implementação do zero, reforçando a lacuna entre o trabalho em repositórios e a engenharia aberta.

O risco aumenta quando o código gerado afeta o comportamento científico, e não apenas empacotamento ou desempenho. Comparações exatas se tornam impossíveis quando um projeto introduz um novo método. Pesquisadores então precisam escolher simulações, tolerâncias e medidas de resultado que podem deixar passar modos de falha ocultos.

Dados reais acrescentam mais pressão. Pequenas cargas de trabalho sintéticas tornam a iteração mais rápida, mas os colaboradores da OpenAI encontraram repetidamente casos extremos adicionais ao mudar para conjuntos de dados realistas. Uma suíte de validação só consegue detectar comportamentos que foi projetada para examinar.

A pesquisa mais ampla da Anthropic sobre agentes de programação reforça a necessidade de especialização. Sua análise de cerca de 400.000 sessões constatou que as pessoas tomavam a maioria das decisões de planejamento, enquanto Claude tomava a maioria das decisões de execução. Especialistas do domínio obtiveram melhores resultados porque conseguiam reconhecer erros e se recuperar de mal-entendidos.

A distinção competitiva entre Codex e Claude Code é, portanto, secundária. Ambos avançam em direção a uma execução mais longa e mais autônoma. A disputa importante é entre a crescente autonomia dos agentes e a capacidade das organizações científicas de auditar o trabalho resultante.

Pesquisadores também devem separar a verificação de código da validação científica. Testes unitários podem confirmar que uma função se comporta de forma consistente. Eles não podem estabelecer que as premissas biológicas subjacentes são adequadas, que o conjunto de dados é representativo ou que a interpretação sustenta uma afirmação publicada.

As descobertas científicas da OpenAI colocam os especialistas em um novo papel. Eles passam menos tempo digitando implementações e mais tempo elaborando critérios de aceitação, selecionando conjuntos de dados de referência, investigando discrepâncias e decidindo se a evidência é forte o bastante para publicar.

Isso não é a eliminação do trabalho humano. É uma transferência de trabalho da construção para o julgamento. Laboratórios que tratam a saída de agentes como código finalizado deixarão passar a lição central do relatório.

Reescritas Mais Rápidas Podem Fragmentar Comunidades Científicas

A implementação barata cria um segundo problema: projetos tecnicamente impressionantes demais, sem proprietários claros.

Software científico envolve mais do que código-fonte. Projetos maduros acumulam promessas de compatibilidade, convenções de nomenclatura, documentação, expectativas dos usuários e soluções alternativas para conjuntos de dados incomuns. Muitas dessas restrições nunca aparecem em uma especificação formal.

Um agente pode traduzir funções para Rust ou substituir um antigo framework de machine learning. Ele não pode herdar automaticamente a confiança associada ao projeto original. Os usuários precisam saber quem revisará problemas, publicará atualizações, corrigirá vulnerabilidades e lidará com mudanças futuras no ecossistema ao redor.

O relatório da OpenAI identifica a coordenação precoce com mantenedores como a rota preferida quando isso for viável. A modernização de cyvcf2 entrou no projeto original. A migração de framework de MHCflurry também foi enviada para upstream, preservando um lar reconhecido para o desenvolvimento futuro.

Rustar-aligner seguiu um caminho diferente porque STAR não era mais mantido ativamente. A substituição passou para a administração de uma nova comunidade. Esse arranjo pode funcionar, mas exige um responsável visível e um plano de manutenção confiável.

O perigo é uma onda de reescritas paralelas. Se vários laboratórios gerarem novas versões de uma ferramenta confiável, cada versão poderá divergir em comportamento. Os usuários se dividirão entre pacotes, enquanto o grupo limitado de revisores especializados se espalhará por mais bases de código.

A fragmentação é particularmente arriscada quando implementações diferentes produzem resultados científicos ligeiramente distintos. Dados gerados por um laboratório podem deixar de se combinar de forma limpa com dados de outro. Estudos longitudinais também podem mudar de comportamento após uma atualização do pipeline.

Portanto, programar mais rápido aumenta o valor da governança. Os projetos precisam de regras de contribuição, suítes de benchmark, processos de lançamento, políticas de compatibilidade e atribuição clara. Financiadores talvez precisem apoiar a manutenção como infraestrutura científica, em vez de tratá-la como uma obrigação informal.

Há também uma dimensão de segurança. Agentes de programação frequentemente operam com acesso a repositórios, gerenciadores de pacotes, sistemas de teste e recursos computacionais. Uma autonomia maior cria mais espaço para que um agente interprete mal uma solicitação ou interaja com uma dependência insegura. A validação científica não substitui a revisão de segurança comum.

Os esforços de computação científica da OpenAI enfrentarão a mesma questão institucional que o software de código aberto em sentido mais amplo. Quem é responsável quando uma mudança assistida por agente parece correta, passa nos testes disponíveis e, mais tarde, produz um erro consequente?

O relatório de campo não resolve essa questão. Ele recomenda colaboração e administração responsável, mas isso depende de financiamento, incentivos e mantenedores dispostos. A ciência com IA agêntica pode reduzir o trabalho de escrever um patch. Não pode garantir que alguém continuará responsável cinco anos depois.

Essa incerteza deve influenciar a seleção de projetos. Atualizar uma biblioteca mantida ativamente junto de sua comunidade é diferente de publicar uma reescrita concorrente. Uma melhoria de velocidade, por si só, não justifica quebrar a compatibilidade ou criar uma nova carga de manutenção.

Cientistas que dirigem agentes devem começar identificando o futuro lar do trabalho. A validação prova que uma versão atende aos critérios definidos hoje. A administração responsável determina se os usuários podem continuar confiando nela após mudanças em dependências, conjuntos de dados e práticas de pesquisa.

Três Sinais Mostrarão se o Modelo se Sustenta

A próxima etapa precisa provar que esses projetos isolados podem se transformar em prática científica repetível.

O primeiro sinal é a replicação independente. A OpenAI descreve seu relatório como retrospectivo e exploratório, e as equipes colaboradoras continuam responsáveis pelas afirmações específicas de cada projeto. Grupos externos devem reproduzir os benchmarks principais em hardware, conjuntos de dados e fluxos de trabalho posteriores adicionais.

A replicação reforçaria o argumento de que agentes de programação podem modernizar a computação científica de forma confiável. Grandes diferenças de desempenho que diminuam fora do ambiente original enfraqueceriam alegações amplas de produtividade, mesmo que os projetos individuais continuem úteis.

O segundo sinal é a adoção upstream. Mais mudanças assistidas por agentes devem entrar em projetos estabelecidos por meio de processos comuns de revisão, teste e lançamento. A aceitação upstream mostra que os mantenedores consideram o trabalho compatível com os requisitos técnicos e comunitários do software.

Uma coleção crescente de reescritas desvinculadas sugeriria o contrário. Ela mostraria que agentes conseguem gerar alternativas mais rápido do que as comunidades conseguem avaliá-las ou absorvê-las. Esse resultado poderia melhorar a experimentação enquanto torna a infraestrutura compartilhada menos coerente.

O terceiro sinal é o desenvolvimento de práticas padrão de validação. Os campos científicos precisam de estruturas de teste reutilizáveis, conjuntos de dados de referência, políticas de tolerância e registros de procedência para mudanças assistidas por agentes. Esses sistemas devem examinar o significado científico, e não apenas se o código é executado.

A competição recente poderia acelerar esse trabalho. A Anthropic enfatizou recuperação determinística, oráculos de teste e artefatos auditáveis para agentes científicos. Um sistema de software científico de 2026 publicado na Nature também reflete o interesse crescente em agentes que ajudam especialistas do domínio a produzir software empírico.

A abordagem vencedora não será o modelo que escreve mais código. Será o fluxo de trabalho que torna os erros visíveis, preserva evidências e atribui responsabilidade após a implantação.

Para desenvolvedores, isso significa criar infraestrutura de avaliação antes de adicionar mais autonomia. Para líderes de pesquisa, significa tratar o tempo de verificação como um custo de projeto de primeira classe. Para financiadores, significa apoiar mantenedores e benchmarks compartilhados junto com o acesso a modelos.

Profissionais do conhecimento fora da ciência também devem prestar atenção. O padrão subjacente se aplica sempre que o software codifica julgamento profissional. Um agente pode acelerar a implementação em finanças, engenharia, políticas públicas ou operações. Um especialista do domínio ainda precisa definir a correção e investigar exceções.

A computação científica da OpenAI está passando da demonstração para o teste institucional. Os oito projetos mostram que agentes podem concluir trabalhos que antes exigiam um esforço substancial de engenharia especializada. Eles também mostram que uma implementação mais rápida torna a verificação e a administração responsável mais visíveis, não menos necessárias.

O próximo passo prático é escolher um projeto delimitado com uma saída de referência sólida. Defina os critérios de aceitação antes que o agente edite qualquer coisa. Registre cada benchmark, discrepância e decisão humana. Em seguida, pergunte se a evidência resultante convenceria um revisor independente.

Essa questão importa mais do que a rapidez com que a primeira implementação surgiu. Se as organizações de pesquisa conseguirem ampliar a revisão confiável junto com a ciência de IA agêntica, o software científico poderá se tornar mais rápido e durável. Caso contrário, a dívida técnica de amanhã será simplesmente gerada em maior velocidade.