Unikernels are back! I keep seeing people discovering or rediscovering unikernels, so I decided to spend some time talking to people about why and what they are up to with unikernels now.

First up is Geoffrey Huntley, who you may know from the Ralph Loop, or his talks and writings. I dropped him a mail and within minutes he was talking to me from the pub about Mirage, Orleans, Haskell, Nix and much more.

Justin: Nice to actually meet.

Geoffrey: Likewise. You sent me an email literally five minutes ago because Sean says, "Hey, you should catch up with this guy." And I'm down at the pub. I've got myself a stein of beer, and I'm like, "Yep, unikernels. Let's nerd."

Justin: Tell me when you discovered unikernels. What's your history with them? When did you come across the idea?

Geoffrey: Probably around 2015. I staffed up a team of Haskellers and went pretty deep down the functional programming route. Of course, where there's Haskellers, there's OCaml programmers, and from there you get to Mirage. I tried playing with it back then. Great idea.

Let's define a unikernel first. A unikernel is the idea that your application is the operating system. That means there's no userland. If you want to do things like a web server, DNS or sending email, there's nothing else that you can fork or spawn. You've got to write those things as libraries in your application. There's nothing else but these things.

But the problem was, before AI, you had to write those things. That was the friction.

Justin: It was the friction. When we were working on Mirage and Unikernel Systems, we took a bunch of shortcuts for that reason. We had the TCP stack and the HTTPS stack, but there was a whole lot of stuff we didn't have. There was basically almost nothing for storage.

We did have a bunch of Git-like storage stuff, but it was much better for non-persistent applications because of that.

Then I worked on a bunch of stuff using drivers from NetBSD, because you could run them in userspace easily. You could use filesystems and stuff from NetBSD. We were trying to find ways of getting libraries faster, and getting stuff faster. It was hard back then.

Geoffrey: It was hard. Let's quickly get into why unikernels. There are a lot of things that people have in their heads as dogma: Nix is hard. Bazel is hard. Unikernels are hard. Yes, they were. Key word: were. Now we have AI. These hard concepts are in the model weights. All you've got to do is prompt them, and also, cognitively, get rid of this dogma that they're hard.

So, why unikernels? Unikernels are really simple to me. Every application out there that's not unikernel-based has been built with the idea that you have the application, and then you have the operating system underneath.

Justin: The application runs on top of the operating system.

Geoffrey: Now, people might think that's fine. But why do we have an operating system? If we go back 40 years, I used to do IBM 5250. I've done AIX, Solaris, mainframes. I did it all, baby.

It used to be a human operator. The reason we have an operating system, and even a multi-user operating system, is because there was a human operator, and then we put the application on top. With a unikernel, we get rid of a lot of these historical design decisions. I consider this design debt.

Why this really matters now: under that model, without the unikernel, applications get popped. They've been getting popped before AI. They pop the top userland application, and when they do, they get access to a shell. That shell is this VIP butler service for exfiltration.

Why I think unikernels are going to get really big – and I really want to know your take on this, Justin – is because the attack surface is much less. If you don't have that functionality in your application, also known as the operating system, then the agent is screwed. The autonomous attack vector is screwed. If it's not in the application, it can't do that functionality, because there's no other surface to go to the next hop. What's your take?

Justin: I do agree. Though I think attack surface reduction is something that people are very fuzzy about how it works. You can remove the shell in Linux, for example, but almost every Linux environment has lots of other things you can use to attack.

I spent a bunch of time working on hardening in containers. It was fascinating what people thought attack surface reduction could do without realising how many more holes there were. In Linux, you can execute a new program without a writable filesystem. Not many people know that, but you can.

Geoffrey: If you can cat /proc, you're screwed. You're hosed.

Justin: Yeah. Almost every Linux environment has something that's basically an interpreter. There's Python, there's shell, or there's something you can use as a fake interpreter. There's something that will effectively run new code.

One of the things you need in a hardened environment is no ability to write new code. Even then, you've still got to worry about memory safety and things like that. Gadgets are real ways you can execute code that shouldn't be runnable, and you can write things onto the stack. There are a lot of things you have to do to harden an environment.

There's a huge amount of attack surface in a general OS, because it's designed to run a lot of code. People are not quite sure exactly what you have to do to reduce attack surface. A lot of it's very hand-wavy: "We'll just remove the shell," in the container world.

Geoffrey: We've been doing this for 26 years or so, this entire notion of hardening the operating system. I think the earliest adage was back in the Solaris, SunOS days, when we were using PHP and cgi-bin: "Don't put the compiler on production."

From there, eventually we started using containers, and got the idea of a build container and a production container. Then we started getting into things like Chainguard. All we're doing is continually trying to reduce the attack surface, instead of going from the opposite direction of ensuring there is no attack surface.

It is true about memory safety and gadgets and widgets and chains. But consider: if there's no shell environment, no interpreter environment, there's nothing that the agent is trained on in the model weights. It won't know how to actually do things unless it's a very sophisticated attacker, and they've got access to your source code. That's a targeted attack, versus, let's say, an exploit on Ruby on Rails. Pick your language, and next thing you know it's got shell access. And the model weights know what to do with shell access, baby.

One of the reasons I think it's very different now is all those past hindrances, like storage and all the rest. I've got some stuff to show you, Justin. I went pretty deep with unikernels at the end of the year, just to check if my mental model was right. I think those past hindrances are no more, because you can prompt the LLM to do OCaml, and you get the things you need.

The fact that a programming language doesn't have support for the Stripe API, and you've got this unikernel that needs to access Stripe, and you're like, "Oh, I don't want to write the Stripe library"—it doesn't matter anymore. You can run a loop to port the Go to OCaml. Here you go, baby: you've got Stripe in a unikernel.

Justin: I've spent a bunch of time working on minimal Linux OS images for appliances. They were what drew me back to unikernels as well, because once you start going down the minimal Linux OS route, you're halfway there. You're just running the one application.

I did some experiments building with Nix and with systemd. Then it was, "Well, actually, it's just as easy to have a single executable that executes as PID 1 and just runs my code."

Again, this is running on Linux, so you've got some stuff. At one point I needed to make an XFS filesystem. I was like, "Okay, I can bring in xfsprogs and all the stuff it brings in, or I can sit down with the AI agent, ask it to write mkfs.xfs, and make it output exactly the same bytes on the filesystem as mkfs.xfs does, and interpret all the flags."

It literally only took a few hours. It had tests; it reverse-engineered what all the on-disk formats were and what they meant, basically filled them in one by one, and made sure that all the things worked for different block sizes and everything. Now I have mkfs.xfs in Rust, and I never need to actually run mkfs.xfs.

Geoffrey: Beautiful. If you've got something like a golden oracle – if you can run mkfs and see what it looks like – then you vibe-port it across. Use the tests, port the tests across. You can take the Rust implementation and the OCaml implementation, and use the creation of the filesystem at different sizes as an oracle to verify the port. You can automate this stuff.

The filesystem thing is interesting. I would go out and say that a lot of what's deployed these days is cloud-based workloads, even if it's on-prem. You can do a lot with the turbopuffer approach: a local on-disk block cache, and then you use S3 as your primary, infinitely growable storage. You can do it across many nodes.

Justin: I'm a massive "S3 for everything" fan. I gave a talk about that a few years back. The number of things that are being built on S3, that can be built on S3—as long as the latency piece doesn't matter, you've got infinite storage with multi-user access, and you can build everything on it now.

Geoffrey: With the local storage, you use some sort of LRU—figure out your caching algorithm—and use the local NVMe disk for your hot bits. Then you use the infinitely growing S3.

You mentioned—I guess you're doing Yocto, because that's another approach for embedded systems.

Justin: There's a number of different approaches. I was using the systemd OS thing that they build as well, and I was just trying various things. I experimented with building with Nix as well. As you say, AI is very good at building with Nix. I was surprised the first time I got it to prototype building an OS, and it built all the tests into flakes.

Geoffrey: Oh, the machine tests! Okay, Nix sucks, the language sucks. Nixpkgs: great. NixOS machine tests are the bee's knees, because you can create a test that creates a fleet of machines, and then you can test the interaction of network rules and your application. You can run the entire thing. It's the thing that people don't know about.

Plus, of course, you can patch the world. If you get a problem with something, or some supply chain problem with your dependencies, that's just an overlay.

Justin: Totally. The more you build this stuff, the more you realise that you just need that level of control, because upstreaming stuff is so slow. Having the ability to overlay is necessary, and you just want it. The speed difference between working with upstream open source and what you can do with AI is so extreme that you have to be able to do overlays.

Geoffrey: You have to. If you have to tool-call a human, also known as "Dear Maintainer", who might be on holiday or might have abandoned the project, and wait a day, two days, or even five minutes—that's not AGI. We're building recursive products here. The agents need the ability to modify the world as first-party source, not third-party bundled binaries. We're going back to the contrib folder and Unix patches.

Justin: What do you think unikernels still need for other people to discover them?

Geoffrey: Honestly, it's what we're doing now. We've raised two generations of developers who don't even know it's a thing.

If you really deeply care about security, there are really two choices. One, you're sending satellites into space, which means you should probably use seL4 as a formally verified operating system. I'm still a little bit salty about the Australian government disbanding that team.

And two, you should deeply consider unikernels. If you deeply care about security, you should stop trying to harden something that is very hackable, and instead invert it and design the other way. I don't know how to properly explain it, but just do the opposite of trying to harden a Linux image.

Justin: One of the other criticisms of unikernels was that a lot of the original designs were all a single privilege layer, without layered privilege in the unikernel. Your application would run in the same ring as where the OS runs now, rather than having a userspace and kernel-space privilege separation.

Geoffrey: Honestly, just rip a fart into a coding agent, and then you get ring separation if you so desire, in 2026.

Justin: Yeah. Is a thing running in a lower ring?

Geoffrey: But this is all instantly fixable. It's definitely more secure than praying to God your systemd cgroup configuration is right. Consider this: how much time does enterprise spend, every time a new Linux thing comes out, patching the world because of that? How much time do they spend on maintenance? You can substitute that and remove it, because you don't have to worry about it, because it doesn't affect you.

Justin: Nowadays, upstream Linux expects you to patch your kernel every week.

Geoffrey: Did you see the KVM bypass this week? Holy [expletive]. Someone managed to pop KVM, which essentially means Firecracker—the core primitives of virtualisation, what we thought was good sandboxing. They took $50,000 from Vercel and a few other vendors. That's not much money, considering they had the equivalent of something that would allow them to essentially root every single managed cloud provider out there in the world, including AWS. It's crazy.

Justin: Yes.

Geoffrey: Cool stuff. Do you want to see some cool stuff, man?

Justin: Yeah, sure.

Geoffrey: This was seven months ago. This is me revisiting the world. What you see here is essentially our Mirage folder, and this is all the functionality I needed to add into Mirage.

I didn't have a way for a unikernel to sync NTP and keep that fleet up to date. So what do I do? I take an NTP client in a different language, and I'm like, "Hell yeah, let's add it to OCaml, baby." Next thing you know, we've got an NTP server based on RADclock. I took some of the ideas behind TigerBeetle and how they handle their time, and implemented them here, for both NTP server and client, but also as a library for how to handle time. So it's not just one clock source, it's many clock sources. Look at TigerBeetle if you want; there's a good blog post about this.

You add your network stack, DNS. OCaml's the fun part. Here it is: we've got a library for payments using Airwallex. We've got libraries for Anthropic, HTTP clients, HTTP servers, structured logging, OpenAI, OTel.

Every project, no matter what, should have a PII wrapper, so at the boundary you never log any secrets or PII through your logging subsystem. It should be pluggable. Just use a functor and have some fun.

Because it's OCaml, you can do some metaprogramming with PPX rewriting. That's a bit of fun. A generic retry library for handling retries and backpressure over an HTTP client, all the rest. You build out this massive library in OCaml, and the end result is you get a cool little unikernel operating system.

But this is perhaps the most cooked thing. I guess this is the first time I'm showing this to folks. I tweeted about it at the beginning of the year. This is Spaceleans. Spaceleans is Microsoft Orleans ported to OCaml.

Microsoft Orleans is a distributed actor-based system with transactions. You can do transactions over your actors, like SQL transactions. If you've got many different physical machines, and you've got some operation where you want to make sure you have atomic commit or rollback, Orleans has this. It's normally written in .NET.

The way Orleans works is you take many physical machines, merge them together, and that becomes one addressable heap of memory. The idea is that an actor always exists. It's an async/await-based thing. If you "get customer" and the customer doesn't exist, it will rehydrate it from storage, and that storage provider is pluggable.

The idea is that you collapse this n-tier architecture down into your actors, and then your content is always addressable. If it's in memory because it's been accessed before, it's always in memory, and you don't have to worry about whether it's on machine A, B, C or D. The runtime handles this as an infrastructure primitive, and you just use async/await.

So, hello, Spaceleans running as a unikernel. In a weird sense, I built a distributed unikernel operating system using actors.

Justin: Right. Cool.

Geoffrey: I don't know what I'm doing with this, but it was fun. I also built a filesystem on top. I went full tits-to-the-wall with this thing. It's something that exists for me, and I'll probably never release it. I'm waiting for the right time to put this into play. But it's pretty cool what you can do with things like this.

That was me getting back and falsifying the idea that unikernels were hard. Well, they were, but we have AI now. All that was done in a week. It's cooked.

Did I make a distributed unikernel operating system using actors? Maybe it's Plan 9-esque. I'm going to go back.

Justin: It's kind of Erlang-esque. There were lots of non-distributed things along those lines as well, back in the day. There's been a lot of thinking about those. Actors have been a persistent thing for generations.

Geoffrey: That's exactly it, Justin. Us being a little bit older means we can sample history. It's like an experienced DJ like Carl Cox, being in the music scene for so long. You can sample previous repertoire and bring it forward. All this research, all these ideas existed in the '80s. We've just got to bring them forward again.

Justin: The AI has read all those papers. You can point it at specific papers and ask for an implementation as well. A lot of it's in its background learning, so it understands the concepts, which is helpful.

Geoffrey: It sure as [expletive] can. It's got TAPL in its training dataset. It's got the most advanced type theory in its training dataset. All you've got to know is how to sample it and ask for it, and you'll get it. The thing that's lacking is people's curiosity and ambition to do these unhinged things, and the knowledge that previous records exist that can be sampled from, and doing it.

Justin: How do we inspire people to try these things? I wrote a while back that I thought we could have a new era of systems software that would be really great again. We have an opportunity to do things differently. But how do we actually make that happen?

Geoffrey: We just do it. If we've got ourselves a turbo Lamborghini alien space rocket that allows us to do things more efficiently, and it's more secure, then good for us. We've got a leg up and an advantage in the AI space race. Maybe others pay attention when this happens. But the best way of getting everyone else to adopt it is just to do it.

Then you attract other smart minds who are curious, maybe people watching. When new people turn up, we're like, "Cool. Now we've got an apprentice to mentor." The same thing we've always done: you mentor the incoming curious people. You do cool things that attract newbies, you mentor those newbies, and you grow.

Meanwhile, everyone else is going to be trying to Chainguard their Ruby on Rails application. You're like, "Baby, what are you doing? Why are you managing AWS with 50 AWS-certified monkeys, when you can just use Nix and automate those 50 people with two people and Hetzner?"

Eventually, it comes down to money. Higher-power tools are more efficient, and efficiency will win in this game, especially as margins with AI get collapsed.

Justin: You said you originally did a lot of Haskell. I started out a long time ago. Do you think OCaml's time has come again? How do you feel about OCaml now?

Geoffrey: OCaml is still going strong, right? I'm sitting here with a non-OCaml jumper, but a certain company is using OCaml very well in this space, to their growth.

I caught up with Yaron at the beginning of the year, and I asked him, "How's it going? Why does OxCaml exist? Is it so your language extensions get into the training dataset, which then lifts up your company?" And it was just a very "no comment" smile.

It means they can lift up their internal developer productivity without having to change away from OCaml. They're not giving away any alpha by showing how to allocate onto the stack properly with OCaml. But at the same time, by that being in a training dataset, it lifts up the entire organisation, so they can go improve the liquidity of the markets.

Justin: OCaml's really got good types, especially around modules. It's got a lot of things that other languages haven't copied yet.

Geoffrey: The functor design between modules is beautiful. Even just the .mli files: to have that type annotation on top, like a header explaining how this should work, is really efficient with agents. Plus, opam and Dune are legitimately really good, and the compile times are really fast.

What's the type system—Hindley–Milner?

Justin: Hindley–Milner.

Geoffrey: It's beautiful. I see no reason someone would do F# these days. As someone who's done F#, you might as well just do OCaml. It's the same stuff.

Justin: I've mostly been doing Rust recently. Agents are good at Rust.

Geoffrey: But the backpressure from compilation—it takes so long to compile.

Justin: I know. Basically, you have to spend more money than you spend on the AI buying faster computers to run your compiler on.

Geoffrey: These LLMs hallucinate, and the problem is, if the compilation speed is slow, a hallucination is very expensive, because it means it can do fewer attempts per minute.

Justin: Compile time is definitely a problem, especially once you get into big codebases. I've been writing an S3 clone, and it's about a million lines of Rust. It's slow, and it uses space. When you have four agents running and they're all compiling it, they're fighting for the amount of disk space you've got.

Geoffrey: And the CPU.

Here is the exact same thing that I showed previously, but in Haskell. It's one of the cool things: I can show this again with Erlang; I can show this again with Rust. You get to play with these properties, with OCaml, and try to figure out what's in the distribution of the weights.

I definitely think dependent types are going to be something for next-generation languages. Anything with dependent types, meaning you can codify more into the language system, is going to be a winner for language designers.

It does Haskell really freaking well, because the type system is really good. But the problem is, if you get a space leak in Haskell, I don't feel so good about running Haskell in production.

Justin: That's interesting, because it's not visible at the code level.

Geoffrey: It's the state space when it's running in production that only shows when it runs in production. And I don't like that.

Justin: It's interesting, because all the linear type stuff in Rust came from trying to solve that problem in Haskell. Those papers are all Haskell papers: "How can we actually make it understandable when it's not going to blow up?" But that hasn't really got into Haskell in a usable way.

Arguably, Rust spends so much time with people doing reference counting in the end that it's only partly there. You really have to work very hard. I'm finding it very interesting how different languages have these different strategies about memory. The Zig people are all, "Just allocate once up front, when your program starts. Never do any memory allocation afterwards." Constant everything, which is a strategy.

Geoffrey: The game devs: we used to do this in the '80s and '90s.

Justin: It's hard, but it does give you those hard guarantees about memory usage. You can do that with anything, but it's hard to persuade an AI agent to do that in Rust, for example, because its training set is not constant-memory applications.

Geoffrey: You probably wouldn't be surprised if I said I have my own fork of the Rust toolchain with dependent types. You can just do things now.

I guess this is probably where we should go: the pace of language development has been slowed down by people's cognitive ability to learn advanced concepts. We've also designed languages for humans. What's the point of operator chaining? It's essentially just sugar to make things easier for humans.

But if agents are going to be the interface that writes the code, not humans, then we can lean on all this advanced TAPL-based knowledge. There's 40 years of academic programming language theory research that can be called on if you know how to sample it.

I think languages can accelerate. If you had Python 2 to Python 3 today, Justin—it's been something like 15 years; I don't know the exact number, I've had a few beers—and people are still wounded by that migration between Python 2 and Python 3.

Justin: I knew companies that had hundreds of people working on that migration for years on end. It was a horrendous thing.

Geoffrey: We've codified, as an industry, "Do not make breaking changes." I think that's false now. What you do as a language designer is ship a skill pack, and the agents auto-migrate. So you can accelerate really goddamn fast.

Justin: Sean Allen, who we both know, spent a bunch of time working with agents with Pony, which is a language with almost nothing in the training set. It still did pretty well, because a lot of stuff is transferable from other languages.

Geoffrey: It's the same latent space.

Justin: It would be interesting to understand what you have to do to build a new language for an agent. I spent a lot of time talking to Anil about how you build OCaml into a language that lots of people use, and how much it costs to make a programming language successful. Go was the last one where a company spent a budget on making a new programming language successful, and it took a long time and a lot of money. But what does that really look like now?

Geoffrey: I can answer this. This is full tilt. This is almost a year old now. I had a few beers, and I'll show the prompt I used, but I said, "Make me this language." This language is Gen Z, and it's called Cursed. It's currently broken on GitHub. I acknowledge this. Understand it was written with Sonnet 3.5, and I'll go into how it was built.

Basically, I could have done this by re-lexing Go. It would have been really easy, but that's not fun. I wanted to see exactly that, Justin: how well can a shittier model like Sonnet 3.5 or 3.7 build a brand-new programming language? Can it do a Pratt parser? What can it do? Really exploring the space, what approaches you would take.

It's the only compiled language that allows you to code with sus, slay and vibes. It's 500 times more performant than Python, when it works. But that's not hard, to be honest.

It's got 50 standard library modules of questionable design. This is really weird. I did it in Rust. I did it in C: not enough backpressure. I wasted too much time running Valgrind. It would make an update, and then it would clobber the update, and I'd find the agent going backwards. So I then did it in Rust, and then I decided to do it in Zig.

Zig was a mistake. I should have stayed with Rust, and then it would have been functional, and I wouldn't be apologising. It's got zero human taste. Claude Code says it's 100% production-ready, but it's not.

It has these beautiful features, such as a pointer syntax that uses the Among Us "sus" logo. If you've got kids, you'll understand the reference. Among Us is sus. Pointers are not stars; they're Among Us. It's all on GitHub. Is it real? No cap.

Keyword reference: as fucked up as you can get. When should you use it? When you want to troll your hiring manager.

This is how it was made. This is the first loop engineering. Everyone's talking about loop engineering AI. Go to my YouTube: three months of running this bloody prompt in a loop, saying, "Dream of candles. You can implement anything you like." This is the prompt. It was literally so underspecified.

"Did you run it for three months?" Facts. "How much does it cost?" A fourth of a salary. It was something like US$6,000, and I did it three times over. What the actual [expletive]? Compare it to how much Golang cost to build.

The standard library contains whatever Claude thought was appropriate to add. This included post-quantum cryptography.

Why did you make it? I honestly don't know. I wanted to see what was possible.

Now let's get out of the comedy hour, Justin, and get into the real. What I found, and what it taught me, was some really cursed things, and it really scared me. It still scares me to this day.

If you allocate the context window correctly—a lookup table, like a hash map of the lexical structure or the grammar—it's able to dream of candles of previous programming languages and TAPL. It can program the programming language without it being in the model weights.

That is wild. It's not efficient. But what I'm getting at: if you think about compiler T-diagrams, tombstone diagrams, you can take something and get yourself to a self-compiling compiler really damn fast. Within a month. It really depends on when the next training run is.

Lock down your grammar, lock down your lexical structure, get yourself to stage two, have a standard library that's sensible, and get in the training run. From that point forward, you can basically get to the equivalent of Roslyn, or any of the classical languages where the language itself is programmed in the language itself. You can get to a full self-hosted compiler with language services stupidly fast.

This was true almost a year and a half ago now, and the models have got better. I haven't retested it. It just takes one programming language designer to go tits to the wall with the good models, to shock the world.

Justin: Do you think it would help to fine-tune an open model on your language, to help bootstrap it? Or do you think it's not worth it?

Geoffrey: It's just not needed. Understand, it's very brute force. It's not efficient, but it works. You get to stage two really fast.

It's just efficiency: how you allocate the context window on every loop will allow you to get there. A self-hosting compiler means you've got to reimplement the compiler itself, and that's a little bit frustrating. You want to have efficiency before you do that.

Justin: The other option is obviously to write the compiler in OCaml or something, like Rust did to start with.

Geoffrey: Scheme is the classic, right? OCaml or Scheme. You start with something new.

I'm going to have to go in five minutes. They're shutting down the pub. It's been lovely nerding out, dude. Anytime. I like hanging out with nerds.

Justin: It's great. I've been really enjoying your recent posts. I saw the unikernel one and the Nix one, and you did the podcast where you talked about some of that. I wanted to catch up and talk about some of that stuff, because it really is a fun time.

I'm looking forward to catching up with some more people about unikernels, because I've seen all sorts of different people talking about them again in the last few months, in a way that just hasn't been happening.

Geoffrey: Slowly waking up. You can sample again. You can now sample.

Justin: What are you thinking about now? What's next on your mind?

Geoffrey: I don't know. I've just posted a new post talking about how AI use is mandatory for employability. If people haven't seen that, you should go read it. If you're a manager of people, you should make some preparations. You should create the space and time for people to play with it. But your leadership, in the next six months, is going to ask you to put your employees on a vitality curve. You'd better start planning. You don't want to have no idea what's going on here, folks.

Yes, the labs have trained AI on the commons and stolen the commons from the world. I hate that. I get it. But if you want to be employed, AI use is mandatory now, so you've got to push past those feelings. You trade time and skill for money, and employers have minimum standards. Those minimum standards have changed very fast, faster than they ever have in our industry.

Be curious, learn how to build an agent, and go create beautiful stuff, because we're in a renaissance right now.

Justin: The time for building things is just so true now. Every idea can be an experiment now.

Geoffrey: Absolutely. It's like a time-compression device. The older you are and the more experience you have, the more you can sample. Just because you create something doesn't mean it ships. Some of the stuff I showed you today might never see the light of day. But I use it as a kata, and I'll redo those things when the models get better.

Some of my philosophy here is: if you want to build a secure thing in the world, you should seriously consider unikernels.

Justin: Thanks very much. It's been great to catch up, and hopefully we'll catch up again soon.

Geoffrey: Until next time, Justin. Let me know when it's posted.

Justin: Yes. See you. Bye.

Geoffrey: Bye.