Software 3.0 is a mental model. Don't ship it as a roadmap.
Andrej Karpathy's June 2025 keynote at YC AI Startup School framed three paradigms of software production: Software 1.0 (humans write code in formal languages), Software 2.0 (humans curate datasets, models learn weights), Software 3.0 (humans write prompts, the model produces behavior). The argument that landed was that the existing web stack — HTTP, HTML, the request-response cycle, the tool-use APIs that grew up around human-readable interfaces — was built for human developers and is therefore the wrong substrate for AI-class consumers of the same software.
_Software 3.0 is a mental model. Don't ship it as a roadmap._ Hold that distinction in view. Everything that follows traces back to it.
A mental model tells you what to throw away. A roadmap tells you what to build. The Software 3.0 framing does the first cleanly. It does the second only loosely.
What the framing throws away cleanly: the assumption that the consumer of every API is a human developer. The HTTP stack carries human-developer assumptions everywhere — authentication flows designed for browser-based identity, error messages calibrated to human-readable debugging, rate limits tuned to human request cadences, documentation written for human reading. Every one of those is wrong substrate when the consumer is an AI agent. Karpathy's argument is that the substrate has to be rebuilt.
What the framing does not tell you cleanly: what the rebuilt substrate looks like. Karpathy gestured at it with examples (the AI-readable docs format, the structured-output API, the agent-runtime APIs). The gestures are correct directionally. They are not, in operating terms, a buildable spec. The spec is what the next two years of frontier-lab and protocol-class work has to produce.
Operators reading the talk as a roadmap built things that ran ahead of the spec. Operators reading it as a mental model used it to evaluate what to throw away in the existing stack. The first group built artifacts that need to be rebuilt eighteen months later. The second group ran lighter and absorbed less rework cost.
Trace back to the mental-model frame and the throw-away-bound discipline sharpens. When the substrate is rebuilding, the operating-correct move is to identify what in the current stack is now actively wrong and remove it (or wrap it for migration). The build-bound work — the new substrate, the new APIs, the new agent-runtime conventions — is happening at the protocol layer at frontier-lab and standards-body cadence, and operator-class work in that layer is mostly absorbing the cost of ships that the protocol layer subsequently changes. Throw-away-bound work compounds because each thing thrown away clears decision space for whatever the protocol layer ships next.
Trace back to the framing's load-bearing claim and the substrate-was-built-for-humans argument surfaces as the durable piece. That claim is correct on the technical merits. It is the argument operators should reuse when defending stack-modernization investments to non-technical stakeholders. The "Software 3.0" naming is the rhetorical wrapper; the substrate-was-built-for-humans argument is the operating substance. Use the wrapper when the audience is technical-class familiar with Karpathy. Use the argument when the audience is finance-class or board-class.
Trace back to the gap between mental-model and roadmap and the operator-tier confusion locates itself. Operators who treat Software 3.0 as a roadmap make spec-level commitments before the protocol layer has stabilized. Operators who treat it as a mental model preserve optionality. The right read is the mental-model read for the next eighteen months, then a roadmap read once the protocol layer's MCP-class standards have stabilized at the major-frontier-lab level. By 2027 the roadmap read will be operating-correct. In 2025-2026 it is premature.
The same shape recurs across regulated categories with their own substrates. Healthcare-AI runs into the EHR-substrate-was-built-for-humans problem; the EHR's UI was designed for clinician input, not for AI consumption, and the substrate has to be rebuilt for AI-native workflows. Travel-AI runs into the OTA-substrate-was-built-for-humans problem; the OTA's checkout flow was designed for human shoppers, not for agent-class buyers. Each category has its own substrate-rebuild question. Each category's question is, in operating terms, more constrained than the general-purpose AI substrate question because the regulated category has compliance and integration constraints the general-purpose category does not.
What survives all of this is that the Software 3.0 framing is one of the cleaner mental models for the substrate transition, the press-class read is treating it as a roadmap, and the operator discipline is to use it as a mental model that informs throw-away-bound stack-modernization decisions. The roadmap version of the same argument will, in operating terms, be available by 2027. Building against the roadmap version now is too early. Reading the mental-model version now is exactly on time.
Karpathy named three paradigms. The naming is correct. The order in which operators should engage with the third paradigm is throw-away first, build second. Most operators are doing the inverse and are paying the cost of the inversion in rework. The operating-correct sequencing is the part the talk does not specify and the operator class has to figure out from the substrate.
Software 3.0 is a mental model. The roadmap is the part you have to build into your own plan, calibrated to your category's substrate constraints. Karpathy's talk does not do that work for you. It does the throw-away work cleanly. The build work is yours.
—TJ