La Voyager no tenía prisa (y por eso sigue funcionando)

Circula una imagen que ya casi todo el que trabaja en tecnología ha visto. De un lado, la Voyager 1: lanzada en 1977, hoy en el espacio interestelar, operando con unos 69 KB de memoria. Del otro, una captura del administrador de tareas: dos pestañas de LinkedIn consumiendo más de 2.4 GB de RAM.

Es un meme, y como todo meme simplifica. Pero no se volvió viral por gracioso, sino porque todos sabemos que tiene algo de verdad.

Casi al mismo tiempo se viralizó, también en LinkedIn, un post en sentido contrario. Un ingeniero de hardware de Meta sostiene que cada generación de ingenieros escribe código más descuidado que la anterior, "y me parece perfecto". Cuenta que en un dispositivo con 4 GB de RAM le dijeron a los equipos que sólo tenían 2 GB, para obligarlos a caber. Que sacaron el producto en ocho meses con agentes de IA generando código a toda velocidad. Y remata: "Voyager tuvo años y un solo intento de lanzamiento; nosotros tenemos meses y un mercado que no espera. Escribe descuidado cuando la velocidad importe; pon el límite antes de que el hardware lo ponga por ti."

La frase suena bien. Tiene el ritmo de una cita para enmarcar en la oficina. El problema es lo que deja fuera.

 

El espejismo del time-to-market

Pasar de 18 a 8 meses es una noticia que cualquier junta directiva aplaude, y con razón: llegar antes al mercado vale dinero, a veces todo el dinero. No vamos a fingir que la velocidad no importa. En Núcleo trabajamos con empresas que pierden ventas cada semana que su sistema no existe; para ellas, esperar un año a la versión perfecta tampoco es ingeniería, es otra forma de fallar.

Pero en esa celebración se mezclan dos cosas distintas: entregar rápido y entregar descuidado. Se presentan como si fueran lo mismo y no lo son.

Entregar rápido es recortar alcance, posponer lo que no es esencial y aceptar una primera versión modesta. Entregar descuidado es otra cosa: aceptar código que nadie entiende del todo, dependencias que nadie eligió a conciencia y consumos de recursos que nadie midió, porque "el hardware lo aguanta". Lo primero es una decisión de producto. Lo segundo es una hipoteca que se firma sin leer.

Y esa hipoteca no aparece en la presentación de los ocho meses. Aparece después: en el tiempo que tarda un ingeniero nuevo en entender por qué algo funciona, en el bug que nadie puede reproducir, en la refactorización que siempre está "para el siguiente trimestre". El código generado rápido no es gratis; sólo se cobra a plazos y a otro equipo.

La paradoja del ejemplo de Meta

La anécdota de los 2 GB escondidos es, irónicamente, el mejor argumento en contra de la tesis del post.

El equipo demostró que el producto cabía en 2 GB. La restricción funcionó: obligó a la gente a pensar, a medir, a elegir. Eso no es descuido; es exactamente la disciplina que el post dice que ya no hace falta.

Y entonces la pregunta obvia: si el software cabe en 2 GB, ¿por qué el chip tiene 4?

Puede haber buenas razones. Margen para el sistema operativo, para actualizaciones futuras, o simplemente que los módulos de memoria vienen en tamaños estándar y 4 GB costaba casi lo mismo. No conocemos los detalles y no vamos a inventarlos. Pero el principio sí merece decirse en voz alta: cuando la respuesta a un código ineficiente es "pon más hardware", ese hardware se fabrica de verdad. En un producto de consumo no se fabrica una vez: se fabrica millones de veces. Cada gigabyte de margen que existe para absorber descuido es silicio, energía de fabricación y, en el caso de la DRAM, consumo continuo para mantener los datos refrescados mientras el dispositivo está encendido.

Multiplicado por millones de unidades, deja de ser un detalle de ingeniería y se vuelve una decisión industrial.

La factura física del software

La industria lleva dos décadas operando bajo un supuesto cómodo: el cómputo es infinito y barato. Si el código es lento, se compra un servidor más grande. Si consume mucha memoria, el siguiente teléfono traerá más. Y ahora, con la IA, se suma otro supuesto: escribir código también es gratis.

Ninguno de los dos es cierto. Lo que pasa es que el costo se desplaza a donde no lo vemos.

El software no vive en "la nube" en un sentido etéreo. Vive en centros de datos que consumen electricidad las 24 horas, que necesitan sistemas de enfriamiento (muchos de ellos con agua) y que se llenan de equipo que hubo que fabricar. Esa fabricación tiene su propio costo, lo que en green computing se llama carbono incorporado (embodied carbon): la energía y los materiales que ya se gastaron antes de que el equipo procese su primera petición. En muchos dispositivos de consumo, ese costo de fabricación pesa tanto como, o más que, toda la energía que consumirán en su vida útil.

Esto no es una postura moral. Es termodinámica básica: cada instrucción que un procesador ejecuta disipa energía, y cada byte que una memoria guarda necesita un circuito físico que alguien fabricó. El código ineficiente no es un problema estético. Es trabajo físico innecesario, repetido miles de millones de veces.

Y lo más incómodo: buena parte de ese trabajo extra no produce nada que el usuario note. Una red social de hoy hace, en esencia, lo mismo que hacía hace quince años: mostrar texto, imágenes y comentarios. La experiencia mejoró en algunas cosas, sin duda. Pero no en proporción a los recursos que ahora consume. Entre lo que el software hace y lo que gasta, la distancia no deja de crecer.

La contraparte: donde la factura duele, la eficiencia regresa

Sería injusto pintar a toda la industria con la misma brocha. Al mismo tiempo que se celebra el código descuidado, ocurre un movimiento en sentido contrario, y viene justo de los lugares donde la ineficiencia se paga en serio.

El ejemplo más claro está en el propio ecosistema de JavaScript. Durante años, las herramientas para compilar, empaquetar y revisar código JavaScript se escribieron en JavaScript. Funcionaba, hasta que los proyectos crecieron lo suficiente como para que cada build tardara minutos. La respuesta fue reescribir esas herramientas en lenguajes compilados: esbuild en Go; SWC, Turbopack, Rspack, Biome y Rolldown (el nuevo empaquetador de Vite) en Rust. En Python pasó lo mismo con Ruff y uv, también en Rust.

El caso más simbólico es el de TypeScript. En 2025, Microsoft anunció que está portando el compilador de TypeScript, un lenguaje que existe para escribir mejor JavaScript, a Go, y reportó builds alrededor de diez veces más rápidos en proyectos grandes. Un detalle revelador: eligieron Go no por ser el lenguaje más rápido posible, sino porque su estructura les permitía trasladar el código existente casi línea por línea. No fue una reescritura por moda; fue una decisión de ingeniería con el menor riesgo posible.

En infraestructura, el patrón se repite. Discord documentó cómo migró un servicio crítico de Go a Rust porque las pausas del recolector de basura provocaban picos de latencia que, a su escala, se notaban. AWS construyó en Rust Firecracker, la tecnología de micro máquinas virtuales sobre la que corre Lambda, precisamente porque cada megabyte de memoria y cada milisegundo de arranque se multiplica por millones de ejecuciones.

La lección no es "reescribe todo en Rust". Es otra, más incómoda: la eficiencia vuelve a importar en el momento exacto en que alguien tiene que pagar la factura. Cuando el costo lo absorbe el proveedor (en sus servidores, en sus builds, en su nube), se optimiza sin pensarlo dos veces. Cuando el costo se reparte entre millones de usuarios (en su batería, en su RAM, en su próximo teléfono), se vuelve invisible y se celebra el descuido.

Los mismos ingenieros que escriben herramientas en Rust para ahorrar segundos de compilación entregan aplicaciones que consumen gigabytes en el dispositivo del usuario. No es falta de conocimiento. Es que la ineficiencia sólo se corrige cuando le duele a quien decide.

Aquí conviene matizar algo. Es tentador leer todo esto como una historia de pasión contra lucro: los artesanos que reescriben en Rust por amor al oficio frente a las corporaciones que sólo buscan ganancias. No es tan simple. Muchas de estas herramientas sí nacieron del oficio de una persona o de un equipo pequeño (esbuild empezó como el proyecto de un solo ingeniero), y ese cuidado se nota. Pero casi todas sobrevivieron y crecieron porque detrás había un incentivo económico que las sostenía. Y la propia Meta, cuando el costo cae en sus centros de datos, optimiza con enorme rigor: creó HHVM para abaratar sus servidores de PHP, Hermes para que React Native corra en teléfonos con poca memoria y el compresor Zstandard. La diferencia no está en quién ama más el código. Está en a quién le llega la factura: cuando le llega a quien decide, el oficio se vuelve buen negocio; cuando se reparte entre millones de usuarios, el descuido sale gratis para quien lo produce.

Pragmatismo no es lo mismo que pereza

Conviene ser justos con la Voyager. Su software no es admirable porque sus ingenieros fueran más virtuosos que los de hoy, sino porque no tenían opción. La memoria era carísima, el procesador era lento y no había manera de mandar un técnico a 20 mil millones de kilómetros. La restricción era física y absoluta.

Y aun así, esa restricción produjo algo que vale la pena mirar. En 2024, casi medio siglo después del lanzamiento, un chip de la computadora de la Voyager 1 falló y la nave empezó a mandar datos ilegibles. El equipo de la NASA no tenía repuesto ni forma de tocar el hardware. Lo que hizo fue entender el código lo bastante bien como para reubicarlo, por partes, en otras zonas de la memoria y recuperar la nave. Eso sólo es posible cuando alguien, décadas antes, escribió un sistema que se podía entender.

Ésa es la diferencia que importa. No se trata de escribir todo en ensamblador ni de optimizar cada ciclo. Se trata de que alguien, en algún momento, sepa qué hace el sistema y por qué.

Usar IA para generar código no tiene nada de malo. Nosotros la usamos todos los días: para borradores, para pruebas, para el trabajo repetitivo que no necesita criterio. El problema no es la herramienta. El problema empieza cuando la herramienta se vuelve una excusa para dejar de revisar, de medir y de decidir. Un agente puede generar mil líneas en un minuto; lo que no puede hacer es responder por ellas cuando fallan un viernes en la noche.

El pragmatismo dice: esta parte no importa tanto, la resolvemos rápido y seguimos. La pereza dice: nada importa tanto, el hardware lo aguanta. El primero es criterio. El segundo es renunciar a él.

Menos grasa, más ingeniería

La frase del post de Meta tiene una mitad que suscribimos completa: pon el límite antes de que el hardware lo ponga por ti. Es un buen principio. Sólo que la conclusión correcta no es "escribe descuidado". Es la contraria: los límites existen para que pienses, no para que encuentres la forma de esquivarlos.

En Núcleo construimos sistemas para empresas que no tienen el presupuesto de Meta, y quizás por eso lo vemos con más claridad. Para un negocio mediano, cada recurso desperdiciado se nota: un servidor más grande, una licencia más, un sistema que nadie se atreve a tocar porque nadie entiende cómo funciona. Ahí no hay a quién trasladarle la factura. La eficiencia no es una virtud abstracta: es dinero que se queda en la empresa en lugar de irse a la nube. Por eso, en nuestro caso, el oficio y el negocio apuntan en la misma dirección.

Creemos que el software sobrio, el que hace lo que tiene que hacer, consume lo que necesita y se puede explicar, no es nostalgia de otra época. Es responsabilidad económica y de producto:

• Medir antes de escalar. Si algo es lento, primero se entiende por qué; después, si hace falta, se compra más hardware.
• Entregar rápido recortando alcance, no criterio. Una primera versión pequeña y sólida vale más que una grande que nadie puede mantener.
• Elegir la herramienta por el cuello de botella, no por la moda. No todo necesita Rust; pero cuando una parte del sistema se repite millones de veces, esa parte merece el lenguaje y el diseño adecuados.
• Usar la IA para acelerar, no para dejar de pensar. Todo código que entra a producción tiene a alguien que lo entiende y responde por él.
• Diseñar para durar. El sistema que construyes hoy lo va a mantener alguien dentro de cinco años, quizás tú mismo, y debería poder leerlo.

La Voyager lleva casi cincuenta años funcionando con menos memoria de la que usa hoy un ícono de tu escritorio. No porque sus ingenieros tuvieran más tiempo, sino porque tenían algo que hoy escasea: la obligación de saber exactamente qué estaban construyendo.

Esa obligación ya no nos la impone el hardware. Hoy la tenemos que elegir.

¿Tu sistema creció a base de parches y ya nadie sabe bien cómo funciona? Platiquemos por WhatsApp →