OpenAI Dice Haber Resuelto Navier-Stokes: 10 Mil Agentes, 88 Horas y la Pelea Por el Crédito del Problema del Milenio

Hola HaWkers, el martes 8 de septiembre de 2026, OpenAI publicó lo que llama la resolución del problema de existencia y suavidad de Navier-Stokes, uno de los siete Problemas del Milenio del Clay Mathematics Institute, cada uno con un premio de US$ 1 millón. Según la empresa, un modelo interno todavía no lanzado, operando como un enjambre de cerca de 10 mil agentes, llegó al resultado en 88 horas y la prueba fue verificada formalmente en Lean. Doce horas antes, el matemático Tristan Buckmaster, de la NYU, había publicado una nota de cuatro páginas acusando a OpenAI de correr detrás del mismo camino después de enterarse del trabajo que él hacía con Levent Alpöge, matemático de Anthropic.

Vale la pregunta directa: ¿qué se probó exactamente, qué tiene esto que ver con quien escribe software, y por qué la comunidad matemática está más preocupada por la forma que por el resultado? En este artículo vas a entender el problema en lenguaje de ingeniero, qué significa una prueba verificada en Lean, los números reales divulgados hasta ahora, la cronología de la disputa y qué falta todavía para que alguien reciba el premio.

Qué Es el Problema de Navier-Stokes

Las ecuaciones de Navier-Stokes describen el movimiento de fluidos: agua en un caño, aire alrededor de un ala, humo subiendo de una chimenea. Los ingenieros las resuelven numéricamente todos los días en simulaciones de CFD. El problema del Clay Institute, formulado en 2000 por Charles Fefferman, de Princeton, es otro: pregunta si, en tres dimensiones, una solución que empieza suave puede desarrollar una singularidad en tiempo finito, lo que los matemáticos llaman blowup. En términos prácticos, si la velocidad o la vorticidad del fluido puede irse al infinito en un punto, en un instante específico, incluso con energía total limitada.

Durante casi 90 años nadie logró probar ni que eso ocurre ni que no ocurre. El enunciado oficial de Fefferman ofrece cuatro variantes, identificadas como (a), (b), (c) y (d). Las dos primeras tratan del fluido sin fuerza externa; las dos últimas, (c) y (d), permiten una fuerza externa suave actuando sobre el fluido. Probar blowup en cualquiera de ellas resuelve el problema. El resultado de OpenAI, según la empresa, es justamente un blowup en tiempo finito con forzamiento suave, en el espacio tridimensional entero y en el toro, o sea, las opciones (c) y (d).

Por Qué "Forzamiento Suave" Es la Palabra Clave

Acá está el detalle que explica toda la disputa. Existe un programa de investigación, abierto por los españoles Diego Córdoba, del ICMAT en Madrid, y Luis Martínez-Zoroa, de la CUNEF, que construye singularidades apilando capas de soluciones no singulares en una cascada infinita. Alrededor de 2023 ya tenían blowup para Euler con forzamiento irregular. Lo que faltaba era hacer que la misma cascada produjera una singularidad y, al mismo tiempo, mantener la fuerza externa suave. Ese era el último obstáculo, y casi nadie en el mundo trabajaba en él. Fefferman, autor del enunciado del premio, llamó a los dos "los héroes" de la historia al hablar con Quanta Magazine.

Qué Afirma OpenAI Haber Hecho

El post de OpenAI describe un proceso en dos fases. Primero, cerca de 100 agentes trabajaron durante 50 horas en las ecuaciones de Euler, la versión sin viscosidad del problema. Después, aproximadamente 10 mil agentes pasaron 88 horas atacando Navier-Stokes propiamente dicho, con el resultado alcanzado el sábado 5 de septiembre. Según el propio post, fueron cerca de 130 mil millones de tokens de salida solo en la parte de Navier-Stokes y 2,7 millones de mensajes intercambiados entre agentes, llegando a 4,9 millones contando los otros problemas. Enseguida, 17 horas adicionales con el modelo GPT-6 Astra produjeron la formalización en Lean.

Los números de costo varían según la fuente. Sébastien Bubeck, investigador de OpenAI, habló de "varios millones de dólares" a Quanta; Fortune estimó alrededor de US$ 2 millones a partir de una comparación con desafíos anteriores; TechCrunch citó un valor bastante mayor. No hay un número oficial, así que lo más honesto es decir que fue un esfuerzo de millones de dólares en computación concentrado en menos de dos semanas. El plazo también está confirmado por la empresa: el trabajo empezó el 1 de septiembre, motivado por rumores de que Anthropic estaría cerca de resolver el problema.

Un punto pocas veces destacado en los titulares: OpenAI afirmó en el post que no pretende reclamar el premio de US$ 1 millón. El objetivo declarado es demostrar la capacidad del modelo, que la empresa describe como un sistema interno con un desempeño inédito en benchmarks de matemáticas.

Prueba Verificada en Lean: Qué Significa Eso Para Ti

Quien programa entiende Lean mejor que la mayoría de los periodistas. Lean es un lenguaje de programación con un sistema de tipos tan expresivo que una proposición matemática se vuelve un tipo, y una prueba se vuelve un término de ese tipo. Si el código compila, la prueba es correcta respecto de los axiomas y las definiciones usadas. Es el mismo principio que hace que un compilador rechace un string donde se esperaba un number, solo que aplicado a teoremas.

-- Lean 4: una proposición es un tipo, una prueba es un valor de ese tipo.
-- Si este archivo compila, el teorema está probado.
theorem soma_comutativa (a b : Nat) : a + b = b + a := by
  -- 'omega' resuelve aritmética lineal sobre naturales y enteros
  omega

-- Las definiciones equivocadas también compilan: la verificación garantiza
-- coherencia con el enunciado escrito, no con la intención del autor.
theorem exemplo_de_alerta (n : Nat) : n + 0 = n := by
  rfl

La salvedad del segundo bloque importa. Una prueba en Lean garantiza que el enunciado formalizado se deduce de los axiomas. No garantiza que el enunciado formalizado sea el mismo enunciado del premio Clay. Por eso la comunidad quiere leer las cerca de 100 páginas de la prueba en lenguaje humano: alguien necesita verificar que las definiciones de "solución suave", "forzamiento suave" y "energía limitada" coincidan con las de Fefferman. Buckmaster escribió en su nota que se negó a publicar solo un certificado Lean junto a un preprint sin pulir, porque "lo primero que alguien lee debería ser un argumento matemático presentado de la forma normal".

Visualizando un Blowup en Código

No se puede simular Navier-Stokes 3D en un post, pero sí se puede ver el fenómeno en una dimensión con la ecuación de Burgers sin viscosidad, que es el ejemplo clásico de singularidad en tiempo finito. La velocidad se transporta a sí misma, las partes rápidas alcanzan a las lentas y el gradiente se va al infinito en un tiempo previsible.

# Ecuación de Burgers no viscosa: u_t + u * u_x = 0
# Solución por el método de las características: cada punto avanza con velocidad u.
# El gradiente diverge en t* = -1 / min(u0'(x)), el "blowup" en tiempo finito.
import numpy as np

x0 = np.linspace(-np.pi, np.pi, 2001)
u0 = -np.sin(x0)                      # perfil inicial suave
du0 = -np.cos(x0)                     # derivada analítica del perfil
t_star = -1.0 / du0.min()             # instante teórico de la singularidad

for t in [0.0, 0.5 * t_star, 0.9 * t_star, 0.99 * t_star]:
    x = x0 + u0 * t                   # características: x(t) = x0 + u0 * t
    # gradiente a lo largo de las características: u_x = u0' / (1 + u0' * t)
    grad = du0 / (1.0 + du0 * t)
    print(f"t = {t:.3f}  |u_x| máximo = {np.abs(grad).max():.1f}")

print(f"blowup previsto en t* = {t_star:.3f}")

Ejecuta eso y el gradiente máximo crece de 1 a decenas, centenas, y explota al acercarse a t* = 1. En Burgers esto es fácil porque la ecuación es escalar y sin presión. En Navier-Stokes 3D la presión es no local, la viscosidad suaviza y la incompresibilidad acopla las tres componentes. Por eso el problema resistió durante décadas y por eso la ruta del forzamiento suave, que le da al matemático un grado extra de control, fue la que abrió camino.

La Cronología de la Disputa

Los hechos de abajo vienen de la nota pública de Buckmaster, de los reportajes de Quanta, TechCrunch, Fortune y Axios, y de la respuesta de OpenAI. Donde hay contradicción, la marqué.

• Hace cerca de un año: Buckmaster y Alpöge empiezan la colaboración personal, sin acuerdo institucional. Usan Claude, de Anthropic, y Codex, de OpenAI, con los modelos GPT-5.6 Sol y, más tarde, Astra. Buckmaster paga la cuenta con fondos propios de investigación.
• 15 de agosto de 2026: los dos obtienen blowup con forzamiento suave para Boussinesq y para Euler 3D. Buckmaster describe la primera prueba generada por el modelo como "la más horrenda que he leído".
• 22 de agosto: la prueba de Euler es verificada en Lean.
• 1 de septiembre: según la propia OpenAI, empieza el esfuerzo interno, motivado por rumores de que Anthropic estaba cerca de un resultado.
• 3 de septiembre: Buckmaster le escribe a un matemático de OpenAI avisando que el trabajo existe y será publicado en breve. La respuesta ofrece computación y pide detalles "para evitar competir".
• 6 de septiembre: en dos llamadas con Bubeck, Buckmaster es informado de que un modelo interno probó blowup forzado para Navier-Stokes. Según él, se le ofrecieron dos propuestas, ambas condicionadas a sacar a Alpöge de la autoría por trabajar en Anthropic. Él se negó. La nota le atribuye a Bubeck las frases "¿Por qué arruinarías tu carrera?" y "Si no quieres que sea amable, no necesito ser amable".
• 7 de septiembre, medianoche: Buckmaster publica la nota y tres artículos: blowup con forzamiento suave para medios porosos incompresibles, Boussinesq y Euler 3D incompresible.
• 8 de septiembre, por la mañana: OpenAI publica la prueba de Navier-Stokes.

La respuesta de OpenAI tiene dos frases centrales. La primera: "Nosotros (los investigadores y los agentes) no vimos ningún trabajo de ellos por ningún medio hasta que se hizo público". La segunda, sobre datos de uso: "Aunque es improbable, no podemos descartar que datos desidentificados derivados de su uso de nuestros productos hayan ayudado a mejorar nuestros modelos". Bubeck también afirmó que el resultado de Euler se obtuvo por un método totalmente distinto al de Buckmaster y Alpöge, aunque reconoce que el camino hacia Navier-Stokes siguió la misma ruta.

Qué Está en Juego Para Quien Usa Herramientas de IA

Deja las matemáticas de lado por un minuto. Buckmaster y Alpöge hicieron todo el trabajo dentro de sesiones de Codex, incluidos los borradores. Cuando preguntó si el modelo había sido entrenado con esas sesiones, la respuesta fue que el modelo "no consulta datos de usuario". Sobre entrenamiento, dice no haber recibido respuesta. Si usas un asistente de código en un proyecto que todavía no es público, la pregunta es la misma: ¿qué significa "usado para mejorar el modelo" en la práctica, y quién garantiza que el resultado de tu trabajo no reaparezca del otro lado?

Esto no es paranoia de académico. Es la misma discusión que apareció cuando OpenAI lanzó un espacio de trabajo para científicos, que cubrí en OpenAI lanza un espacio de trabajo para científicos con Deep Research. Cuanta más investigación de frontera corre dentro de las herramientas de una empresa que también compite por el descubrimiento, más peso tienen las políticas de retención y entrenamiento. Vale revisar, en tu plan, si las sesiones están excluidas del entrenamiento por defecto y si existe un modo de retención cero.

Un patrón de ingeniería que la historia enseña, independientemente de quién tenga razón, es el del verificador independiente. El enjambre de OpenAI produce candidatos; Lean rechaza lo que no cierra. Es una compuerta determinista delante de un generador probabilístico, y sirve para cualquier pipeline con agentes.

// Patrón generador + verificador: los agentes proponen, un chequeador
// determinista decide. Ninguna propuesta pasa sin aprobación.
type Proposta = { id: string; conteudo: string };
type Veredito = { ok: boolean; motivo?: string };

async function enxame(
  gerar: (semente: number) => Promise<Proposta>,
  verificar: (p: Proposta) => Promise<Veredito>,
  tentativas: number,
): Promise<Proposta | null> {
  // dispara los generadores en paralelo; cada uno recibe una semilla distinta
  const propostas = await Promise.all(
    Array.from({ length: tentativas }, (_, i) => gerar(i)),
  );

  for (const p of propostas) {
    const v = await verificar(p); // acá entra Lean, un test runner, un linter
    if (v.ok) return p;           // la primera propuesta aprobada gana
    console.warn(`proposta ${p.id} rejeitada: ${v.motivo}`);
  }
  return null; // ninguna pasó: mejor fallar que aceptar sin prueba
}

Cambia verificar por tsc --noEmit, por una suite de tests o por un validador de schema y tienes la versión de producción de lo que pasó con Navier-Stokes. La diferencia es la escala: 10 mil generadores, 88 horas y un verificador que no acepta "casi seguro".

Qué Están Diciendo Terence Tao y la Comunidad

Terence Tao, de la UCLA, no entró en la disputa de crédito. Su preocupación, citada por Fortune, es sistémica: la "minería indiscriminada de problemas abiertos en busca de soluciones" puede "destruir el ecosistema a partir del cual se habría desarrollado la próxima generación de técnicas, problemas y practicantes matemáticos". Los problemas abiertos son el material de formación de los doctorandos. Si cada uno de ellos se vuelve blanco de un enjambre de agentes apenas circula un rumor, ¿qué queda para entrenar a la próxima generación?

Buckmaster hace un punto parecido en la nota. Dice que pretendía anunciar sus resultados diciendo que "los resultados no son lo importante"; lo importante sería que un matemático y un modelo ahora logran hacer todo eso en un mes, un "momento Deep Blue contra Kaspárov" para el área. En vez de eso, se vio escribiendo sobre quién llamó a quién. También asume que sus artículos salieron mal escritos por el apuro, llegando a llamar al texto de Euler "AI slop", y pide disculpas por eso.

Quanta llamó al resultado de OpenAI "por un margen significativo, la prueba matemática más importante jamás alcanzada por un modelo de inteligencia artificial hasta hoy". Las dos cosas son verdaderas al mismo tiempo: puede ser el mayor logro de la IA en matemáticas puras y, aun así, haber sido anunciado de una manera que la comunidad considera inaceptable.

Qué Falta Para Que Alguien Gane el Premio

Las reglas del Clay Mathematics Institute son públicas y lentas a propósito. Una solución necesita ser publicada en un medio calificado, quedar disponible por al menos dos años y alcanzar aceptación general en la comunidad matemática antes de que el comité siquiera considere la premiación. Hasta el cierre de este artículo, el instituto sigue listando Navier-Stokes como problema abierto. Incluso si la prueba es correcta, el calendario mínimo empuja cualquier decisión para después de 2028.

Hay además tres verificaciones independientes en marcha. La primera es matemática: especialistas en ecuaciones diferenciales parciales necesitan leer las 100 páginas y confirmar que la formalización en Lean corresponde al problema de Fefferman. La segunda es de prioridad: las fechas de Buckmaster y Alpöge para Euler (15 y 22 de agosto) son anteriores al inicio del esfuerzo de OpenAI (1 de septiembre), y la propia OpenAI acredita a la dupla por el resultado de Euler; la cuestión abierta es el salto de Euler a Navier-Stokes. La tercera es de conducta: OpenAI todavía no dio una respuesta directa sobre si las sesiones de Codex entraron en el entrenamiento.

Para quien construye software, las lecciones son menos glamorosas y más útiles. Un verificador determinista delante de agentes probabilísticos es lo que transforma la fuerza bruta en un resultado confiable. Las políticas de retención de datos de la herramienta que usas forman parte de tu arquitectura, no del área legal. Y el crédito, en ciencia como en open source, es lo que sostiene la próxima contribución; tratarlo como un detalle de negociación sale caro para todo el mundo.

Vamos con todo! 🦅

📚 ¿Quieres Seguir lo Que Viene Por Delante?

Este artículo cubrió la resolución de Navier-Stokes anunciada por OpenAI y la disputa de crédito con Buckmaster y Alpöge, pero el ecosistema cambia todas las semanas y no todo se convierte en artículo acá.

En X comparto lo que estoy probando, los detrás de escena de los proyectos y las novedades que aparecen antes de volverse post.

Sígueme Allá

👉 Seguir a @jeffbruchado en X

💡 Contenido diario sobre desarrollo, carrera y las herramientas que realmente uso