The Dawn of Software 3.0
Andrej Karpathy, who coined the term "vibe coding", recently gave a talk introducing the idea of Software 3.0. Now I've poked my fair share of fun at "vibe coding", but in fairness that's less about Karpathy and more about the life and meaning the term has taken on since. Software 3.0 is a different beast. It changes how we write software, sure, but it also changes how we use it.
The way I'd frame it is that software has gone through three big iterations. The first, call it Software 1.0, is the static, deterministic stuff developers write by hand. A web app with CSS and JavaScript is the classic example: click a button, get a predictable result, because someone hardcoded the logic behind it. Software 2.0 is machine learning. Instead of writing the rules, developers feed models huge datasets and let the network work out its own parameters through optimisation. At Tesla, Karpathy watched neural networks take over perception, tracking, and sensor fusion, replacing thousands of lines of traditional code.
Software 3.0 moves the work into the prompt. What sets these systems apart is how adaptable and introspectable they are. You steer them in real time with words, and reuse one system across loads of tasks without retraining a thing. They take text, images, and audio, and with tools wired in they can reason and act.
This changes the job. Engineers spend less time building deterministic architectures and more time directing intelligent systems: unblocking agents, managing context, writing prompts, wiring up workflows.
It goes well beyond developer tooling, though. Normal software makes you translate what you want into a sequence of clicks and screens. Software 3.0 lets you just say it. Take the Trainline booking flow as an example of where the old model breaks down. You knew exactly what you wanted, to be in London by a certain time, but the rigid UI made you do all the fiddly work yourself and still let you book a fare against an expired railcard. Software 3.0 closes that gap. Rather than wading through the interface, you state the intent: "I need to be in London by 10:30am." The system works out the rest, the cheapest tickets, the right railcards, without you spelling any of it out.
That reshapes design too. Instead of sweating every individual button, spacing, and hover state, designers shape how intent gets expressed, interpreted, and confirmed. That may still involve some UI but the job moves toward the back-and-forth between what a person means and what the machine does with it.
LLMs have real flaws, mind: they hallucinate, they overreach, they forget. Tight feedback loops matter because of it. The system has to show you its read on what you meant, fast, so you can confirm it or correct it. That makes it a collaborator rather than a glorified assistant.
As these systems mature, products will prioritise outcomes over interfaces. People will stop navigating software and start stating what they want, leaving the system to sort out the how.