Descubrimientos de OpenAI con IA: la lección de verificación en Bun

OpenAI publicó un post contando tres resultados nuevos en matemáticas, ciencias de la computación y física. Todos salieron de un trabajo conjunto con investigadores académicos. No fue un modelo escupiendo un paper solo. Fue gente del área tomando lo que la IA sugería, desarmándolo y revisando cada paso. Leí los descubrimientos de OpenAI pensando en algo mucho menos glamoroso que la física teórica: el PR que vas a abrir mañana con código generado por IA.

La fuente original está aquí: Building scientific understanding with academic communities.

Lo que OpenAI anunció, sin exagerar

El resumen honesto es este. Se usaron modelos de lenguaje como compañeros de investigación en tres áreas distintas. En cada caso el modelo ayudó a llegar a un resultado que los investigadores no tenían antes. Después los académicos validaron todo con los métodos de siempre: prueba revisada, experimento reproducible, comparación con lo que ya se sabía.

No voy a fingir que entendí cada detalle técnico de las tres áreas. No lo entendí, y desconfío de quien dice que lo entendió todo en una sola lectura. Lo que me interesa aquí es el formato del trabajo, porque se repite en cualquier lugar donde la IA produce algo que parece correcto.

El formato es:

1. La IA propone.
2. Alguien que sabe del tema intenta romper la propuesta.
3. Solo lo que sobrevive se convierte en resultado.

Esto no tiene nada de nuevo. Es el método científico con un becario muy rápido y muy seguro de sí mismo en el medio.

Por qué los descubrimientos de OpenAI importan para quien programa

Porque ya vivimos esta situación todos los días, solo que sin la parte 2.

Le pides una función al asistente. Compila. Los nombres de las variables son buenos. Hasta tiene comentarios. Y entonces haces merge porque "parece correcto". En la ciencia, "parece correcto" no publica nada. En nuestro repositorio, publica en producción.

Una IA que acierta sin que nadie verifique solo tuvo suerte, y la suerte no entra en el changelog.

Lo que saco del anuncio es que el valor no vino solo del modelo. Vino del modelo más una comunidad con la vara alta. Quita la vara y lo que queda es un generador de hipótesis plausibles. Útil, pero peligroso.

Dónde entra Bun en esta historia

Bun es un buen ejemplo de proyecto que vive de pruebas, no de promesas.

Cuando Bun dice que es compatible con Node, nadie se lo cree por cortesía. El equipo corre las suites de tests del propio Node contra el runtime y sigue lo que pasa y lo que falla. Cuando dice que es rápido, publica benchmarks que cualquiera puede correr en su propia máquina. Algunas veces los números fueron cuestionados, la gente rehízo las pruebas, y la discusión mejoró gracias a eso.

Es el mismo ciclo de la noticia: alguien afirma, la comunidad intenta tumbarlo, lo que queda en pie gana confianza. Bun creció porque aceptó ser verificado en público.

Y hay un lado práctico. bun test ya viene en el runtime, con una API parecida a Jest, y corre lo bastante rápido como para que no tengas excusa. Si verificar cuesta caro, nadie verifica. Si cuesta un segundo, se vuelve hábito.

Cómo verificar código generado por IA con Bun

Te voy a mostrar el truco que más uso, que es prácticamente lo que hace un matemático con una conjetura: comparar la respuesta lista con una respuesta tonta que sabes que es correcta.

Imagina que la IA te dio una función optimizada para encontrar el subarray contiguo de suma máxima (el 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 correcta. Pero no necesitas confiar. Escribes la versión de fuerza bruta, O(n²), lenta y obvia, y les lanzas miles de entradas aleatorias a las dos:

// 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('coincide con la fuerza bruta en 5000 casos', () => {
  for (let k = 0; k < 5000; k++) {
    const nums = randomArray()
    expect(maxSubarray(nums)).toBe(bruteForce(nums))
  }
})

Córrelo con bun test. Si quieres cazar fallos intermitentes, bun test --rerun-each 20 repite la suite varias veces. La fuerza bruta es tu revisor académico. No es elegante. Simplemente no miente.

Fíjate que este test atrapa cosas que una revisión visual no atrapa. El array vacío, por ejemplo: la función de arriba devuelve undefined para []. Mi generador nunca crea arrays vacíos, así que el test tampoco lo detecta. Y eso ya es una lección: el verificador tiene los puntos ciegos de quien escribió el verificador. Por eso la ciencia usa revisión por pares, y por eso tu test merece un segundo par de ojos.

La objeción obvia: "pero entonces tardo más"

Tardas. Unos diez minutos más por función crítica.

Ahora compáralo con el costo de un bug de cálculo en producción. Ya vi un descuento de checkout aplicado dos veces porque una función "parecía correcta". El incidente se llevó una tarde entera, más el reembolso, más la conversación incómoda con el cliente. Diez minutos de test salen baratos al lado de eso.

Y no hace falta hacerlo para todo. Mi regla personal:

• Lógica de dinero, permisos o datos sensibles: siempre lleva test contra una referencia.
• Parsing y transformación de datos: test con entradas aleatorias.
• Componentes visuales y pegamento de API: una revisión normal basta.

La IA aceleró mucho la parte de escribir. La parte de confiar sigue al mismo ritmo de antes. Quien ignora esto solo está empujando el trabajo a la guardia del domingo.

Lo que cambia de verdad en tu flujo

Si tuviera que resumir el anuncio de OpenAI en un cambio concreto de hábito, sería este: trata la salida de la IA como una hipótesis, no como una respuesta.

En la práctica:

• Pídele a la IA que genere también el test, pero escribe tú la referencia tonta. Si la IA escribe las dos, puede equivocarse igual en ambas.
• Deja bun test corriendo en el pre-commit o en el CI. La verificación que depende de acordarse no ocurre.
• Cuando la IA sugiera una optimización, pide la versión ingenua junto. Te llevas el oráculo gratis.

Opinión fuerte: dentro de poco, la habilidad que separa a un dev bueno de uno mediocre no va a ser escribir código. Va a ser saber probar que el código está bien. Los investigadores de estos tres descubrimientos no ganaron por teclear más rápido que el modelo. Ganaron porque sabían dónde pinchar.

Mi lectura final

El anuncio me pareció interesante justamente porque no vende a la IA como un genio solitario. El crédito va para el proceso: el modelo proponiendo, gente competente verificando, una comunidad abierta a cuestionar. Es el mismo proceso que le dio credibilidad a Bun, y el mismo que debería proteger tu repositorio.

La IA va a seguir volviéndose más lista. Tu suite de tests tiene que seguirle el paso. Si quieres ver cómo aplico esto en proyectos reales, echa un vistazo a mis proyectos.

La IA no descubrió nada sola, y ese es justamente el punto.

OpenAI publicó tres resultados nuevos en matemáticas, computación y física. En todos, el modelo propuso e investigadores de verdad intentaron tumbar cada paso.

En la ciencia, "parece correcto" no publica nada. En nuestro repositorio, publica en producción.

Mi hábito hoy: el código de IA es una hipótesis, no una respuesta. Comparo la versión optimizada con una fuerza bruta lenta y obvia en miles de casos aleatorios con `bun test`. La fuerza bruta es fea, pero no miente.

Dentro de poco, lo que va a separar a un dev bueno de uno mediocre no será escribir código. Será saber probar que está bien.

Escribí el paso a paso con un ejemplo en el blog. Si tiene sentido para tu equipo, el link está en los comentarios.

#InteligenciaArtificial #Bun #TypeScript #Testing #DesarrolloDeSoftware