“Unikernels were hard. Key word: were. Now we have AI.”
En octubre de 2026, Geoffrey Huntley sentenció esta frase durante una conversación técnica. Al otro lado de la mesa se encontraba Justin Cormack, uno de los primeros desarrolladores clave de MirageOS. Diez años atrás, para ejecutar aplicaciones directamente sobre máquinas virtuales, el equipo tuvo que extraer controladores de NetBSD y portar a mano miles de líneas de código C de bajo nivel al espacio de usuario.
Un unikernel adopta una arquitectura de espacio de direcciones único: la propia aplicación es el sistema operativo. En la imagen no existen procesos aislados ni un shell interactivo. Si los desarrolladores necesitan enviar paquetes de red o resolver nombres de dominio, no pueden apoyarse en un entorno anfitrión. Todos los controladores y pilas de protocolos deben compilarse directamente dentro del binario.
Durante la última década, las empinadas barreras de las cadenas de herramientas y la falta de ecosistema relegaron esta tecnología a un segundo plano. Hoy en día, los modelos de lenguaje han eliminado el coste de programar bibliotecas a medida. Sin embargo, abaratar el desarrollo no ha resuelto los dilemas de seguridad inherentes a su diseño.
Figura: Ilustración conceptual que representa un unikernel como un núcleo digital minimalista. Fuente: ghuntley.com
Los pesos del modelo asumen la carga de escribir controladores a mano
Desde la perspectiva de Huntley, la industria del software ha estado encadenada durante años a una serie de dogmas técnicos: Nix es difícil, Bazel es difícil y los unikernels son difíciles. Estas dificultades eran, en el fondo, meras barreras de conocimiento levantadas por detalles de implementación.
Los pesos de los modelos han asimilado la teoría de tipos y décadas de literatura académica. La infraestructura de bajo nivel que antes exigía meses de trabajo ahora está al alcance de unos pocos prompts. Los ingenieros experimentados ya no necesitan transcribir controladores en C línea por línea.
Huntley tardó solo una semana en construir el prototipo de Spaceleans. Portó el sistema de actores virtuales distribuidos Orleans de Microsoft a OCaml, empaquetándolo en una imagen de unikernel. El sistema fusiona múltiples máquinas físicas en un único heap direccionable donde las instancias de actores pueden rehidratarse desde el almacenamiento bajo demanda.
Para poner en marcha el prototipo, tuvo que levantar todo el entorno de ejecución desde cero. Apoyándose en la generación de código, completó una pila de red, un resolver DNS y un cliente HTTP en solo siete días. Posteriormente añadió sincronización horaria por NTP, clientes para LLM y trazabilidad distribuida. Una labor de fontanería de sistemas que antes exigía un equipo completo fue ensamblada por un solo desarrollador en cuestión de días.
La objeción histórica sobre la falta de ecosistema se desvanece ante la síntesis de código. Antes se descartaban los unikernels por carecer de SDKs de terceros, como pasarelas de pago maduras en OCaml. Con bucles de agentes automatizados, los modelos reescriben bibliotecas de Go a módulos funcionales de OCaml en cuestión de horas.
Replicar cadenas de herramientas a medida en horas con Rust
Cormack experimentó una evolución similar en su propia práctica de ingeniería. Al construir imágenes de Linux para aplicaciones únicas, buscaba una reducción extrema del tamaño. Tradicionalmente, formatear un disco requería empaquetar toda la suite xfsprogs dentro de la imagen solo para ejecutar un único comando.
En su lugar, optó por encargar a un modelo la creación de una utilidad mkfs.xfs dedicada en Rust. La herramienta nativa sirvió como oráculo de referencia (golden oracle): el código generado se contrastó byte por byte con la salida original y superó pruebas con diversos tamaños de bloque. El procesamiento de parámetros y la escritura de las estructuras en disco se completaron en apenas unas horas.
Este flujo de trabajo transforma de raíz la producción de herramientas de sistemas. Antes, podar utilidades básicas suponía una pesada carga de mantenimiento, obligando a los equipos a convivir con espacios de usuario inflados. La combinación de generación de código y pruebas diferenciales contra oráculos reduce el coste de personalización a un nivel casi insignificante.
La infraestructura moderna nativa de la nube ha relajado aún más los requisitos de los sistemas de archivos locales. Arquitecturas como turbopuffer tratan el almacenamiento de objetos en la nube como capa primaria de persistencia, relegando los discos NVMe locales a cachés de bloques y políticas de desalojo. Al delegar la durabilidad en la nube, ya no se necesitan complejos sistemas de archivos transaccionales en local, permitiendo gestionar grandes volúmenes de estado sobre almacenes de objetos.
Figura: Portada del vídeo de la conversación «Unikernels in 2026». Fuente: YouTube / Canal de Geoffrey Huntley
Desprenderse del sistema operativo no elimina la superficie de ataque
Con la reducción de las barreras técnicas, la controversia en torno a la seguridad se ha vuelto aún más patente. Huntley sostiene que los sistemas operativos multiusuario son reliquias de la era de los terminales tontos. Los servicios dedicados no necesitan interfaces de usuario genéricas; sin un shell ni intérpretes del sistema, los atacantes carecen de plataforma para movimientos laterales y los escaneos masivos pierden su objetivo.
Sin embargo, Cormack expresó reservas inmediatas. Señaló que el mantra de la comunidad sobre la «reducción de la superficie de ataque» lleva años reducido a un eslogan simplista. Eliminar /bin/sh de un contenedor es trivial, pero el entorno de ejecución sigue conservando capacidades completas de interpretación. Aunque se bloquee la escritura en disco, la corrupción de memoria y las cadenas ROP pueden secuestrar igualmente el flujo de ejecución del programa.
Huntley reconoció que los diseños originales ubicaban la aplicación y el kernel en el mismo anillo de privilegios. No obstante, argumentó que en 2026 reincorporar el aislamiento de anillos está a «la distancia de un prompt», y que en cualquier caso sigue siendo más seguro que limitarse a rezar para que la configuración de cgroups en systemd sea correcta. Cormack no insistió más en ese punto, manteniendo su foco en cómo se trivializa el concepto de superficie de ataque.
Incluso el aislamiento a nivel de hipervisor entraña riesgos reales de fuga. La misma semana en que se grabó la charla, un equipo de investigadores obtuvo una recompensa de 50.000 dólares de un proveedor de nube por una vulnerabilidad de escape en KVM. Este tipo de fallos desestabiliza las garantías de aislamiento en entornos multiinquilino. Para alcanzar una seguridad de alta fidelidad es necesario recurrir a sistemas verificados como seL4; confiar ciegamente en imágenes únicas solo traslada los riesgos de seguridad a otra capa.
La latencia de compilación local frena la velocidad de inferencia
La elección del lenguaje de programación influye directamente en el rendimiento del desarrollo automatizado. Huntley prefiere OCaml: sus interfaces limpias ofrecen ventanas de contexto compactas y el compilador valida los tipos en pocos segundos.
Por el contrario, Cormack se topó con una notable fricción dentro del ecosistema de Rust. El estricto sistema de tipos de Rust resulta excelente para el razonamiento del modelo, pero la pesada sobrecarga de compilación entorpece el ritmo de iteración. Cuando los modelos exploran código de bajo nivel, las alucinaciones son inevitables; los largos tiempos de espera por cada compilación disparan el coste de la prueba y error.
En proyectos con millones de líneas de código, la compilación llegó a saturar por completo los recursos del equipo. Cuatro agentes trabajando en paralelo en código Rust colapsaron de inmediato las colas de CPU y el subsistema de disco. En servidores de alto rendimiento, el tiempo de espera de rustc superaba habitualmente el tiempo empleado en generar tokens.
Esta circunstancia invierte la lógica tradicional del desarrollo de software. Los desarrolladores humanos aceptaban compilaciones lentas a cambio de robustez en tiempo de ejecución. En los flujos iterativos gobernados por agentes, la lentitud al compilar se ha convertido en el cuello de botella que frena la evolución de los sistemas.
Superada la fricción de ingeniería, queda la pura decisión arquitectónica
La visión del espacio de direcciones único no ha quedado obsoleta. Con la teoría de tipos y la bibliografía técnica asimiladas, los modelos de IA cubren los vacíos de implementación con enorme rapidez. La generación de controladores y pilas de red reduce los plazos de construcción de meses a días.
Sin embargo, la eliminación de la fricción técnica no modifica las leyes fundamentales de la arquitectura informática. Una vez retirados los andamios, los desarrolladores se enfrentan a la verdadera naturaleza del unikernel: un entorno de proceso único sin aislamiento de anillos de hardware y altamente vulnerable a problemas de seguridad de memoria.
La IA simplemente ha abaratado el precio de la entrada. Los desarrolladores ya no tienen que temer la escritura manual de controladores, pero deben asumir los riesgos de un único dominio de privilegios. Renunciar al maduro ecosistema de introspección y depuración del sistema operativo sigue siendo una decisión de ingeniería que exige una rigurosa evaluación.
Enlaces de referencia:
- Ignore Previous Directions: Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley: Unikernels were hard. Key word: were.
- Notas de diseño del proyecto Spaceleans y retrospectiva de MirageOS
