Andrej Karpathy: Software Is Changing (Again)

At a glance

Andrej Karpathy's keynote at Y Combinator's AI Startup School is the strategy talk of this track. His claim is that software has now had three major versions. Software 1.0 is code a person writes. Software 2.0 is neural network weights, which you do not write but rather produce by curating a dataset and running an optimizer. Software 3.0 is prompts, which is to say programs written in English and executed by a large language model.

From there he works through three analogies for what these models actually are, utilities, fabrication plants, and above all operating systems, and lands on a dating of the current moment: we are in the 1960s of LLM computing, with expensive centralized compute, time sharing, thin clients, and no personal computing revolution yet.

The second half turns practical. Build partial autonomy products with an autonomy slider. Keep the generation and verification loop tight, which usually means a graphical interface for verification and small chunks for generation. Keep the AI on a leash. And start writing your documentation for agents, not only for people, because a growing share of your readers are not human.

The deep explanation

Three versions of software

Software 1.0 is the instructions you write for a computer. Software 2.0, a term Karpathy coined years ago, is the weights of a neural network: you do not write them, you specify a dataset and an objective and an optimizer produces them. He notes that this shift already came with its own infrastructure. GitHub is where Software 1.0 lives; Hugging Face is the equivalent for Software 2.0, and the model atlas is its map.

Software 3.0 is the new one. Large language models are programmable in natural language, so a prompt is a program, English is a programming language, and the person writing it may have no engineering background at all. His illustration is sentiment classification, which can be written three ways: as Python code, as a trained classifier, or as a sentence of instruction. Same task, three eras.

The strategic advice that follows is short. You should be fluent in all three, because real systems shuttle between them, and the interesting products decide which parts of a problem belong in which paradigm.

Three analogies for what an LLM is

A utility. Training a frontier model is capital expenditure, serving it is operating expenditure, and what customers buy is metered intelligence delivered over an API. The consequences are recognizable from the electricity grid: demand for low latency, high uptime, and consistent quality. Karpathy notes that we now have the equivalent of a brownout, when a major provider goes down and a slice of the world's cognitive infrastructure goes with it. The open weight models are the generator in the basement.

A fab. The analogy captures the capital intensity, the secrecy around process, and the small number of players who can afford the frontier. Training runs cost what fabs cost, the trade secrets are real, and there is a similar dynamic between companies that own their own capability and those that rent it.

An operating system. This is the one he thinks is most useful, and he develops it furthest. LLMs are not a commodity like electricity because they are increasingly complex software ecosystems, not fungible units. The shape matches the operating system industry: a few closed source providers, an open source alternative in the Llama ecosystem playing the role Linux played, and applications built on top that can in principle be moved between them.

Push the analogy down a level and it keeps working. The LLM is the CPU. The context window is memory, the thing the processor can directly address, which the operating system has to page information into and out of. Tools are peripherals. The chat interface is a terminal, which is to say a text stream to the machine, and the graphical user interface for this technology has not been invented yet, which he flags as an enormous open opportunity.

The dating that comes out of this is the memorable part. Compute is expensive and centralized, users are on thin clients talking to it over a network, and time sharing is how it is allocated. That is the 1960s. The personal computing revolution for this technology has not happened, and it is not obvious yet what form it takes.

There is one striking inversion he draws out. Historically transformative technology arrived at governments and corporations first and reached consumers last, because it was expensive. This one inverted: consumers got it immediately, and institutions are the laggards. Billions of people had access to a frontier model before most large organizations had a policy about it.

The psychology: what these things are like to work with

Karpathy's framing is that LLMs are stochastic simulations of people, with a specific and unusual profile. They have encyclopedic knowledge and memory well beyond any individual, and simultaneously a set of cognitive deficits you have to design around:

• Jagged intelligence. Superhuman in some places and startlingly wrong in others, with no clean boundary between the two and no reliable way to predict which you are about to get.
• Anterograde amnesia. Nothing consolidates. Every session starts fresh, and the context window is wiped. He compares it to Memento and 50 First Dates: a colleague who cannot form long term memories and whose notes are all you have.
• Gullibility. They can be talked into things, which is the security surface known as prompt injection.

The practical conclusion is that products should be designed around this profile rather than pretending it away.

Partial autonomy, and the autonomy slider

The centerpiece of the practical half is the idea of partial autonomy products, and the reference image is the Iron Man suit: both an augmentation you wear and an autonomous agent that can fly on its own, with a dial between the two. His argument is that right now the augmentation setting is where the value is, and the products should be built with the dial exposed.

The examples he uses are the coding tools and search products where you can choose the size of the unit of work: change one line, change one file, change the whole repository. That is the autonomy slider, and the user moves it based on how much they trust the system for the task at hand.

The design principle underneath is the generation and verification loop. The model generates, the human verifies, and the speed of the whole system is set by the slower of the two. So:

• Make verification fast, which usually means visual. A diff, a rendered result, a highlighted change. Reading a wall of text is the slowest possible verification.
• Keep generation small. He is blunt about this: do not accept a ten thousand line diff. Keep the AI on a leash and work in chunks you can actually check, because an unverifiable output has not saved you anything, it has moved the work to debugging.
• Concrete beats abstract. Ask for specific changes rather than vague improvements, because specific requests are verifiable and vague ones are not.

He grounds this in his own experience of vibe coding, a term he coined, and specifically in a small project called MenuGen that turns a photo of a restaurant menu into pictures of the dishes. The demo took roughly an hour. Making it a real thing that other people could use, authentication, payments, deployment, took about a week, and none of that week was the AI's contribution. His point: the model handles the part we used to think was hard, and the remaining work is the plumbing nobody wrote a demo about.

Building for agents

The final section is the one with the most immediate action items. There is a new category of consumer of your software, and it reads.

Historically digital information had two audiences: humans through a graphical interface, and programs through an API. Now there is a third, an agent that is a program that behaves like a human reader. The infrastructure for serving that reader barely exists, and the analogy he uses is robots.txt: a simple file at a known location that tells a crawler how to behave. The proposal circulating is llms.txt, a plain markdown file that tells a model what your site or product is and how to use it.

The rest of his checklist:

• Write documentation in markdown, not as HTML pages that need to be scraped and stripped.
• Replace instructions like "click this button" with commands a model can execute, such as a curl call. An agent cannot click.
• Make repositories and docs ingestible, and he points at the tools that flatten a repository into a single readable text file for exactly this purpose.

He notes that companies were already adapting, with several developer platforms publishing markdown documentation aimed at models, and frames it as low effort with an outsized payoff, because meeting the model halfway is far cheaper than waiting for the model to get good enough to not need it.

The decade of agents

The closing line is a correction of a slogan. Not the year of agents, the decade of agents. The technology is real, the trajectory is clear, and the work of turning it into reliable systems is a long grind rather than a step change. In the meantime, the thing to build is partial autonomy with a human in the loop, and the thing to remember is that a whole generation of software is being rewritten by people whose programming language is English.

Key takeaways

• Three eras of software: code, weights, and now prompts. Being fluent in all three is the actual skill, because real systems move between them.
• LLMs behave like utilities in their economics, like fabs in their capital intensity, and most usefully like operating systems in their ecosystem shape.
• The mapping is concrete: model as CPU, context window as memory, tools as peripherals, chat as a terminal. The graphical interface for this technology has not been invented.
• We are in the 1960s of this computing era: expensive centralized compute, time sharing, thin clients, no personal computing revolution yet.
• The technology diffused backwards. Consumers got it first, institutions last, which is the reverse of every previous transformative technology.
• Design for the psychology: jagged intelligence, no persistent memory, and gullibility that becomes a security surface.
• Build partial autonomy with an autonomy slider. Speed comes from the generation and verification loop, so make verification visual and keep generation small.
• The demo is an hour and the product is a week. The remaining work is plumbing, and that is where the effort now goes.
• Write documentation for agents: markdown, executable commands rather than click instructions, and a plain file that tells a model what your product is.

Where this sits in the LLM Learning track

This closes the track. Everything before it explains the technology; this explains what to do about it, and it is the only video here written for someone deciding what to build rather than how it works. Read it after the Sutskever talk, which sets up the research question, and treat the two together as the pair of open questions the field is currently living inside: where does the capability come from next, and what do we build with what we already have.

Resources mentioned

• Software 2.0, Karpathy's original essay on the second era
• Y Combinator's AI Startup School and the talk's library page
• GitHub and Hugging Face as the repositories of the first two eras
• Llama and the open weight ecosystem
• Cursor and Perplexity as examples of products with an autonomy slider
• The llms.txt proposal for making sites readable by models
• Anthropic's Model Context Protocol, the emerging standard for connecting models to tools and data
• Memento and 50 First Dates, his reference points for the memory problem

About this page

This reconstruction was built from the public record of the keynote rather than from its caption track, because the machine that assembled it had no network route to YouTube. The argument, the analogies, and the practical checklist are here; the verbatim transcript, the timestamped chapter map, and pull quotes are not, and those get backfilled on the next run from a machine that can reach the source. Until then, watch it on YouTube alongside this page.