Un motor de cohete de combustible líquido fue diseñado por software, impreso en cobre y encendido con éxito en un banco de pruebas.

La frase parece el comienzo de una historia de ciencia ficción. No lo es.

En junio de 2024, un equipo de la University of Sheffield probó un pequeño motor de cohete generado por Noyron, el modelo de ingeniería computacional de LEAP 71. La universidad afirma que el diseño fue producido autónomamente, sin intervención humana durante esa ejecución concreta, que el motor se imprimió en cobre y que funcionó en su primera campaña de hot-fire.

Pero hay una diferencia importante entre ese hecho y la versión más espectacular de la historia: “la IA ya es mejor ingeniera de cohetes que los humanos”.

Esa conclusión todavía no está demostrada.

Lo que sí está ocurriendo es quizá más interesante: una parte del conocimiento de ingeniería que antes vivía en la cabeza de especialistas, hojas de cálculo, simuladores y procesos CAD está empezando a convertirse en lógica ejecutable capaz de producir geometría física directamente.

Y cuando esa geometría puede pasar casi de inmediato a una impresora 3D de metal, el cuello de botella del proceso cambia.

Este artículo parte del video El mejor ingeniero de cohetes del mundo no es humano, contrasta sus afirmaciones principales con fuentes técnicas y separa tres cosas que suelen mezclarse bajo la palabra “IA”:

  1. modelos de lenguaje;
  2. ingeniería computacional basada en física;
  3. ciclos automatizados de diseño, fabricación, prueba y aprendizaje.

La tercera es la que podría transformar de verdad la ingeniería.

La historia que sí está documentada

El 28 de junio de 2024, la University of Sheffield publicó los resultados de una prueba realizada junto a LEAP 71 y otros colaboradores.

Su descripción es bastante concreta:

  • el motor fue diseñado usando Noyron, el Large Computational Engineering Model de LEAP 71;
  • el diseño se produjo autónomamente durante la ejecución del modelo;
  • el componente fue fabricado mediante impresión 3D en cobre;
  • desde la especificación final hasta la fabricación transcurrieron menos de dos semanas;
  • una nueva iteración del diseño puede generarse en minutos;
  • el motor pasó una campaña de encendido en caliente con éxito.

La universidad también deja claro algo que a veces desaparece en los titulares: sus ingenieros aportaron feedback práctico durante el desarrollo del código de Noyron.

Es decir, no apareció una inteligencia artificial de la nada, leyó internet y descubrió por sí sola cómo construir un motor.

La secuencia real se parece mucho más a esto:

conocimiento humano de ingeniería
        ↓
física + reglas + restricciones de fabricación
        ↓
modelo computacional Noyron
        ↓
especificación del motor
        ↓
geometría fabricable
        ↓
impresión 3D en metal
        ↓
hot-fire
        ↓
datos experimentales
        ↓
refinamiento del modelo

Esa diferencia semántica importa porque nos dice qué tipo de automatización está avanzando.

Noyron no es ChatGPT para CAD

Cuando escuchamos “IA diseñó un motor”, la intuición moderna es imaginar algo parecido a esto:

Prompt: "Diseña un motor de cohete de 5 kN"
                 ↓
              modelo
                 ↓
            archivo CAD

No es una buena descripción de Noyron.

LEAP 71 lo presenta como un modelo de ingeniería computacional. Su objetivo es codificar conocimiento de primeros principios y lógica de ingeniería: termodinámica, dinámica de fluidos, transferencia de calor, materiales, geometría y restricciones asociadas a cómo se va a fabricar la pieza.

Esto cambia la naturaleza del problema.

Un LLM opera principalmente sobre representaciones aprendidas de grandes cantidades de datos y produce secuencias probabilísticas. Un sistema como Noyron intenta convertir una intención de ingeniería en un objeto físico coherente aplicando reglas y modelos que tienen significado físico explícito.

Una simplificación útil sería:

LLM
texto/datos → representación aprendida → texto/código/acciones

Noyron
requisitos → física + ingeniería + manufactura → geometría física

No significa que una arquitectura sea “más inteligente” que la otra. Significa que resuelven problemas distintos.

Para un motor de cohete no basta con que la forma parezca correcta.

Debe sobrevivir simultáneamente a:

  • presiones elevadas;
  • temperaturas de miles de grados en la combustión;
  • flujos criogénicos;
  • gradientes térmicos extremos;
  • vibración;
  • restricciones de material;
  • espesores mínimos que una impresora pueda fabricar;
  • canales internos por los que debe circular refrigerante;
  • tolerancias reales del proceso de manufactura.

Un render bonito no sirve.

El resultado tiene que obedecer a la física y luego sobrevivir cuando se abre la válvula.

Por qué la impresión 3D es la pieza que hace posible el salto

Hay otra razón por la que esta historia está ocurriendo ahora y no hace veinte años: la fabricación aditiva eliminó muchas de las restricciones geométricas que definían el diseño tradicional.

En manufactura convencional, el ingeniero no diseña únicamente aquello que sería físicamente óptimo. Diseña también aquello que puede mecanizarse, fundirse, soldarse y ensamblarse a un coste razonable.

Eso introduce restricciones como:

¿puede entrar una herramienta aquí?
¿podemos perforar ese canal?
¿cuántas soldaduras necesitamos?
¿cómo ensamblamos estas piezas?
¿podemos inspeccionar la unión?

La impresión 3D de metal cambia el espacio de soluciones.

NASA explica, por ejemplo, que piezas que tradicionalmente podían requerir cientos de componentes soldados pueden reducirse a una o dos piezas impresas. Esa integración no es solo estética: reduce operaciones, interfaces, posibles puntos de fallo y tiempos de fabricación.

SpaceX ya imprimía cámaras SuperDraco hace una década

NASA documentó en 2015 que las cámaras de los motores SuperDraco de Crew Dragon eran impresas en 3D.

Esto es importante porque muestra que la fabricación aditiva en propulsión no nació con la actual ola de IA.

La base industrial llevaba años madurando.

Rocket Lab industrializó el enfoque con Rutherford

Rocket Lab describe el Rutherford como un motor cuyos componentes primarios pueden imprimirse en unas 24 horas.

La empresa llevó esa idea a producción repetitiva y vuelo orbital.

Ya no hablamos de una pieza experimental que se enciende una vez en un laboratorio. Hablamos de una cadena de producción real para un lanzador comercial.

Relativity llevó la idea al vehículo completo

NASA señala que Terran 1 era aproximadamente 85% impreso en 3D por masa, incluyendo cuerpo y motores.

El vuelo de marzo de 2023 no consiguió colocar su carga en órbita, pero Relativity confirma que el vehículo atravesó Max-Q, el punto de máxima carga aerodinámica.

Eso importa porque prueba algo distinto: un cohete construido en gran medida mediante fabricación aditiva puede sobrevivir a una parte extremadamente exigente del vuelo real.

La conclusión no es que imprimir sea automáticamente mejor.

La conclusión es que la fabricación ha ganado suficiente libertad geométrica para aceptar diseños que un algoritmo puede explorar mucho más agresivamente que un proceso CAD condicionado por herramientas tradicionales.

Del CAD a una función ejecutable

Aquí está la diferencia conceptual que más me interesa.

Un diseño CAD tradicional puede verse como un artefacto.

Un modelo como Noyron intenta convertir el proceso que produce ese artefacto en una función.

Conceptualmente:

engine = design(
    propellant="LOX/RP-1",
    thrust=5000,
    chamber_pressure=...,
    material="CuCrZr",
    manufacturing="LPBF",
    boundary_conditions=...
)

La función no contiene simplemente un modelo tridimensional congelado.

Contiene la lógica que permite producir una familia de motores.

Por eso la afirmación de Sheffield de que una nueva iteración puede tardar minutos es más importante que el dato llamativo de que el primer motor funcionara.

Si el diseño fuera únicamente un archivo CAD creado rápidamente, tendríamos una automatización puntual.

Si lo que existe es una función generalizable que puede regenerar la geometría al cambiar empuje, propelente, presión, material o restricciones, entonces tenemos algo parecido a software de ingeniería generativo basado en física.

Y el software puede ejecutarse otra vez.

Y otra.

Y otra.

El aerospike: una prueba bastante más interesante

LEAP 71 no se quedó en el pequeño motor convencional.

El 18 de diciembre de 2024 probó en Westcott, Reino Unido, un aerospike de 5 kN alimentado con oxígeno líquido y queroseno. La compañía afirma que fue generado autónomamente por Noyron, impreso como una pieza monolítica de aleación de cobre y que funcionó en el primer intento.

¿Por qué esto llama la atención?

Un motor convencional utiliza una tobera con forma de campana optimizada para un rango de presión ambiental. A medida que el vehículo asciende, la presión exterior cambia de forma dramática.

El aerospike intenta adaptarse mejor a diferentes altitudes mediante una geometría que permite que el flujo de escape se expanda contra la atmósfera circundante.

El atractivo existe desde hace décadas.

El problema también.

El spike central está expuesto directamente a gases de combustión extremadamente calientes y necesita una refrigeración complicada. LEAP 71 diseñó una estructura con canales internos en la que el oxígeno criogénico ayuda a refrigerar esa región.

Este es precisamente el tipo de geometría donde se juntan las dos piezas de la revolución:

geometría difícil para humanos/CAD convencional
                    +
canales internos difíciles de mecanizar
                    ↓
ingeniería computacional + impresión 3D metálica

No demuestra que el problema del aerospike esté “resuelto”.

Demuestra que la combinación permite recorrer espacios de diseño que antes eran caros de explorar.

Y después llegó una prueba que hace la historia más creíble, no menos

En diciembre de 2025, LEAP 71 anunció pruebas de dos motores methalox de 20 kN generados por Noyron: uno convencional con tobera de campana y otro aerospike.

El motor convencional alcanzó régimen estacionario a la presión y empuje nominales, según la compañía.

El aerospike, en cambio, encontró problemas durante los transitorios de arranque y solo pudo realizar una combustión, aunque llegó a presión completa de cámara.

Este detalle es muy valioso porque desmonta una narrativa demasiado perfecta.

La ingeniería real se parece a esto:

modelo
  ↓
prototipo
  ↓
prueba
  ↓
problema inesperado
  ↓
datos
  ↓
modelo actualizado
  ↓
nueva iteración

No a esto:

IA mágica → diseño perfecto → fin de la ingeniería

Que aparezcan fallos al escalar es exactamente lo esperable.

El valor del enfoque estará en cuánto reduce el coste temporal y económico de aprender de esos fallos.

“Sin intervención humana” necesita una nota al pie grande

Hay dos afirmaciones que pueden ser ciertas al mismo tiempo:

Noyron generó autónomamente la geometría de un motor concreto.

Y:

Noyron existe gracias a una enorme cantidad de ingeniería humana.

No hay contradicción.

Los humanos:

  • diseñaron el modelo;
  • seleccionaron las ecuaciones y aproximaciones;
  • decidieron qué variables importan;
  • codificaron reglas de fabricación;
  • desarrollaron el proceso de impresión;
  • prepararon el hardware;
  • instrumentaron el banco;
  • definieron los criterios de éxito;
  • interpretaron datos experimentales;
  • modificaron el sistema a partir de esos datos.

La autonomía aparece dentro de una frontera concreta del proceso.

Podemos visualizarlo así:

┌───────────────────────────────────────────────────────┐
│                  SISTEMA HUMANO                       │
│                                                       │
│  física → reglas → materiales → proceso → validación │
│                       │                               │
│                       ▼                               │
│              ┌────────────────┐                       │
│              │     NOYRON     │                       │
│              │                │                       │
│ requisitos ─▶│ ejecución de   │─▶ geometría          │
│              │ diseño autónoma│                       │
│              └────────────────┘                       │
│                       │                               │
│                       ▼                               │
│            fabricación + prueba + datos              │
└───────────────────────────────────────────────────────┘

Decir “ningún humano diseñó ese motor” puede ser correcto si hablamos de la ejecución de diseño.

Decir “los humanos ya no son necesarios para diseñar motores” sería una conclusión que la evidencia no sostiene.

Project Prometheus confirma que la idea va mucho más allá de cohetes

El otro elemento del video que parecía exagerado también resultó tener bastante sustancia.

Project Prometheus, cofundada por Jeff Bezos y Vik Bajaj, comenzó con unos 6.200 millones de dólares de financiación y en 2026 anunció una ronda de 12.000 millones, a una valoración de 41.000 millones.

Bezos ha descrito públicamente el objetivo como construir un “artificial general engineer”.

No se refiere simplemente a otro chatbot.

La ambición es aplicar modelos a la creación de objetos físicos y comprimir procesos de diseño y manufactura que hoy requieren equipos grandes y ciclos que pueden durar años.

Bezos lo comparó, simplificando, con una versión radicalmente moderna de CAD.

La existencia de Prometheus no prueba que esa visión vaya a funcionar.

Sí demuestra que el mercado está empezando a tratar la automatización del conocimiento de ingeniería física como una categoría propia, suficientemente importante para atraer decenas de miles de millones de dólares.

Eso acerca el tema a lo que suele llamarse Physical AI, aunque el término engloba muchas tecnologías diferentes.

SpaceX: de “prácticamente nada de IA” a infraestructura interna

Hay otro contraste interesante.

En mayo de 2024, Elon Musk dijo públicamente que SpaceX y Starlink utilizaban “basically no AI” porque las herramientas disponibles no eran especialmente útiles para sus necesidades.

Dos años después, las ofertas de empleo de SpaceX muestran un panorama muy distinto.

La compañía busca ingenieros para una plataforma interna de inferencia de alto rendimiento y describe un equipo llamado SpaceX Internal AI Infrastructure. También publica puestos de Applied AI destinados explícitamente a diseñar, evaluar, desplegar e integrar modelos de lenguaje y sistemas agénticos en productos e infraestructura de SpaceX.

Además, en julio de 2026 Musk afirmó públicamente que el gran corpus interno de datos de ingeniería de SpaceX —exceptuando material restringido por ITAR— se incorporaría al entrenamiento suplementario de Grok.

La dirección estratégica es clara:

2024
IA actual → poca utilidad para SpaceX

2026
modelos + agentes + infraestructura interna
         +
conocimiento institucional de ingeniería
         ↓
herramientas integradas en workflows reales

Eso no significa que Grok vaya a diseñar Raptor de forma autónoma mañana.

Significa que uno de los activos más valiosos de SpaceX —años de decisiones, pruebas, fallos, telemetría y conocimiento acumulado— empieza a tratarse como capital legible por máquinas.

El verdadero cambio: cerrar el loop

Hasta ahora hemos hablado de piezas separadas.

La hipótesis potente aparece cuando se conectan:

     requisitos
         │
         ▼
┌────────────────────┐
│ modelo de ingeniería│
└─────────┬──────────┘
          │
          ▼
      geometría
          │
          ▼
┌────────────────────┐
│ impresión 3D metal │
└─────────┬──────────┘
          │
          ▼
       hot-fire
          │
          ▼
      sensores/datos
          │
          ▼
┌────────────────────┐
│ análisis y modelos │
└─────────┬──────────┘
          │
          └───────────────► siguiente iteración

SpaceX hizo famosa una cultura de build → test → fail → learn → repeat con humanos coordinando el ciclo a gran velocidad.

La pregunta nueva es qué ocurre cuando partes crecientes de ese ciclo pueden ejecutarse computacionalmente.

Un ingeniero puede tardar días o semanas en reconstruir un CAD, rehacer análisis térmico, modificar canales, comprobar manufacturabilidad y preparar documentación.

Una función de ingeniería puede volver a ejecutarse.

La impresora puede fabricar una variante sin reconstruir moldes o utillaje.

El banco de pruebas puede capturar miles de señales.

Un sistema de software puede incorporar esos datos a la siguiente decisión.

El salto económico potencial no está únicamente en “quitar personas”.

Está en aumentar brutalmente el número de ciclos de aprendizaje que un equipo puede completar por unidad de tiempo.

De dos iteraciones al año a cien al día

El video utiliza una comparación provocadora: un humano podría iterar un diseño unas pocas veces, mientras un modelo podría hacerlo cientos de veces.

La cifra concreta depende por completo del problema. Pero la intuición sí es relevante.

En ingeniería tradicional, cada iteración arrastra costes de coordinación:

cambio de requisito
→ reunión
→ CAD
→ análisis
→ revisión
→ manufactura
→ inspección
→ prueba
→ informe
→ nueva reunión

Si parte de ese conocimiento está codificado, algunos pasos dejan de ser actividades manuales y se convierten en ejecución reproducible.

Esta transformación se parece mucho a lo que ocurrió en software con CI/CD.

Antes:

código → integración manual → build manual → release

Después:

commit → pipeline → tests → artifact → deploy

En ingeniería física podríamos estar viendo los primeros bloques de algo equivalente:

spec → modelo → geometría → manufacturing → test → telemetry

La analogía no es perfecta porque los átomos son mucho más caros que los bits.

Un test de cohete consume propelente, degrada hardware, necesita instalaciones, protocolos de seguridad y tiempo real de fabricación.

Pero precisamente por eso eliminar semanas de trabajo entre dos pruebas puede tener un impacto enorme.

Lo que todavía NO está demostrado

Conviene poner límites claros porque el área es especialmente propensa a titulares grandiosos.

1. Un motor de 5 o 20 kN no es un Raptor

Escalar un motor no consiste en multiplicar dimensiones.

Aparecen problemas distintos de combustión, refrigeración, estabilidad, alimentación, turbomaquinaria, vibraciones, acústica y estructura.

Que Noyron pueda diseñar pequeños thrusters funcionales no demuestra todavía que pueda producir autónomamente un motor orbital de millones de newtons.

2. Hot-fire no equivale a calificación de vuelo

Un encendido exitoso es una señal importante.

Pero un motor de vuelo debe sobrevivir múltiples condiciones, márgenes, ciclos térmicos, vibraciones, tolerancias de manufactura, aceptación y requisitos de fiabilidad.

3. La fabricación sigue introduciendo realidad

Incluso un diseño matemáticamente correcto puede fallar por:

  • porosidad;
  • rugosidad interna;
  • tratamiento térmico;
  • deformación durante impresión;
  • tolerancias;
  • contaminación;
  • inspección imperfecta.

El modelo necesita conocer no solo la física ideal, sino la estadística del proceso industrial real.

4. El loop todavía no es completamente autónomo

Hoy podemos observar componentes del ciclo automatizados.

No tenemos evidencia pública de una cadena general donde un sistema:

detecta el fallo
→ diagnostica la causa
→ modifica su modelo físico
→ diseña la corrección
→ manda fabricar
→ ejecuta la prueba
→ decide si acepta el resultado

sin supervisión humana significativa.

Ese sería un salto mucho mayor.

5. El conocimiento codificado también puede codificar errores

Una función de ingeniería reproduce sus supuestos con una consistencia extraordinaria.

Eso es una ventaja cuando los supuestos son correctos.

Y un riesgo cuando no lo son.

La automatización no elimina la necesidad de validación independiente; puede hacerla más importante.

El activo más importante puede dejar de ser el CAD

Durante décadas, una empresa de ingeniería acumulaba valor en:

  • planos;
  • archivos CAD;
  • simulaciones;
  • procedimientos;
  • hojas de cálculo;
  • documentación;
  • y, sobre todo, experiencia tácita de sus ingenieros.

El nuevo paradigma intenta llevar una parte de ese valor a modelos ejecutables.

Eso cambia lo que significa propiedad intelectual.

El activo ya no sería solamente:

motor_v37_final_FINAL.step

Podría ser:

motor_model_v37(specification) → manufacturable_engine

El primero describe un objeto.

El segundo describe una capacidad de generar objetos.

Esa diferencia es enorme.

Una nueva versión del “software is eating the world”

Durante años, la digitalización consistió principalmente en convertir procesos administrativos o informativos en software.

Después los modelos generativos empezaron a producir texto, imágenes, audio y código.

La frontera que muestran Noyron y proyectos similares es distinta:

el software empieza a producir directamente decisiones de ingeniería que terminan convertidas en metal.

No estamos hablando solo de un copiloto que recomienda qué botón pulsar en CAD.

Estamos hablando de transformar parte del acto de diseñar en una función computable.

Y ese cambio puede extenderse mucho más allá de cohetes:

  • intercambiadores de calor;
  • turbinas;
  • motores eléctricos;
  • sistemas de refrigeración;
  • componentes estructurales;
  • semiconductores;
  • química y materiales;
  • maquinaria industrial.

Cuanto más compleja sea la interacción entre física, geometría y fabricación, mayor puede ser el valor de encapsular esa lógica en un modelo reutilizable.

Entonces, ¿es Noyron “el mejor ingeniero de cohetes del mundo”?

No tenemos evidencia para decirlo.

No ha diseñado y operado un sistema comparable a los motores de mayor empuje y madurez del sector. No posee décadas de historial de vuelo. No ha demostrado que pueda sustituir a un equipo completo de propulsión.

Pero esa no es la comparación útil.

La comparación útil es esta:

¿Qué ocurre cuando un buen equipo de ingeniería puede convertir una parte creciente de su conocimiento en un modelo ejecutable que genera nuevas soluciones en minutos?

Ahí sí estamos ante algo real.

Sheffield verificó un motor funcional generado por Noyron. LEAP 71 avanzó después hacia aerospikes y motores methalox de mayor empuje. NASA, Rocket Lab y Relativity muestran que la manufactura aditiva ya es suficientemente madura para llevar geometrías complejas al hardware real. Bezos está financiando una apuesta gigantesca por un “ingeniero general artificial”. Y SpaceX, que en 2024 decía utilizar prácticamente nada de IA, hoy construye infraestructura interna para modelos y agentes.

Por separado, cada señal es interesante.

Juntas apuntan a una transición más profunda:

ingeniería como documento
        ↓
ingeniería como software
        ↓
ingeniería como loop ejecutable

El futuro no tiene por qué ser una IA sentada en la silla del ingeniero.

Puede ser algo bastante más radical: equipos humanos diseñando los sistemas que diseñan las máquinas.

Y en ese mundo, la métrica importante no será quién dibuja la pieza.

Será quién consigue construir el mejor ciclo de aprendizaje entre modelo, metal y realidad.

Fuentes