Unikernels Were Hard. Key Word: Were

TL;DR

Before you orderOffer from Amazon

Get the latest gadgets delivered free with Prime

• Fast, free delivery on millions of items
• Prime Video, Amazon Music and more included
• Member-only deals all year

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

Geoffrey Huntley argues that AI coding agents could reduce the effort of building unikernels by porting missing libraries and tools. His case draws on a conversation with Justin Cormack and examples including an agent-written filesystem utility, but the security advantages are not settled and the article reports no broad adoption or measured results.

Geoffrey Huntley argues that AI coding agents could make unikernels easier to build by helping developers write or port software that those systems have historically lacked. In a report about a conversation with Justin Cormack, who worked on MirageOS and Unikernel Systems, Huntley says the approach could reduce a practical barrier to using unikernels, though the security case remains contested and the source provides no evidence of wider adoption.

A unikernel packages an application with the operating-system functions it needs, rather than running it atop a conventional operating system with a separate userland. That design means developers may need to provide services such as networking, storage, or email as libraries within the application. Huntley says that constraint made early projects difficult to build: Cormack recalled that Mirage had TCP and HTTPS stacks but few storage options, and developers used drivers taken from NetBSD.

Huntley’s proposed change is that AI agents can help fill those gaps. He gives the example of a developer asking an agent to port an existing library from Go to OCaml, making a service such as Stripe easier to use from an OCaml-based unikernel. These are Huntley’s argument and examples, not evidence that every port can be produced reliably or maintained without human review.

Cormack offered a separate example involving a minimal Linux appliance image. According to Huntley’s account, Cormack used an agent to write a Rust implementation of mkfs.xfs, a tool for creating XFS filesystems. The report says the implementation reproduced the original tool’s output byte for byte across tests involving different block sizes, with work taking a few hours. Huntley presents comparison against the existing utility as a way to check the generated implementation; the report does not provide the code, independent test results, or a detailed account of the review process.

AI Could Reduce Unikernel Build Work

The argument matters because unikernels have offered a way to run an application without much of the general-purpose operating-system environment that surrounds conventional software. A smaller environment can mean fewer components to configure and maintain, and may limit what an intruder can do after exploiting an application. If AI tools make it less costly to create missing libraries and utilities, developers could revisit a design that previously demanded specialist knowledge and substantial custom work.

That prospect is not the same as a demonstrated security improvement. Huntley argues that removing shells and interpreters can restrict an attacker’s options after a compromise. Cormack cautions that attack-surface claims can be difficult to quantify: a Linux system can omit a shell and still contain other ways to execute code, while memory-safety flaws and exploitable code remain concerns. A unikernel can also contain bugs in the application and libraries it incorporates. Reducing components does not, by itself, prove a system is secure.

The report’s practical value is therefore a change in the cost question, not a conclusion that unikernels are now ready for general use. AI-generated ports and tools might reduce one source of friction, but reliability, maintenance, compatibility, and security still need testing. Huntley’s article does not supply comparative deployment data or an independent assessment of the examples.

The Engineering Gaps Behind Unikernels

Huntley says he first explored unikernels around 2015 after working with functional programming and encountering MirageOS, an OCaml-based project. In the model he describes, the application is also the operating system: rather than relying on a normal userland for processes and utilities, developers assemble the functionality the application needs.

That structure can require a team to build or adapt components that conventional systems already provide. Huntley recalls gaps in storage support in early Mirage work, while Cormack’s filesystem example illustrates the same issue for system utilities. The report places this challenge alongside a broader history of efforts to remove unnecessary production components, from keeping compilers off production machines to using separate build and runtime containers. It does not establish that those approaches are equivalent to unikernels or that one is universally safer.

Huntley also describes cloud-oriented storage as one possible fit for modern workloads, with object storage such as S3 serving as a primary store and local NVMe used as a cache. He and Cormack discuss Nix-based machine testing and overlays as ways to test systems and address dependency problems. These are design suggestions within their conversation, rather than results from a reported deployment study.

“Unikernels were hard. Key word: were.”

— Geoffrey Huntley

Adoption and Security Still Unproven

The report does not say whether AI-assisted unikernel development has led to production deployments, wider adoption, or lower development costs across teams. It also gives no benchmark comparing the effort of building or maintaining a unikernel with that of a conventional application. The filesystem example is attributed to Cormack through Huntley’s account; independent verification, source code, and the full test suite are not included in the supplied material.

It remains unclear how often an agent can create correct ports for complex libraries, how developers should maintain them as upstream software changes, and what human review is needed. The security discussion is also unresolved: the report describes potential limits on post-exploit activity, but includes no measured comparison of attack outcomes. The claimed benefits should be read as an argument and a set of examples, not as proof that unikernels eliminate exploitable paths.

Testing the AI-Assisted Approach

The source describes Cormack running a series of conversations about unikernels for his newsletter, with Huntley’s discussion appearing first. It does not announce a product, release date, adoption target, or formal research program. Readers seeking to judge the proposal will need further public examples that include reproducible code, test results, maintenance history, and details of human review.

The next meaningful evidence would be a comparison of AI-assisted ports and conventional implementations under the same tests, followed by reports on how those components perform in real deployments. Security claims would likewise need clearly defined threat models and testing that compares what an attacker can do in each environment. Until such evidence is available, Huntley’s report supports a narrower conclusion: AI agents may make some of the custom software work behind unikernels less burdensome, but whether that makes them practical or safer at scale remains open.

Key Questions

What is a unikernel?

A unikernel combines an application with the operating-system functions it needs, instead of running it on top of a conventional general-purpose operating system and userland.

Why were unikernels difficult to build?

Developers often had to provide needed services as libraries within the application. Huntley says early Mirage work had networking stacks but few storage options, leaving teams to find, adapt, or write missing components.

How could AI make unikernels easier to use?

Huntley argues that coding agents can help port libraries and create system utilities that are missing from a unikernel’s software ecosystem. The report offers examples, but does not establish how reliable or maintainable these generated components are in general.

Do unikernels guarantee better security?

No. The report discusses how removing shells or other components might limit some post-exploit options, but Cormack cautions that attack-surface reduction is hard to quantify. Bugs and other ways to execute code can remain.

Has AI made unikernels mainstream?

The source report does not provide evidence of broad adoption, production use, or comparative deployment data. It presents AI-assisted development as a possibility that still needs testing.

Source: hn