Software 3.0 Needs an Operating System

In his 2025 talk “Software Is Changing (Again)”, Andrej Karpathy gives the current AI transition a useful name: Software 3.0.

Software 1.0 is the code we write directly. Software 2.0 is the behavior learned into neural-network weights. Software 3.0 is software programmed in natural language, with large language models interpreting intent and taking action.

The label matters because it asks us to look past the chatbot. If English is becoming a programming language, then the model is not merely another feature inside an app. It is a new way to make computers do things.

ISPO begins from the same premise. But it places the operating-system boundary somewhere different.

Karpathy describes the LLM itself as a new kind of computer—part utility, part fab, part operating system. ISPO treats the model as an extraordinarily capable but fallible compute layer. The operating system is the environment around it: the part that owns identity, files, permissions, durable state, application boundaries, and the handoff between human intent and machine action.

That distinction is the center of the product.

The agreement: software is becoming soft

Traditional software arrives as a finished object. Someone else decided what it does, built it, packaged it, and shipped it. The user can configure the edges, but the application itself is mostly fixed.

Software 3.0 makes that boundary negotiable.

A person can describe a workflow in ordinary language, ask an agent to build it, inspect the result, and keep shaping it through conversation. The most important change is not that code is generated faster. It is that software can become responsive to the person using it.

That is what we mean when we say apps in ISPO are soft.

An ISPO app is still real software. It has source, interface, data, permissions, and a lifecycle. But it is not sealed. Every app has a conversation attached to it. You can ask how it works, change its behavior, or make a new app for a need too specific to justify a product company.

The old loop was browse, install, configure, tolerate.

The new loop is describe, inspect, reshape, keep.

This is Karpathy’s “English as programming language” made into an everyday application model.

Where the metaphor breaks

The phrase “LLM operating system” is evocative, but taken literally it gives the least predictable part of the stack the most trusted job.

Operating systems are responsible for boundaries. They decide which process can read which file, which application can use the camera, what persists after a crash, and how one program hands work to another. These are places where “probably” is not good enough.

LLMs are powerful precisely because they are flexible. They are also stochastic, context-bound, and uneven. Karpathy calls them “people spirits” and emphasizes their jagged intelligence and limited long-term memory. Those are excellent properties for a collaborator. They are dangerous properties for a kernel.

In ISPO, the model does not grant itself access. The host does. An app cannot simply decide that it may read a file, send mail, inspect another app’s data, or reach the network. It requests a specific capability; the user decides; the system records and enforces the result.

The model can propose. The operating system disposes.

That division is not a constraint around Software 3.0. It is what lets Software 3.0 graduate from demos into daily work.

Prompts are programs, but programs need somewhere to live

A prompt can produce a useful result. A durable piece of software needs more:

• state that survives the conversation
• files the user can find outside the app that created them
• permissions that can be understood and revoked
• interfaces for both people and agents
• history, so a working state can be restored
• a way for one application to hand a typed result to another
• verification that what was built is what is actually running

Without these, natural-language programming collapses into a stream of impressive one-offs. The user repeatedly explains the same context, recopies the same data, and re-establishes trust on every turn.

ISPO gives each project a durable home: its files, its app, its data, its conversation, and its history stay together. The agent can change the software, but the software remains after the agent leaves.

This is a subtle inversion. The prompt is not the product. The prompt changes the product.

Partial autonomy is a product architecture

Karpathy’s most practical argument is not for full autonomy. It is for fast generation-and-verification loops, custom interfaces, and an “autonomy slider” appropriate to the task. His warning from self-driving is concise: “demo is works.any(), product is works.all().”

ISPO shares that caution.

Creating an app begins with a plan. The plan names the workflow and the access it will require. The person reviews it before construction starts. When the app runs, sensitive actions cross explicit system boundaries. When an agent changes the app, the result is built and rendered so it can be inspected. History provides a way back.

The goal is not to keep a human clicking forever. The goal is to put human judgment at the consequential boundaries:

• What are we building?
• What may it access?
• What action is about to cross an application or account boundary?
• Did the result actually work?
• Is this version worth keeping?

Everything between those boundaries is a candidate for acceleration.

This is the difference between an agent that can operate a computer and a computer designed for agents.

Build for agents—and for the person supervising them

Karpathy argues that agents are a new consumer of digital information, alongside humans using GUIs and programs using APIs. That has immediate design consequences: documentation should be legible to models, workflows should expose structured actions, and important state should not be trapped behind pixels.

ISPO takes this further by making the dual interface a platform primitive.

People get applications: visual tools for browsing, editing, comparing, and deciding. Agents get explicit capabilities: typed commands, structured entities, file handoffs, skills, and bounded connectors. The two meet at the same durable object instead of operating parallel worlds.

That matters because neither interface is sufficient on its own.

A GUI gives a person overview and control, but it is a poor protocol for an agent. An API gives an agent precision, but it rarely helps a person understand the state of the work. Software 3.0 needs both: interfaces that make generation efficient and verification cheap.

The visible app is not legacy baggage. It is part of the control system.

From software for markets to software for one

Industrial software is shaped by distribution economics. Building an application is expensive, so the result must serve a large market. Features converge on the median customer. Niche workflows live in spreadsheets, glue scripts, or someone’s head.

When agents lower the cost of building and maintaining software, the minimum viable market can shrink dramatically—sometimes to one person, one team, or one afternoon.

That does not mean every prompt should create a disposable app. It means software can finally fit the shape of the work.

A researcher can make a source-review tool around their own method. A producer can build a peculiar approval queue. A family can create a shared system that reflects how they actually plan. If the workflow changes next month, the software can change with it.

This may be the most consequential promise of Software 3.0: not infinite software, but software with a much closer fit.

ISPO is a bet on the missing layer

Karpathy closes by saying that we are in the 1960s of this new computing era. The foundational machines exist, but the conventions around them are unsettled.

ISPO is a bet about what one of those conventions should be.

The model should be replaceable. The user’s files and data should not be.
The agent should be powerful. Its authority should be explicit.
Apps should be generated. They should also be inspectable, durable, and composable.
Conversation should be a programming interface. It should not be the only interface.
Autonomy should expand where trust is earned, not where friction is merely inconvenient.

Software 3.0 gives us a new way to tell computers what we want. That is the beginning, not the end.

The next question is where that intent lands—what remembers it, constrains it, renders it, connects it, and gives it back to us as something we can rely on.

That is the operating system we are trying to build.