Descobertas da OpenAI com IA: a lição de verificação no Bun

A OpenAI publicou um post contando três resultados novos em matemática, ciência da computação e física. Todos saíram de trabalho conjunto com pesquisadores acadêmicos. Não foi um modelo cuspindo um paper sozinho. Foi gente da área pegando o que a IA sugeria, desmontando e checando cada passo. Eu li as descobertas da OpenAI pensando numa coisa bem menos glamourosa que física teórica: o PR que você vai abrir amanhã com código gerado por IA.

A fonte original está aqui: Building scientific understanding with academic communities.

O que a OpenAI anunciou, sem exagero

O resumo honesto é este. Modelos de linguagem foram usados como parceiros de pesquisa em três áreas diferentes. Em cada caso o modelo ajudou a chegar num resultado que os pesquisadores não tinham antes. Depois os acadêmicos validaram tudo com os métodos de sempre: prova revisada, experimento reproduzível, comparação com o que já se sabia.

Não vou fingir que entendi cada detalhe técnico das três áreas. Não entendi, e desconfio de quem diz que entendeu tudo em uma leitura. O que me interessa aqui é o formato do trabalho, porque ele se repete em qualquer lugar onde IA produz algo que parece certo.

O formato é:

1. A IA propõe.
2. Alguém que entende do assunto tenta quebrar a proposta.
3. Só o que sobrevive vira resultado.

Isso não tem nada de novo. É o método científico com um estagiário muito rápido e muito confiante no meio.

Por que as descobertas da OpenAI importam para quem programa

Porque a gente já vive essa situação todo dia, só que sem a parte 2.

Você pede uma função ao assistente. Ela compila. O nome das variáveis é bom. Tem até comentário. E aí você faz merge porque "parece certo". Na ciência, "parece certo" não publica nada. No nosso repositório, publica em produção.

IA que acerta sem ninguém verificar só deu sorte, e sorte não entra no changelog.

O ponto que eu tiro do anúncio é que o valor não veio só do modelo. Veio do modelo mais uma comunidade com régua alta. Tira a régua e o que sobra é um gerador de hipóteses plausíveis. Útil, mas perigoso.

Onde o Bun entra nessa história

O Bun é um bom exemplo de projeto que vive de prova, não de promessa.

Quando o Bun diz que é compatível com Node, ninguém acredita por educação. O time roda suítes de teste do próprio Node contra o runtime e acompanha o que passa e o que falha. Quando diz que é rápido, solta benchmark que qualquer um pode rodar na própria máquina. Algumas vezes os números foram contestados, gente refez o teste, e a discussão ficou melhor por causa disso.

É o mesmo ciclo da notícia: alguém afirma, a comunidade tenta derrubar, o que fica de pé ganha confiança. O Bun cresceu porque aceitou ser verificado em público.

E tem um lado prático. O bun test já vem no runtime, com API parecida com Jest, e roda rápido o bastante para você não ter desculpa. Se verificar custa caro, ninguém verifica. Se custa um segundo, vira hábito.

Como verificar código gerado por IA com Bun

Vou mostrar o truque que eu mais uso, e que é praticamente o que um matemático faz com uma conjectura: comparar a resposta esperta com uma resposta burra que você sabe que está certa.

Imagine que a IA te deu uma função otimizada para achar o maior subarray contínuo (o famoso Kadane):

// max-subarray.ts
export function maxSubarray(nums: number[]): number {
  let best = nums[0]
  let current = nums[0]
  for (let i = 1; i < nums.length; i++) {
    current = Math.max(nums[i], current + nums[i])
    best = Math.max(best, current)
  }
  return best
}

Parece certa. Mas você não precisa confiar. Escreve a versão força bruta, O(n²), lenta e óbvia, e joga milhares de entradas aleatórias nas duas:

// max-subarray.test.ts
import { test, expect } from 'bun:test'
import { maxSubarray } from './max-subarray'

const bruteForce = (nums: number[]) => {
  let best = -Infinity
  for (let i = 0; i < nums.length; i++) {
    let sum = 0
    for (let j = i; j < nums.length; j++) {
      sum += nums[j]
      best = Math.max(best, sum)
    }
  }
  return best
}

const randomArray = () =>
  Array.from({ length: 1 + Math.floor(Math.random() * 30) }, () =>
    Math.floor(Math.random() * 41) - 20
  )

test('bate com a força bruta em 5000 casos', () => {
  for (let k = 0; k < 5000; k++) {
    const nums = randomArray()
    expect(maxSubarray(nums)).toBe(bruteForce(nums))
  }
})

Roda com bun test. Se quiser caçar falha intermitente, bun test --rerun-each 20 repete a suíte várias vezes. A força bruta é o seu revisor acadêmico. Ela não é elegante. Ela só não mente.

Repara que esse teste pega coisa que review visual não pega. Array vazio, por exemplo: a função acima devolve undefined para []. Meu gerador nunca cria array vazio, então o teste também não pega. E isso já é uma lição: o verificador tem os pontos cegos de quem escreveu o verificador. Por isso a ciência usa revisão por pares, e por isso o seu teste merece um segundo par de olhos.

A objeção óbvia: "mas aí eu demoro mais"

Demora. Uns dez minutos a mais por função crítica.

Agora compara com o custo de um bug de cálculo em produção. Já vi desconto de checkout aplicado duas vezes porque uma função "parecia certa". O incidente levou uma tarde inteira, mais o reembolso, mais a conversa chata com o cliente. Dez minutos de teste saem baratos perto disso.

E não precisa fazer isso para tudo. Minha regra pessoal:

• Lógica de dinheiro, permissão ou dado sensível: sempre tem teste contra uma referência.
• Parsing e transformação de dados: teste com entradas aleatórias.
• Componente visual e cola de API: review normal resolve.

A IA acelerou muito a parte de escrever. A parte de confiar continua no mesmo ritmo de antes. Quem ignora isso só está empurrando o trabalho para o plantão de domingo.

O que muda de verdade no seu fluxo

Se eu tivesse que resumir o anúncio da OpenAI numa mudança concreta de hábito, seria esta: trate saída de IA como hipótese, não como resposta.

Na prática:

• Peça para a IA gerar também o teste, mas escreva você a referência burra. Se a IA escrever as duas, ela pode errar igual nas duas.
• Deixe bun test rodando no pre-commit ou no CI. Verificação que depende de lembrar não acontece.
• Quando a IA sugerir uma otimização, peça a versão ingênua junto. Você ganha o oráculo de graça.

Opinião forte: daqui a pouco tempo a habilidade que separa dev bom de dev mediano não vai ser escrever código. Vai ser saber provar que o código está certo. Os pesquisadores dessas três descobertas não ganharam por digitar mais rápido que o modelo. Ganharam porque sabiam onde cutucar.

Minha leitura final

Achei o anúncio interessante justamente por não vender a IA como gênio solitário. O crédito vai para o processo: modelo propondo, gente competente verificando, comunidade aberta para contestar. É o mesmo processo que fez o Bun ganhar credibilidade, e o mesmo que deveria proteger o seu repositório.

A IA vai continuar ficando mais esperta. Sua suíte de testes precisa acompanhar. Se quiser ver como eu aplico isso em projetos reais, dá uma olhada nos meus projetos.

A IA não descobriu nada sozinha, e esse é justamente o ponto.

A OpenAI publicou três resultados novos em matemática, computação e física. Em todos, o modelo propôs e pesquisadores de verdade tentaram derrubar cada passo.

Na ciência, "parece certo" não publica nada. No nosso repositório, publica em produção.

Meu hábito hoje: código de IA é hipótese, não resposta. Comparo a versão otimizada com uma força bruta lenta e óbvia em milhares de casos aleatórios com `bun test`. A força bruta é feia, mas não mente.

Daqui a pouco, o que vai separar um dev bom de um mediano não é escrever código. É saber provar que ele está certo.

Escrevi o passo a passo com exemplo no blog. Se fizer sentido para o seu time, o link está nos comentários.

#InteligenciaArtificial #Bun #TypeScript #Testes #DesenvolvimentoDeSoftware