What if an operating system built its own apps?
Imagine an operating system that ships with only the bare essentials. A base so it runs, and a graphical interface. No preinstalled apps, no folder full of programs you used once three years ago.
This article was translated from German using AI. Read the German original
Lately I’ve been trying out a few AI tools to generate UI components, landing pages and the like. Honestly, the results are scarily good.
At the same time, I work a lot with AI agents, especially coding agents. And I noticed something: these agents use perfectly ordinary command-line tools. They use them to search for files, create new ones, read logs. And when there’s no suitable tool for a problem, they simply write their own script, run it and throw it away afterwards.
I found that fascinating. The agent doesn’t install ten tools up front just in case it might need them someday. It builds exactly what it needs right now, and cleans up afterwards.
And then the question came to me: why do we only do this for agents? Why not for people too?
The idea
Imagine an operating system that ships with only the bare essentials. A base so it runs, and a graphical interface. No preinstalled apps, no folder full of programs you used once three years ago.
Instead, you simply tell the system what you want to get done, and it builds you the right application for it. When you’re finished, it disappears again.
By that I don’t mean an operating system that reinvents drivers and hardware. Underneath, it can run perfectly ordinary Linux. What I care about is the layer the user works with: it feels like an operating system, but instead of shipping with apps, it builds them on demand.
An example
I start my system and type: “Make a shopping list: eggs, milk, bread, fruit and vegetables.”
The system creates a small application with exactly that list. I can change the entries or add new ones. That’s all it needs to do in that moment.
The next day I remember that we’re out of cheese. I say “Add cheese to the shopping list”, and the system doesn’t build a new app — it takes the existing list and adds to it. Once the shopping is done, I don’t need the app anymore. It can go.
For me, that’s the core of it: applications come into being when they’re needed. They’re reused or extended as long as they’re useful. And they disappear when the task is done.
Who’s in charge?
If you think this through, a system like this needs something in the background that holds everything together. In a classic operating system, that’s the kernel. It decides which program gets to run when, how much memory it gets and what it’s allowed to access.
In my vision, there’s something like that here too, just for AI. Let’s call it an AI kernel. The Linux kernel underneath stays as it is. The AI kernel sits one level higher and plays the role for the generated apps that the classic kernel plays for normal programs. It understands what the user wants and decides which model and which tools are needed for it. It checks what an app is and isn’t allowed to do. And it makes sure apps get reused or cleaned up again.
I’m not the first
To be completely honest: I’m not alone with this idea, and I didn’t invent it either. There are already projects heading in a similar direction. What I find interesting is how differently they approach it.
LLM OS is closest to what I have in mind. It’s an open-source operating system that boots without a single preinstalled app. Every application is generated from a prompt. The AI writes code for it, and so that code can’t do any damage, each app runs isolated in a sandbox and may only do what it has been explicitly allowed to do.
vibeOS takes a different path. It describes itself as an AI-native operating system in which Claude Code controls the computer, from the hardware to the interface. So here a coding agent gets a great deal of control, and the apps that appear on screen are code written by that agent. If you’d rather not run it directly on your machine, there’s a Docker version.
Google is working on this too, just not as an operating system: with “Dynamic View” in Gemini, a suitable interface is designed and coded for each request.
As different as these approaches are, they have one thing in common: in the end, the AI writes code. How well that code is secured then becomes the big question.
There’s also the opposite approach, where an AI only describes an interface instead of writing code. Google, for example, has published an open format called A2UI for this. But it’s meant for interfaces inside existing apps, not as the foundation for an entire system.
And that’s exactly where my idea comes in: what if an entire system worked this way? What if the AI weren’t allowed to write code at all, only to describe?
The question I keep coming back to
The AI tools from the beginning generate code. That works well as long as a developer is sitting in front of it and looking at the result. It’s the same with coding agents: I can see which script the agent writes, and I can step in if something looks off.
But what about someone who just wants a shopping list? They can’t review generated code. And they shouldn’t have to.
That’s why I believe a system like this must not generate and run arbitrary code. My approach is different: the AI doesn’t write code — it describes the application in a fixed format. Which fields are there, which buttons, which actions? This description gets validated, and only then does the system turn it into a real interface.
I picture it like a new, empty house. It comes with a certain set of tools and a craftsman. I tell the craftsman: build me a dining table for tonight’s dinner. After dinner, the table can go again, or I keep it. The one thing the craftsman can’t do is forge new tools: everything gets built with what’s already in the house.
So who writes the code?
People still do — just once, not anew for every app. And often you don’t even have to start from scratch: if the interface runs on web technology, for example, the system could build on ready-made components like the ones from shadcn.
All allowed building blocks live in a kind of catalog, a registry, and the AI may only choose from it. If a building block is missing, a developer writes it once, adds it to the registry, and from then on the AI can use it.
That’s less flexible than free-form code, but that’s exactly the price of control.
Where I am right now
At the moment, all of this is mostly a vision. There is no finished operating system, and honestly, I don’t know whether one will come out of it in the end.
But I am working on one part of it right now: the question of how an AI can describe interfaces without writing code. I’ll write more about that in the next post.
