Log in
A self-driving computer is a computer which writes all its own apps. Every app is an agent which develops itself.
Sure you can download other peoples’ code. You can drive your own self-driving car. You don’t have to, though.
Like with agents now, if you know what you want your computer to do, just tell it what to do. But unlike with agents now, a self-driving computer doesn’t just do things. It makes tools that do things, then uses these tools. As you use your private computer, it becomes your universal tool.
If you ask for a task in the chat, the computer will do it. It may have to build a new tool. Next time, you can ask again. Or you can use the UI. You’re a customer base of one. Your computer has every feature you want and none you don’t. For the first time ever, it fits you.
User story
I just did my taxes with Muse. (Yes, I know, I’m retarded.) Muse is great. Muse is a computer that can do anything, so long as it can be done with Web services, a Jupyter notebook, and an autistic, retarded generalist genius. I was left with—a 1040 and a Jupyter notebook. Of course I can’t rerun my Muse chat, like a Jupyter notebook. But if I have to change anything, Muse will probably get it right. Almost certainly.
A chat is not the best interface for everything. If for anything! What we love about our bots is that they can do anything. It isn’t how we use them (unless we’re driving).
Here’s the difference. With an actual self-driving computer, I would sit down with the same pile of dog-spoiled mail. I would have roughly the same conversation. I would be left with—a 1040, and TurboTax For Me.
Again: on a self-driving computer, an agent is an app. An app is an agent. You can use it just like Muse. You can talk to an app and tell it what to do. You can talk to an app and tell it what to be. When it can’t do X without being Y, the agent writes code. As it talks to you, the app evolves to fit your needs.
(Of course connecting to external Web services is essential, but it is transitional. Your data should be on your own computer—virtual or physical. A connector is just an app that pretends to own your data, but doesn’t.)
“TurboTax For Me” is also a tax expert you can talk to. Thomas. Thomas is also a 10^6x coder, who codes as fast as he does data entry. He puts together the app as he looks at your ridiculous pile of papers.
Next year you’ll go back to Thomas and tell him how your financial life has changed. He’ll update the code to reflect that, plus any legal changes.
Talking to Thomas is just like talking to Muse. But Thomas is building out an application, not writing one-off sandbox scripts. You can change a digit in a form and rerun the application. Unlike a Jupyter notebook, you can’t rerun Muse. You have no way to look at what it’s doing. You could see the shell commands?
Muse is probabilistic. Taxes, however, are deterministic. If you probabilistically write deterministic code, it will probably work. Prove, audit, and/or test that it works. Then run it forever.
Again, every self-driving app is an agent which develops itself. You are the only customer for this product. Thomas is your product manager. Sometimes he learns new product requirements. Thomas is on it. Your tax app isn’t just developed. It’s maintained. It has versions.
How do you use a self-driving computer? Just like Muse. Just tell it what to do. But instead of writing one-off sandbox scripts, it will build actual software. For you. You can tell it what to do, or use the UI, or both.
Why is Muse better than TurboTax? Because most of the mental stress of TurboTax is wading through the 90% of questions that don’t apply to me. Or do they? No, I do not have any agricultural deductions. Or… the landscaping? Alas, I cannot ask my TurboTax. Maybe it’ll get better at that. But if I had TurboTax, but built just for me—hell would freeze twice before I switched from that, back to the Muse UI.
In a self-driving computer, anything the computer does, it does by commanding its own apps. One-offs are considered harmful. If an app, a connector, or a feature is needed, it is added. In a self-driving app, any discrete action the app can take has a UI that can take that action.
Of course, one task can involve a complex flow of actions. This creates a great way to observe agentic computation: have the AI animate the UI as it accomplishes the task. You are treating the agent as a coworker and looking over its shoulder.
Thomas is at the controls. Thomas is just using the app he just made for you. Maybe he’s also livestreaming his actions in voice, like Twitch. Watching him use the tool is actually a great, passive way to learn to use it yourself. You supervise your self-driving computer, just like in a Tesla. Visualization—the ability to literally watch your agent doing its job—is a game changer. It feels like real ownership, because it is.
Take a moment to appreciate how much better this experience will be than doing your taxes in a chat. Which is, by the way, great.
Unix: the moat
The universal Silicon Valley question is the “moat.” This is not an abstruse product vision. Quite the contrary. It’s an obvious product vision.
When a vision is obvious and the product doesn’t exist, there are two possibilities. First: the vision is technically impossible. Second: the vision is commercially retarded. These issues are orthogonal and by no means mutually exclusive.
Now let’s answer the important question: why isn’t the above experience a thing yet? Why is it so hard? Is it, in fact, impossible?
I think that—with present technology—it’s quite difficult, if not impossible. Here’s why.
There are two kinds of personal agents today: bots (Muse, Grok Bot, OpenAI Dots, etc) and claws (OpenClaw, Hermes Agent). Bots are sane and separate the harness and sandbox. Claws are insane and combine them.
Bots can’t evolve into self-driving computers for two reasons, one deep and one silly.
The silly reason is that the bots are store apps. On Apple Store or Google Play, an app can’t be a meta-app. Muse can show you a chat, but not a UI. It actually can’t let you run your own apps, with their own UIs, on your own server.
The deep reason is that an app belongs with its data—internal variables and data structures, not external files and databases—and these constructs don’t belong in either the bot’s harness, or the bot’s sandbox.
A sandbox is a sandbox—an arena of transient chaos, where nothing is sacred and everything is deleted. If you put your sacred personal data in the sandbox, either you are a fool, or it is no longer a sandbox. But the harness is the opposite: a meticulously wired brain. The human body has a blood-brain barrier for a reason. Once vibecoded apps start scribbling on your context compiler, hell’s door is open.
Claws, which have quickly occupied the nerd side of the nerd/normie divide, do not have the deep limitation. A claw can do anything. Of course it can rewrite itself. Of course it can build its own apps.
The fundamental problem of the self-driving Unix claw is that it has to unify personal agents with AI development. While there are certainly limited solutions to this problem—more or less, toys—AI development today means Unix server development.
Today, an AI developer still has to be a developer. You can vibecode. But in practice, you still need to know what you’re doing. It’s really not for normies. Many are trying to solve this problem. They haven’t solved it yet. It’s not clear that they can—and even then, at what cost?
If you don’t know what you’re doing, vibecoding for Unix quickly generates vibe spaghetti. This spaghetti is liberally studded with security holes, rogue commands, and footguns of every shape and description. It is soon too complex for even super-duper intelligence to manage.
Unix is a zoo. It was written for minicomputers the size of a refrigerator in the 1970s. It has done just about everything since. It is full of legacy impedance mismatches (object-relational mapping!) and other clunky stuff that is a constant generator of risk and complexity.
The idea of putting your own vibecoded apps, critical data, and harness logic into one Unix compartment is… fundamentally deranged. Then again, so is landing a rocket on its tail. At some point, it can probably be done. But do we have to do it this way?
There are three ways to make AI more powerful. A: make the model smarter. B: make the context (ie, the harness) smarter. C: make the problem easier. While we continue to make progress on A and B, the most alpha is always in C.
How do we make the problem easier? Well: let’s look from the other side of the question. How *should* we be solving the problem?
When we zoom in closer, the Unix programming environment—even if we could solve all its legacy problems with security, safety, etc—is a bad fit for the specific problem of a self-driving computer.
The state model is completely wrong. Because of the hardware architecture of a DEC VAX in 1976, Unix has two states: disk and memory. It solves everything by rebooting. A virtual computer in 2026 does not need two levels of state.
A self-driving computer does need to update your app’s code, while preserving its data—even if its data structures change. Unix has many languages and frameworks. Almost none support hotpatching—which only applies to memory, anyway. On disk, it’s schema evolution. Also advanced. Also did you fsync() that?
In the past there was no choice. We had to use standard tools. Before AI, success for a new language or OS meant cultivating an ecosystem of programmers. A brutal network-effect problem, taking years or decades, totally unfundable, only for crazy people—rejects, schizos and maniacs. But it’s 2026 and who cares?
The future
If we can build a general-purpose platform on which AI can build anything easily—much more easily, securely, reliably than on Unix—we don’t need programmers. We don’t even need applications. You can start with a naked computer. Just tell it what you want to do.
Yes, of course, most people will still download most apps. They will still change them. Or rather, the apps will change themselves. Steve Ballmer once observed that his customers always complained that they needed only 5% of the features of Word. But it was always a different 5%. With a self-driving computer, it is always the right 5%.
So how do we build a self-driving computer? Of course, we have to build it on Unix. But you can’t see Unix through it, and one day Unix will just go away. (I will miss it. I got my first Unix box, the great AT&T 3B1, in 1986.)
First: there is no “code.” There can’t be procedural “code,” which both does stuff and returns a value. Our new OS is a functional OS. There are pure functions. There are data structures. There is no “code.”
The absolute worst things a pure function can do: (a) return the wrong value; (b) be too slow; (c) infinite loop. (Sadly, there will always be denial-of-service attacks.)
Second: there is no “memory” and “disk.” Your computer is permanent. All data is typed. All protocols are typed. Data structures and protocols constantly and seamlessly change. Public applications auto-update, as does the OS itself.
Third: the application architecture is fixed. All apps work the same way. Most architecture is just data modeling. Most programming is just dataflow. Any actual functions are actually algorithms. The semantics of an application are annotations on the data structure of its state.
Fourth: important invariants are static. It does not take dynamic execution analysis to know that your Gmail connector can only use your Gmail credentials to sign in to Gmail. It only takes static dataflow analysis. New apps and features should still be cognitively analyzed for sanity, but can be deterministically analyzed for safety and security.
Fifth: the OS executes in a cloud TEE. The server is opaque to the data center, and can migrate. Hosting is a commodity. The server has a name which is an NFT, whose owner owns the server. This name is also its network address. Servers can use the TEE to certify network applications. Hosts bill their servers, in crypto, by usage, not time.
With an OS like this, all code is shallow. The AI only has to be as smart as the problem it’s solving. And most problems are stupid. Building a true self-driving computer on this stack will not be trivial. But the stupider we can make its code, the more powerful the agent will be.
Now: especially when an OS of this type is young, when it has to trade off simplicity against generality, it should choose simplicity. So unusual use cases may fall outside its practical envelope. These are less likely to be encountered in a personal server. While the same virtues will serve this OS well in an enterprise context, the enterprise both demands more technical maturity, and has a longer sales cycle. To say nothing of government! But in theory, if a platform is general-purpose, you should be able to run the whole US Government off it.
Imagine you’re just little old you. But you knit. So you need a knitting app. Your friends knit too. So it’s a knitting circle. Of elite knitters. You start selling your knitting. Years go by. And you’re a multinational textile conglomerate. Still running on the same server.
And it’s not just knitting. Any such ecosystem will deliver end-to-end universal, anonymous, more or less unstoppable freedom of computing: the open society, whether you like it or not. Snce its anonymous names are crypto wallets, it also delivers freedom of commerce.
Isn’t this a compelling vision? I think it’s a compelling vision. I think it’s as compelling as the vision of a machine that can perform any medical test on a single drop of blood.
So… where are we on that, eh?
The present
I’ve been seriously working on this project for about a year. With my cofounder Zimran Ahmed (a Meta PM for 8 years, and a Harvard MBA), I started a little company called Urban Tiger. We’ve spent about a million dollars. We don’t have a self-driving computer yet. (Yes, we’re raising: see below.) Here’s what we do have.
Fortunately, most of the solution already existed before Urban Tiger, because I started working on it 25 years ago. It’s called Urbit. Unfortunately, there’s a small problem. Urbit already failed. (You can read about it in the Compact Magazine article, “The Rise and Fall of Urbit.”)
From an engineering standpoint, Urbit didn’t fail at all. Urbit works perfectly. It’s rock solid. We’ve been building on Urbit servers for a year and submitted (I believe) exactly one small bug report.
What failed was Urbit as a product. It was not a good product, and deserved to fail. This was still my fault, though I was not involved in Urbit while it was in the first round of its Gartner hype cycle. (I left the original Urbit company, Tlon, in 2018, after working on the stack alone from 2002 to 2013, then at Tlon from 2013 to 2018. In fall 2024 I spent a year at the Urbit Foundation, then founded Urban Tiger in fall 2025.)
Every new general-purpose OS has to lead with a special-purpose product experience. This experience has to be competitive at the YC level, with users who do not care about the technology. Building a “user base” of fans is a trap for a new platform, because fans (a) will tolerate a substandard user experience, and (b) are fickle and motivated by superficial concerns.
Tlon’s Urbit experience is usable. It’s actually pretty good. But it does not really unlock any particular pain point. It also has the major technical flaw that everyone in the chat needs their own server. This is because Tlon Messenger is the distant descendant of a distributed chat app I wrote in 2012 to see if I could build distributed applications on Urbit. Actually, chat doesn’t need to be distributed at all. Only the forum’s owner needs a server. The guests only need to own their names. (With our client, they can start a server with one click.)
So there’s a lot of things like that. When I was at Tlon, I focused on the core OS. Perhaps that was my real mistake. At Urban Tiger, with the standard Urbit core (Arvo), we’ve built a complete user experience from end to end—from a PWA wallet to a TEE cloud. Everything is self-custodied. We don’t have any user data we can read. You get your urbit straight from the Ethereum blockchain. You save it with a passkey and back it up with a six-word poem. Not that Tlon did a terrible job at all, but this is the Urbit experience I always wanted to build.
To the initial user, it doesn’t even feel like a general-purpose system. You don’t “install Urbit.” You click an invite link to join an Urbit lodge. You have to pick a name, set a passkey, install a Home Screen app and enable notifications. It’s harder than accepting a Partiful invite, but not much harder. And if you don’t have an invite, starting your own lodge isn’t even hard (just go to http://urbit.house).
An Urbit lodge is a digital secret society with untraceable names. As a UI, it’s actually halfway between a forum and a chat—it has a tree like a forum, but you flow through your unreads like a chat. (I stole this from Usenet.) It does everything to protect your identity—you can even set it to restyle posts with an LLM. It’s even a ZCash wallet, in case don’t want to be traced through your lodge dues.
I’m pretty sure this product doesn’t exist already. Does anyone need it? We’ll see.
Do you need it? Gosh, I hope so! Or rather, gosh, I hope not—because the only reason you need a lodge is that you’re in a social or professional context where you might be “held accountable” for speaking the truth under a traceable name. Which sucks. While it’s difficult to estimate the TAM for a “preference-defalsification” app, “everyone with an office job” is, alas, all too defensible.
Lodge is a cool product and I use it myself (if you have to ask, you’re not in %moldbug-club). Will it take over the world? I think so! And so does every 24-year-old fool in YC. (Tlon actually got into YC—in 2014. We didn’t go.) Statistics, however, suggest more caution.
But the only way to prove out a general-purpose platform is to build a special-purpose app and take it seriously, even existentially. The platform cannot be a drag on its applications! And the only way to prove this out is to ship a great product as if the platform didn’t matter, without compromising the generality of the stack.
So. We did that. But this is Urbit, and we’re not here to install an app. We’re here to reboot the world. To make AI more powerful, make its problem simpler. AI is already pretty powerful. And Urbit is a lot simpler.
Gnat
But still, Urbit wasn’t quite where it needed to be for unlimited normie vibecoding. Another breakthrough was needed. We think we have it, but more work is needed.
The last problem was Urbit’s application model, %gall—a typed, functional event-driven state machine. %gall works fine. It is very good for what it is. It can even do schema evolution and protocol adaptation, just somewhat clunkily. The underlying causal event system (which allows events to call and return) in Arvo is, I think, the best typed event system in the world.
But what happens when you write a big event state machine is that it’s all too easy to get—event spaghetti. Functional code is always the dual of procedural code. If your system can vibecode spaghetti, normies will vibecode spaghetti. So your system isn’t for normies.
Really the problem with %gall was that I never really finished the Urbit stack in 2013. I ran out of money and had to start a company. So the top layer, the application framework, was inadequately ambitious. Over time, from experience, the conviction among others in the Urbit ecosystem that %gall was not the right thing grew.
Unfortunately, most of the literal geniuses (and there have been many) who were attracted to the Urbit ecosystem were attracted to it because it was cool, and wanted to make their mark by adding something cooler. These people delivered many cool prototypes. They did not want to make something stupider (nor were they inclined to solve stupid problems). This is a common open-source issue.
What you see when you look at the %gall spaghetti is that it’s doing the same stupid thing over and over again: routing and dataflow. When the user level is solving the same problem over and over again, that’s usually a sign that you’re missing a systems layer.
For Will Hanlen (~rilryp-maplun) and I, what unlocked the new dataflow application model, %gnat (which of course fits the requirements above), was figuring out how to do typed diffs in Urbit. (The answer is: in the stupidest possible way.)
Typed diffs are the fundamental primitive of dataflow. Dataflow lets you track, minimize, and react to dependencies. A credential, for example, is data that can only flow to the appropriate request construction. If you try to leak it, your gnat will not compile. Also, the dataflow system makes schema and protocol adaptation easy—in fact, it makes them the same thing.
Yet %gnat is not a toy. Not just in theory but actually in practice, you could put the whole scene graph for a Pixar movie in your urbit’s brain, and render the frames with %gnat. (You would want asynchronous rendering.) The standard data model is like a slightly-deformed SQL, and %gnat is also good at indexing. And schema evolution. Add a column to a database? No problem. Add a variable to a structure? Same thing. Heck, you can even build an event-state machine in a spreadsheet cell. All these conventional patterns are the same thing and fit very cleanly in Urbit’s noun model.
This is why the Urbit stack with %gnat will enable the self-driving computer: because it is dumb, yet general.
While a %gall app is already much, much dumber than anything on Unix that solves the same problems (schema evolution, etc), %gnat is still dumber and much more legible. And actually faster, though you wouldn’t expect that from switching from custom event writing to generic diffs. Will translated Lodge into an early version of %gnat:
These are still rookie numbers. I actually don’t think Lodge should be more than 250 lines.
Endgame
So what are the actual barriers to Urbit as a self-driving computer?
We need to nail down and polish %gnat. That’ll take another month or two. (In a couple of weeks I’ll post more documentation.) Then we’ll have to figure out how to teach an LLM to do a really good job of writing gnats. That won’t happen overnight, either.
There’s a few things about the stack that could work better. We shouldn’t be writing UIs for Urbit in React and running them in an iframe. An app client should be an Urbit moon, with its own UI toolkit. On the hosting side, we should be auto-jetting: identifying interpreted bottlenecks and translating them into verified Rust. For various legacy calculations, and for captive browsing, we probably still need a sandbox. There’s a bunch of reasonably straightforward, but nontrivial, feature work like this.
All system software is based on tradeoffs. Is this platform, Urbit with the %gnat stack, shallow enough that the strange centaur of a human normie riding an autistic-genius LLM can’t tangle itself up in spaghetti and footguns? Is it deep enough that the LLM can actually write the apps you need? Surely it will be too deep in some ways, too shallow in other ways. It’ll have to be fine-tuned.
But the great thing about a self-driving computer is: it doesn’t need an ecosystem. It doesn’t need apps. It doesn’t need programmers. Once the clankers are good at coding it, everyone can use it tomorrow. For the entire history of system software, momentum has created monopoly—conflicting with the fundamental systems goal of simplicity. Once all software is written by LLMs, the platforms that make it easiest for LLMs to write safe, secure, reliable software will just win—however exotic the platform.
AI has taught us many things. One is how much we were relying on security by obscurity. On any 21st-century stack, Urbit or anything else, “security” as we know it is no longer a thing. There is no ambient authority. Security assertions are declarative and statically checked. So long as there are no holes in the interpreter, “cybersecurity” is over. (Except denial-of-service attacks.)
Yes, Urban Tiger is raising. I’ll be in New York if anyone wants to hear a pitch Nov 1, London Nov 3-9, then back to the Bay Area. Serious investors: reply to this email if you want to hear a pitch. Software is no longer a moat—only system software is a moat. Don’t miss the last system-software revolution.
And check out https://urbit.house. Make a lodge! (Be advised—we haven’t started putting servers in TEEs yet. A couple weeks.)
