Hay ideas de gestión que suenan a tópico hasta que alguien las coloca en el sitio exacto y de repente explican media industria. La que propone Kirsten Bartok Touw el 9 de julio de 2026 en un hilo de X es una de ellas, y tiene peso por quién la firma: lleva años financiando y analizando el sector aeroespacial y de defensa, es decir, el mundo donde construir hardware complejo es lento, caro y castiga el error con la catástrofe. Su punto de partida es una queja conocida de cualquiera que haya fabricado hardware difícil —el tiempo interminable que se va en test & evaluation (T&E), en probar y validar— y su conclusión es más afilada de lo que parece: SpaceX no ganó simplemente yendo más rápido. SpaceX cambió el papel que juega el test dentro del proceso. Y los grandes contratistas tradicionales, the primes, todavía no la han alcanzado.
De examen final a motor de diseño
El desarrollo clásico de hardware trata el test como un trámite de última fase, una validación que confirma lo que el diseño ya ha decidido. El modelo, dice Bartok, suele ser lineal: requisitos → diseño → análisis → pruebas de subsistema → integración → cualificación formal → ensayo en vuelo → producción. Cada etapa existe para reducir el riesgo antes de que empiece la siguiente. Es un esquema que funciona cuando el fallo es catastrófico, los costes unitarios son enormes y rediseñar cuesta un mundo; pero es también lo que vuelve los programas lentos, caros, frágiles y vulnerables a las sorpresas tardías. El desastre que aparece en el ensayo de vuelo es el peor de todos porque llega cuando ya se ha gastado casi todo.
SpaceX se movió hacia otro modelo, que Bartok resume así: construir muchas cosas → probar muchas → fallar rápido → instrumentarlo todo → rediseñar de inmediato → volver a volar. Eso es parallel test & evaluation. En lugar de esperar a que el sistema completo esté "listo", se prueban en bucles solapados los motores, los tanques, el software, la aviónica, la protección térmica, los sistemas de tierra, las operaciones, el proceso de fabricación y la arquitectura de recuperación. Los propios comunicados de SpaceX sobre Starship describen el programa una y otra vez como un "proceso de desarrollo iterativo rápido", con ensayos de vuelo diseñados para generar datos, tensar los límites, identificar mejoras y demostrar soluciones. El matiz, dicho de otro modo: en la aeroespacial clásica el test es una puerta; en SpaceX es una fábrica de información.
El artículo de test deja de ser una joya
De aquí sale la parte más cultural del argumento, y la más difícil de imitar. En la aeroespacial tradicional el vehículo de pruebas se trata como una joya de la corona porque es carísimo y lentísimo de construir. Esa carestía crea una cultura que intenta eliminar todo el riesgo antes de probar: menos ensayos, más análisis, aprendizaje más lento. SpaceX invirtió el incentivo. Con Starship, el vehículo es en sí mismo una herramienta de aprendizaje. El objetivo no es que cada test "triunfe" en el sentido convencional, sino maximizar el aprendizaje por unidad de tiempo. La compañía ha dicho explícitamente que sus ensayos de vuelo de Starship se miden por lo que aprende, y que "los datos y las lecciones de vuelo" son, en la práctica, la carga útil principal.
Es un cambio profundo. Un test fallido puede seguir siendo un experimento exitoso si cierra la incertidumbre deprisa. Y ese reencuadre reordena todo lo demás: si el artículo de test es desechable, uno puede permitirse probar más; si prueba más, aprende más; si aprende más, el siguiente artículo sale más barato y mejor. La carestía deja de ser una excusa para no probar y pasa a ser el problema de ingeniería que hay que resolver.
Integrar pronto, porque el fallo vive en las costuras
Los programas heredados intentan madurar cada subsistema por separado antes de integrarlo. Pero en el hardware complejo muchos fallos solo aparecen en las interfaces: vibración, cargas térmicas, interacción del penacho de gases, sincronización del software, tolerancias de fabricación, dinámica de fluidos, efectos de la plataforma de lanzamiento, cadencia de operaciones. Bartok usa el primer vuelo de Starship como ejemplo: no reveló solo problemas del vehículo, sino un modo de fallo grave de la propia infraestructura de lanzamiento. Cita un análisis académico de aquel primer vuelo integrado que vinculó la destrucción de la plataforma —con su transporte de escombros y partículas— a un fallo de alta presión bajo la rampa; un problema de nivel de sistema que habría sido muy difícil de entender sin una prueba a escala real.
Ahí está el sentido de la palabra "paralelo": no aprendes solo del cohete, aprendes a la vez del vehículo, de la fábrica, de la rampa, del equipo de tierra, del software, del sistema térmico y del concepto de operación. La organización no está probando hardware; está probando todo su sistema de producción y operación al mismo tiempo.
Fracaso visible para evitar el fracaso oculto
La cultura aeroespacial tradicional intenta evitar el fracaso público. SpaceX lo acepta, porque considera que el fracaso oculto es peor. Si el sistema va a romperse, prefieren que se rompa pronto, instrumentado, y de una forma que enseñe al siguiente diseño. Por eso el programa Starship puede parecer caótico desde fuera y ser disciplinado desde dentro. El público ve explosiones; la organización de ingeniería ve datos de alto ancho de banda. Es la frase que mejor condensa el hilo, y la que da título a este comentario invertido: lo que para la grada es un fallo, para el ingeniero es una medición.
La ventaja no es la velocidad: es el aprendizaje compuesto
Aquí Bartok da el giro que a mí más me interesa. Lo que separa a SpaceX de the primes no es que corra más, sino que acumula aprendizaje. Una compañía que opera en modo lineal obtiene un gran evento de aprendizaje integrado cada pocos años. Una compañía que opera en modo paralelo obtiene cientos o miles de eventos de aprendizaje —repartidos por subsistemas, fabricación, software y operaciones— en el mismo periodo. Y de esa diferencia de cadencia nacen cuatro ventajas estructurales que la autora enumera y que conviene retener:
Primero, el diseño mejora más rápido, porque los datos del mundo real baten a la simulación cuando el sistema es demasiado complejo para modelarlo a la perfección. Segundo, la fabricación mejora a la vez que el diseño: SpaceX no dibuja un vehículo prístino para preguntarse después cómo se fabrica; las restricciones de manufactura forman parte del bucle de test. Tercero, la organización se vuelve mejor recuperándose: cada fallo mejora no solo el hardware, sino el análisis de causa raíz, el utillaje, los procesos de los proveedores, las actualizaciones de software y la respuesta operativa. Y cuarto, cambian las curvas de coste: si puedes construir artículos de test rápido y barato, puedes permitirte probar más, y si pruebas más, aprendes más, y si aprendes más, el siguiente artículo es más barato y mejor. Es un bucle que se retroalimenta.
Un foso construido así tiene una propiedad incómoda para el competidor: se ensancha con el tiempo. No es una patente que caduca ni una ventaja de precio que se erosiona; es una tasa de aprendizaje superior compuesta año tras año. Por eso Bartok insiste en que el método trasciende a los cohetes: es un modelo operativo para sistemas físicos complejos, y la lección para defensa, aeroespacial, autonomía, robótica, fabricación y "hardware AI" no es "vuela cosas por los aires", sino mover la frontera del aprendizaje hacia delante: en vez de esperar a un producto perfecto para exponerlo a la realidad, crear muchos tests seguros, acotados e instrumentados que lo enfrenten al mundo antes.
Por qué esta opinión nos importa en Maya
No es nuestro oficio comprar la narrativa "SpaceX" ni recomendar acciones a golpe de hilo viral. Es construir carteras que sobrevivan a las reescrituras del marco mental dominante, y para eso necesitamos herramientas para juzgar qué ventajas competitivas duran de verdad. La tesis de Bartok es, en el fondo, una teoría de fosos aplicada a la industria pesada, y conecta con cómo pensamos en al menos tres planos.
El foso que no aparece en el balance. El aprendizaje compuesto no se contabiliza: no figura como activo intangible ni como CapEx, pero es lo que hace que dos compañías con el mismo producto diverjan durante una década. Cuando analizamos una empresa industrial, de defensa o de hardware, la pregunta útil no es solo cuánto invierte, sino si ha convertido el test en su motor de diseño o sigue atrapada en el modelo lineal. Es un criterio de "calidad" mucho más exigente —y mucho más predictivo— que un múltiplo.
El riesgo de disrupción del incumbente. "The primes haven't caught up" es una frase con consecuencias para carteras. Los grandes contratistas heredados cotizan como negocios de foso ancho y flujo estable; si un modelo operativo rival aprende un orden de magnitud más rápido, ese foso puede erosionarse sin que el mercado lo perciba hasta tarde. Para el ahorrador indexado, el riesgo relevante no es que la defensa "fracase", sino una recomposición lenta de quién captura el valor dentro del sector.
Distinguir el modelo operativo de su precio. Aquí conviene la misma disciplina que aplicamos siempre: un proceso superior no es una valoración. SpaceX puede tener el mejor motor de aprendizaje del mundo y, aun así, ser una mala inversión al precio equivocado —y buena parte de la exposición a este método llega hoy vía vehículos privados de valoración exigente, fuera del alcance y del perfil de la mayoría de nuestras carteras—. Reconocer la excelencia del método y ser prudentes con el precio no es una contradicción: es exactamente el trabajo.
Hay, además, una lectura reflexiva que me parece la más honesta. El propio método —bucles cortos, acotados, instrumentados, con tolerancia al fallo temprano y visible— es un buen modelo para cómo se ponen a prueba las ideas de inversión. La alternativa lineal —construir una tesis perfecta en la cabeza y jugársela entera de una vez— es justo lo que produce las sorpresas tardías y caras. Preferimos mover nuestra propia frontera de aprendizaje hacia delante: hipótesis medibles, posiciones dimensionadas para que un error enseñe sin herir, y revisión continua. Fallar barato para no fallar caro es tan buena política de cartera como de cohetes.
Apunte metodológico
Conviene separar el dato de la interpretación. Este comentario parte de un hilo de opinión publicado en X, no de un paper revisado por pares ni de un informe institucional; su valor es el de una rejilla conceptual, no el de una prueba. Las afirmaciones fácticas concretas que aquí se recogen —que el primer vuelo integrado de Starship reveló un modo de fallo de la infraestructura de lanzamiento, que un análisis académico lo vinculó a un fallo de alta presión bajo la rampa, o que SpaceX describe sus ensayos como "desarrollo iterativo rápido" cuya carga útil son los datos— son las que sostiene la autora, y las hemos atribuido a ella sin verificarlas de forma independiente ni presentarlas como hechos propios. Tampoco convertimos su tesis en una recomendación sobre ninguna compañía cotizada o privada: la usamos como lente para pensar sobre la durabilidad de las ventajas competitivas, que es el terreno donde de verdad nos jugamos las carteras a largo plazo. La idea que retenemos es sobria y transferible: en los sistemas complejos —una nave, una fábrica o un proceso de inversión— gana quien aprende más rápido y más barato, y quien organiza su trabajo para que cada fallo sea, sobre todo, una medición.