“Unikernels were hard. Key word: were. Now we have AI.”
In October 2026, Geoffrey Huntley delivered this verdict during a technical discussion. Sitting across the table was Justin Cormack, an early core contributor to MirageOS. A decade ago, in order to run bare-metal applications in virtual machines, the team had to extract device drivers from NetBSD, manually porting thousands of lines of low-level C code into user space.
A unikernel adopts a single-address-space architecture: the application itself is the operating system. Inside the image, there are no isolated processes, and no interactive shell to log into. If developers need to send network packets or resolve domain names, they cannot rely on a host environment. All low-level drivers and protocol stacks must be compiled directly into the binary image.
For the past decade, steep toolchain barriers and a barren ecosystem kept this technology relegated to the sidelines. Today, large language models have flattened the cost of authoring bespoke libraries. Yet lowering the development barrier has done nothing to resolve the architecture’s inherent security controversies.
Figure: Conceptual illustration depicting a unikernel as a minimal digital core. Source: ghuntley.com
Model Weights Shoulder the Burden of Handwritten Drivers
In Huntley’s view, the software industry has long been constrained by a string of engineering dogmas: Nix is hard, Bazel is hard, and unikernels are hard. These hurdles are fundamentally knowledge moats erected by implementation details.
Model weights have digested type theory and decades of academic literature. Low-level scaffolding that once required months of engineering effort is now just a few prompts away. Senior engineers no longer need to translate C drivers line by line.
Huntley took a week to build the Spaceleans prototype. He ported Microsoft’s Orleans distributed virtual actor system into OCaml, packaging it into a unikernel image. The system merges multiple physical machines into a single addressable heap where actor instances can be rehydrated from storage at will.
To bring the prototype to life, he had to assemble an entire runtime foundation. Leveraging automated code generation, he completed an entire network stack, DNS resolver, and HTTP client in seven days. He then layered on NTP time synchronization, LLM client bindings, and distributed tracing. Plumbing that historically demanded a specialized systems team was assembled by a solo developer in days.
The perennial objection to unikernels—the lack of an ecosystem—evaporated under code generation. Opponents previously pointed to missing third-party SDKs, such as the lack of mature payment provider bindings in OCaml. With automated agent loops, models can synthesize OCaml modules from existing Go libraries in just a few hours.
Synthesizing Bespoke Toolchains with Rust in Hours
Cormack experienced a parallel shift in his own engineering practice. While building single-application Linux images, he pursued extreme size minimization. Traditionally, formatting a disk image required bundling the entire xfsprogs utility package into the build image—solely to run a single formatting command.
He chose instead to let a model author a dedicated mkfs.xfs clone in Rust. The native utility served as a golden oracle: the model-generated implementation was checked byte-for-byte against native output and exercised across diverse block sizes. The entire parser and on-disk layout writer were completed in a few hours.
This workflow fundamentally reshapes how specialized systems utilities are manufactured. In the past, trimming low-level tooling meant a heavy maintenance burden; teams simply accepted bloated user spaces. Pairing code generation with differential oracle testing slashes the cost of custom tooling to near zero.
Modern cloud-native storage patterns have further lowered the requirements on local filesystems. Architectures like turbopuffer treat cloud object storage as the primary persistence layer, using local NVMe drives merely for ephemeral block caching and eviction. Once durability is offloaded to the cloud, local storage no longer requires complex journaling filesystems, allowing systems to manage massive state on top of plain object stores.
Figure: “Unikernels in 2026” discussion video cover. Source: YouTube / Geoffrey Huntley channel
Stripping the Operating System Shell Does Not Eliminate Attack Surface
With engineering barriers lowered, debates around unikernel security have only intensified. Huntley argues that multi-user operating systems are relics of the terminal era. Dedicated microservices have no need for general-purpose user interfaces; without a shell or system interpreter, attackers lack an initial beachhead or lateral movement pivot, rendering automated mass-scanning attacks toothless.
Cormack voiced reservations on the spot. He pointed out that the community’s rhetoric around “reducing attack surface” has long degenerated into a superficial slogan. Removing /bin/sh from a container is trivial, yet the runtime environment still carries Turing-complete interpretation capabilities. Even if write access to the filesystem is blocked, memory corruption and ROP chains can still hijack program control flow.
Huntley acknowledged that early designs co-located the application and kernel in the same privilege ring. However, he argued that by 2026, reintroducing ring isolation is merely “one prompt away”—and regardless of pedigree, it remains inherently safer than crossing one’s fingers over systemd cgroup configurations. Cormack did not press the point further, keeping his focus on how carelessly the concept of attack surface is weaponized.
Even hypervisor-level sandboxing faces tangible breakout risks. During the week the discussion was recorded, security researchers earned a $50,000 bounty from a major cloud vendor for a KVM escape vulnerability. Flaws of this class shatter the core isolation guarantees underpinning multi-tenant hosting. Achieving genuine high-assurance boundaries requires provable foundations like seL4. Blindly placing faith in single-binary images simply displaces security risk elsewhere.
Local Compilation Latency Bites Back Against Inference Velocity
The choice of programming language directly dictates the throughput of automated development. Huntley favors OCaml: concise interfaces yield compact context windows, and the compiler validates types in seconds.
Cormack, working within the Rust ecosystem, encountered significant friction. Rust’s strict type system is exceptionally well-suited for reasoning, but heavy compilation overhead drags down the iteration cycle. When models explore low-level implementations, hallucinations inevitably occur; waiting minutes for each build drastically inflates the cost of trial and error.
In multi-million-line codebases, compilation saturated entire host machines. Four coding agents compiling Rust concurrently choked both disk I/O and CPU queues. On high-performance servers, time spent waiting for rustc routinely exceeded the latency of generating model tokens.
This reality upends classic development assumptions. Human engineers traditionally accepted slow compilation as an investment in runtime reliability. In agentic feedback loops, however, compilation latency has become the primary bottleneck constraining system iteration.
When Engineering Friction Vanishes, Pure Architecture Decisions Remain
The vision of the single address space is far from obsolete. Having internalized type theory and academic papers, modern models can rapidly bridge engineering gaps. Generating drivers and network stacks shrinks the deployment timeline of bespoke systems from months to days.
Yet the decline of engineering friction does not rewrite the fundamental laws of computer architecture. Once the scaffolding is removed, developers are left confronting the true nature of unikernels: single-process sandboxes that lack hardware ring isolation and remain intensely sensitive to memory safety.
What AI has flattened is merely the ticket price for admission. Developers no longer need to dread hand-crafting drivers, but they must now confront the architectural risks of a single privilege domain. Deciding whether to discard the operating system’s debugging and introspection ecosystem remains a deliberate engineering tradeoff.
Reference Links:
- Ignore Previous Directions: Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley: Unikernels were hard. Key word: were.
- Spaceleans project design notes and MirageOS retrospective
