Boot, Prompt, Run: what happens to personal computing when software writes itself

Imagine turning on a computer. There is no operating system, no desktop, no apps. The machine holds just enough code to make a single HTTPS call. It reaches out to a remote LLM, describes its hardware, and asks for a system. Seconds later, it is running one: built from scratch, tailored to this specific machine and this specific user. Nothing was installed. Nothing needs to be stored. The software was conjured into existence and will vanish when the power goes off, if you want it to.

This is a thought experiment on personal computing in a post-scarcity scenario, where creating software costs essentially nothing.

A performance, not an artifact

Today, software is a thing. It is written, compiled, packaged, distributed, installed, updated, patched, deprecated, and eventually abandoned. It has version numbers and changelogs. It sits on a disk.

In this thought experiment, software is an event. It is generated on demand, executed, and discarded. There is no version 2.0 because there is no version 1.0. Each run is a fresh act of creation.

This represents an extreme position in a classical computer science tradeoff: memory versus computation. Traditional computing leans heavily on memory: you compute once, store the result, and reuse it. This model inverts the balance entirely. Storage is nearly zero. Everything is computation.

Software as an intimate discourse

Today, the lifecycle of software is a collective conversation. A user files a bug. A developer reads it, perhaps months later. A fix is discussed, reviewed, merged, released. The user updates. The cycle takes weeks, months, years, and involves thousands of people who will never meet.

In a generative model, this conversation becomes personal and immediate. You don’t like how the system handles files? You say so, and it regenerates. The bug report is the fix. The feedback is the development. What was a dialogue distributed across a community over months collapses into a dialogue between you and your machine over seconds.

The distinction between using software and developing it dissolves. Not because everyone becomes a programmer, but because “programming” becomes indistinguishable from “using”.

The LLM as compiler

The generation pipeline might work like a compiler, but a peculiar one. Instead of translating a fixed source language to a fixed target, it works through successive refinements: from a natural language prompt, to a high-level design, to something resembling code, down to machine instructions.

There is an interesting possibility in the middle of this pipeline: a programming language designed not for humans, but for LLMs. Today’s languages carry enormous amounts of syntactic sugar, ambiguity, and convention meant to make code readable to human eyes and typeable by human hands. An LLM does not need any of that. It needs regularity, explicitness, and structure. Think of something with the level of abstraction of C, but stripped of every concession to human ergonomics: no operator overloading, no implicit conversions, no syntactic shortcuts. A language optimised for reliable generation and fast compilation, not for comfortable reading.

This LLM-oriented intermediate representation would sit at the boundary between the probabilistic world of language models and the deterministic world of traditional compilation: generated with high reliability by the LLM, compiled to native code at maximum speed by a conventional toolchain.

Intent-addressable software

The obvious practical objection: does this mean a full system generation at every boot? Not necessarily. If you hash the input (prompt plus model version), you can cache the output. Same request, same model, same result: serve it from storage instead of regenerating it.

This is interesting because it creates something that looks like a package manager, but with a fundamental difference: the key is the intention, not the artifact. You don’t look up “firefox-125.0.1-x86_64”. You look up the hash of “I need a web browser that prioritises privacy and works well with keyboard navigation”, generated by model X at version Y.

Of course, caching is just a pragmatic optimisation. The pure form of this system, the one that reveals its nature most clearly, is the one with no cache at all: boot, generate, run, forget.

Hardware as a conversation

The most speculative part of this experiment: generating drivers. Today, drivers are written by hardware manufacturers (or by patient kernel developers reverse-engineering data sheets). They are one of the most tedious and error-prone parts of system software.

In this model, the process could happen in two phases. First, the system generates minimal hardware probing code, executes it, and collects the results: what devices are present, how they respond to standard queries, what their capabilities are. Second, armed with this information (and trained on countless data sheets and existing drivers), the LLM generates driver code tailored to the exact hardware configuration.

The more adventurous version: live debugging. The system sends commands to a device, observes the responses, adjusts its model of the hardware, and iterates. The computer, in a sense, learns its own body.

The collapse of layers

Modern operating systems are geological formations: layers upon layers deposited over decades. Kernel, drivers, system services, shell, window manager, applications. Each layer exists for good historical and organisational reasons. Each layer is also an accretion of compromises.

In a system that generates itself from scratch, these layers have no reason to exist as separate entities.

This is not a new idea. The Lisp machines of the 1970s and 80s, the Smalltalk environments at Xerox PARC: these systems already treated the boundary between OS and application as an artificial constraint. They were, as it turned out, ahead of their time rather than wrong.

A Cambrian explosion

Many of the compromises we accept in modern computing exist because software must work for millions of people. Security versus usability. Power versus simplicity. Features versus performance. These are not inherent tradeoffs: they are artifacts of scarcity. When software must be written once and used by everyone, every design decision is a compromise between competing needs.

When every instance is generated for a single user on a single machine, these tradeoffs dissolve. Your system can be both maximally secure and maximally usable, because the security model is designed for your specific threat profile and your specific workflow. There is no lowest common denominator, because there is no common anything.

And the consequences go beyond personalisation. Today, a handful of browsers, a handful of operating systems, a handful of text editors survive the economics of software development. The rest die, not because they were bad ideas, but because no one could afford to maintain them. Remove that constraint and the ecosystem detonates. Millions of browsers, each a slightly different experiment. Operating systems that exist for a single purpose, a single afternoon, a single person. Design decisions that no commercial venture would ever risk become trivially cheap to try.

The empty computer

Back to our machine, the one that boots with nothing but an HTTPS stub. A computer with infinite potential and zero state. Arguably, the most personal computer imaginable: one that contains nothing except the capacity to become exactly what you need.