What is Software 3.0?

Software 3.0 is the conceptual framework Andrej Karpathy used, in a June 2025 talk at Y Combinator's AI Startup School, to distinguish three generations of software. In Software 1.0 the program is code written by hand by a developer, explicit instructions executed line by line. In Software 2.0 the program is the weights of a neural network learned from data during training: nobody writes those rules by hand, they emerge from optimization over a dataset. In Software 3.0 the program is an instruction in natural language, a prompt, which a language model interprets and executes in place of compiled code. This is not the day to day practice of writing software by conversing with a model, that is vibe coding, but the structural shift in the very concept of a program: what it means to own, version and maintain an artifact that is no longer deterministic and that can change behavior without anyone having touched it.

What changes for whoever buys and maintains software

For whoever buys and maintains software inside a company, the distinction is not academic. If the program is a prompt, who owns it? Often it is no longer just the engineering team: whoever wrote that text, perhaps a business analyst with no developer training, becomes part of the accountability chain as much as whoever wired it into the system. Versioning changes nature: tracking edits to the prompt text is not enough, because the exact same prompt can produce different output once the vendor updates the underlying model, an event the client company does not control and often does not see coming. This touches themes already covered elsewhere in the glossary: code ownership gets blurrier when the code is natural language text, and technical debt takes a new shape, made of undocumented, untested prompts that nobody remembers the reasoning behind anymore.

An enterprise case

A team replaces a hand coded business rule, say the approval criteria for a refund, with a prompt describing the same logic in natural language and versions it in an internal registry alongside the reference model. It works, until the vendor ships a new model version and behavior shifts slightly: edge cases that used to get approved now get rejected, without a single line of the prompt having been touched. Nobody in the company "broke" anything, yet behavior changed: that is the first scenario a compliance officer needs a plan for before adopting this pattern.

Why it matters for decision makers

For decision makers, the practical implication is about procurement and governance more than technology. Before adopting a workflow where the program is a prompt, it is worth asking who signs off on the last approved version, how you run regression tests on non deterministic output, and what happens contractually when a vendor's model update changes a behavior the company was relying on. These are new questions that change management processes built for Software 1.0 do not cover.