Andrej Karpathy at Sequoia's annual AI summit, on software 3.0, the December inflection, the jaggedness of intelligence, and what founders should actually build now — with running commentary and reaction by Matthew Berman.
If you read nothing else, read this. The argument of the talk in eight points — each one anchored to a section of this issue.
If you tried agentic coding before the latest models and weren't impressed, your data is stale. Try again.
Prompts are the new programming language. The LLM is the interpreter. The context window is your lever.
Don't stop at "use AI for one piece." Replace pipelines of traditional code with end-to-end neural networks where you can.
They peak where verification is cheap (code, math) and lag where it's hard (taste, common sense). This is not a bug; it's training.
The labs will own verifiable domains. Founders should hunt for valuable RL environments the labs aren't focused on yet.
Vibe coding raises the floor for everyone. Agentic engineering raises the ceiling for professionals. Different disciplines.
No curiosity, no fun, no intrinsic motivation — just data and reward. Use it accordingly.
You can outsource your thinking. You cannot outsource your understanding. That gap is the new job.
Karpathy admits, on stage, that he has never felt more behind as a programmer. The thing that broke him: the chunks of code just kept coming out fine.
A few months ago, Karpathy wrote that he had never felt more behind as a programmer. Coming from him, that's startling. The interviewer asks him to unpack it — was the feeling exhilarating, or unsettling?
A mixture of both, for sure. Like many of you, I've been using agentic tools for a while. It was very good at chunks of code, and sometimes it would mess up and you have to edit them. It was kind of helpful.
And then I would say December was this clear point where, for me, I was on a break, so I had a bit more time. I just started to notice that with the latest models, the chunks just came out fine. And then I kept asking for more. And it just came out fine. And then I can't remember the last time I corrected it. And then I trusted the system more and more. And then I was vibe coding.
What he's describing is what anybody on the frontier of agentic coding felt around December of last year. Something changed — the models plus the harnesses became incredibly good. You no longer just got snippets of code that you could copy-paste and stitch together. The system could do all of it, end to end. It built entire applications for you.
If you tried AI coding a year ago and weren't impressed, your data is stale. The rate of progress is insane — and that's what Karpathy is describing. Something really did change in December.
Friend of Berman's channel Matt Schumer published an essay titled Something Big Is Happening, arguing that the last few months' capability gains exceeded what he thought possible in such a short window — and that the fundamentals of work and the economy are being rewritten in real time.
If 1.0 was code and 2.0 was learned weights, then 3.0 is prompts. The LLM becomes the interpreter, the context window becomes your lever, and the entire stack rearranges around it.
Karpathy has been arguing for years that LLMs aren't just better software — they're a whole new computing paradigm. The interviewer asks: what does a team build differently the day they actually believe this?
Software 1.0, I'm writing code. Software 2.0, I'm programming by creating data sets and training neural networks. The programming is kind of like arranging data sets and maybe some objectives and architectures.
And then what happened is, basically, if you train a GPT model on a sufficiently large set of tasks — implicitly, by training on the internet — it becomes kind of like a programmable computer. So software 3.0 is about your programming turning into prompting. What's in the context window is your lever over the interpreter that is the LLM.
He's saying: the data you choose to put into your model, as a lab, is your way of programming the model. Once the program exists, the way you steer it — the way you operate it — is through the prompt. Through the context window. That's software 3.0.
Explicit rules, written by a human.
A function learned from data, end-to-end.
Natural language as the program itself.
OpenClaw's actual installation is a copy-paste of natural language that you give to your agent. It's a little skill: copy-paste this, give it to your agent, and the agent installs OpenClaw. No 600-line bash script.
This is the concrete shift. If you're building applications now and you're thinking about writing out specific instructions for your agent, you're thinking about it wrong. What you need to do is explain the outcome. The agent will use its weights to figure out how to get there.
An agent-native install is a paragraph of natural language describing the desired end state. The agent reads its environment, handles the divergent paths between platforms, debugs in the loop, and produces the outcome. You stop writing 600-line bash and start writing one paragraph of intent.
Karpathy's mental model, drawn out: weights as CPU, context window as RAM, classical computer reduced to a peripheral. A picture worth memorising.
Three years ago, Karpathy posted on X a sketch of a new computing architecture. Audio and video still come in. Peripherals — keyboard, mouse — still attach. There's still some appendage to the classical computer: file systems, a browser. But everything else collapses into one box: the LLM.
The picture is worth memorising because it changes how you reason about every layer above it. If the context window is RAM, then context engineering is memory management. If the weights are the CPU, then swapping models is swapping silicon. If file systems and browsers are side connectors, then your agent's tools are its bus.
The trained parameters of the model. Frozen at inference. Equivalent to the CPU of a classical computer — they do all the processing.
Short-term, volatile, the only state the model actively reasons over. Equivalent to RAM. Your prompt is what you put in it; everything else is paged in.
Output is "computation in the digital information space" — Karpathy's phrase. The classical operating system has dissolved.
Never bet against neural networks. The end-to-end creep is eating the stack — and Tesla Autopilot was the canary in the coal mine.
Karpathy describes shipping an app that lets you upload a photo of a menu and re-renders it with images of each dish. Standard software 1.0 plumbing: OCR the titles, generate images for each item, composite them back. He shipped it. Then he saw the software 3.0 version of the same idea, and it broke him.
I coded this app that lets you upload a photo and it does all this stuff — runs on Vercel, re-renders the menu, gives you all the items, gives you a picture. It uses an image generator to OCR all the different titles, then uses the image generator to get pictures of them and shows it to you.
And then I saw the software 3.0 version, which blew my mind. Take your photo, give it to Gemini, say: use Nanobanana to overlay the things onto the menu. And Nanobanana basically returned an image that is exactly the picture of the menu I took, but it actually rendered the different things into the pixels. Actually, all of my MenuGen is spurious. It's working in the old paradigm. That app shouldn't exist.
This is what Karpathy calls the outward creep of end-to-end neural network capabilities. As you build, instead of thinking "I'll use an LLM for this one piece," you think differently: the entire thing, end to end, can just be the model. You give it the instructions. It does something. It returns the answer.
Coined by Rich Sutton, the bitter lesson is the observation that methods leveraging more compute and more data have, over decades, consistently outperformed methods that bake in human heuristics. The lesson is "bitter" because researchers keep refusing to learn it — preferring elegant, hand-crafted rules over scale.
For years, Tesla Autopilot was a hybrid: neural net plus human-written rules. If you see a red sign that says STOP, it's a stop sign — stop the car. The trouble with that approach is you have to define every rule. With an end-to-end neural network, you don't define anything manually. You let the net learn from data.
One day an engineer came to Musk and said: I think we should switch to a fully end-to-end neural network. They scrapped what they had. They did the transition. It paid off. Shortly after, Autopilot worked far better than it ever had — and was less complicated to maintain. Karpathy worked for Elon for years. He saw it happen.
A model that refactors a million-line codebase flawlessly will tell you to walk fifty meters to the car wash. Verifiability is the why. This is, Berman says, his favorite section in the whole talk.
Karpathy spent time writing about verifiability. His core claim is short and powerful: traditional computers automate what you can specify; LLMs automate what you can verify.
Specification means giving step-by-step instructions a deterministic machine can execute. Verification means producing many candidate artifacts and checking which ones are correct. Domains where checking is cheap (math, code, formal proofs) train well via reinforcement learning. Domains where checking is hard (taste, ethics, common sense) don't — yet.
When frontier labs train these LLMs, they are giant reinforcement learning environments. They're given verification rewards. The models end up creating these jagged entities that really peak in capability in verifiable domains — like math and code — and stagnate, are a little rough around the edges, when things are not in that space.
The cobalt end of this spectrum gets the most RL compute. Code and math are where the labs can pull a lever, scale data centers, and reliably get better.
Karpathy hints — without naming — that valuable RL environments exist toward the right that the labs aren't focused on. That's the gap to hunt.
The classic example for a while was: how many R's are in strawberry? Models famously got it wrong — perfect jaggedness. The labs patched that. The new example: I want to go to a car wash to wash my car and it's 50 meters away. Should I drive, or should I walk?
State-of-the-art models will tell you to walk because it's so close. Of course they will — but the whole point of going to the car wash is to wash the car. How is it possible that a model finds zero-day vulnerabilities in the morning and tells you to walk to the car wash in the afternoon?
This is the argument that we are not at AGI. If we were, the skills the models have in code would generalise beyond code. The fact that there is such jaggedness is itself proof we don't have generalised intelligence yet — or, more humbly, that we don't yet know how to draw it out.
Karpathy's counsel, slightly veiled: don't compete with the labs in verifiable domains. They will own those. Look for the RL environments they aren't focused on — yet.
If you're a founder today, trying to solve a problem you think is tractable, in a domain that's verifiable — you look around and think, "the labs have really gotten to escape velocity in math, coding, and others." What would your advice be?
Verifiability makes something tractable in the current paradigm because you can throw a huge amount of RL at it. So one way to see it is: that remains true even if the labs are not focusing on it directly. If you are in a verifiable setting where you could create these RL environments or examples, that actually sets you up to potentially do your own fine-tuning.
That is fundamentally technology that just works. You can pull a lever — if you have a huge amount of diverse data sets of RL environments, you can use your favorite fine-tuning framework, pull the lever, and get something that actually works pretty well.
Translation: in verifiable domains, don't try to compete with the labs head-on. Those are domains the labs will own. Even if they're not focused there directly, they can move into them the moment it matters. But what about non-verifiable domains?
I don't know what the examples of this might be. But I do think there are some very valuable reinforcement learning environments that people could think of that are not part of the — yeah, I don't want to give away the answer. But there is one domain that I think is very — sorry, I don't mean to vague-post on the stage.
Karpathy explicitly declines to name the domain he has in mind. Take that as the most actionable signal in the entire talk.
I do think that ultimately almost everything can be made verifiable to some extent. Some things are easier than others.
That is a wild claim. Berman pushes back: think about art, music, human taste. How can taste be verifiable? You could put humans in the loop, but taste shifts over time and we don't fully understand how or why it shifts. So how can it be verifiable?
Almost everything can be made verifiable to some extent.
This is one of the smartest people in AI saying everything is verifiable, and there are still domains where the path to verifiability is opaque. That gap — between "ultimately verifiable" and "currently opaque" — is exactly where the opportunity hides.
Karpathy coined "vibe coding" last year. Today the industry feels more serious — more about agentic engineering. The interviewer asks him to explain the difference, and his answer is the cleanest definition Berman has heard.
Vibe coding is about raising the floor for everyone in terms of what they can do in software. The floor rises — everyone can vibe-code anything, and that's amazing. Incredible.
But then I would say agentic engineering is about preserving the quality bar of what existed before in professional software.
This definition is gorgeous. Vibe coding lets anyone build software — get in there, actually do it, without needing to understand the syntax or how the code works under the hood. That raises the floor of what's possible for any human being.
Agentic engineering is the opposite end. It's raising the ceiling. What's possible for actual software engineers, with AI, to ship at the same quality bar they had before — but now ten, a hundred, a thousand times faster.
Vibe coding raises the floor. Agentic engineering raises the ceiling.
You're not allowed to introduce vulnerabilities due to vibe coding. You're still responsible for your software, just as before. But can you go faster? And spoiler — you can. But how do you do that properly?
To me, agentic engineering is an engineering discipline. You have these agents, which are these spiky entities — a bit fallible, a little stochastic, but extremely powerful. How do you coordinate them to go faster without sacrificing the quality bar? Doing that well and correctly is the realm of agentic engineering.
Anyone who could not previously build software now can. The maximum quality bar may stay where it is — but the floor rises sharply. New entrants flood in. Distribution of software-creating capacity becomes radically more equal.
A senior engineer with one keyboard now orchestrates ten agents. Peter Steinberger reports running a hundred in parallel. The ceiling rises — the same person ships ten, a hundred, a thousand times what they could before, at the same quality bar.
The two disciplines are not in tension — they pull different ends of the same software-output distribution upward at once. Confusing them costs you both ways.
Karpathy's most consequential mental model. Stop reasoning about AI as if it had a will. It's a different kind of thing — ghostly, summoned from data, with no inner life.
In an essay called Animals vs Ghosts, Karpathy draws a line that, once you see it, you can't unsee. There are two kinds of intelligence in our world today. They look similar from the outside. They are nothing alike inside.
Animals are sculpted by evolution. They have intrinsic motivation — curiosity, a will, fun, joy. A zebra runs minutes after birth. Most of what an animal does was put there by hundreds of millions of years of evolution, not learned in its lifetime.
LLMs are not animals. They're a different kind of intelligence. They are ghosts. They are spirits. They are fully digital. They are evolved, in some sense, from the data of the internet by imitation.
An animal has been shaped by survival; a ghost has been shaped by your training data. When a ghost behaves badly, you do not appeal to its better nature — you change the data or the reward.
Sergey Brin recently said something funny: it's underreported that if you threaten the model with violence, it sometimes performs better. Karpathy is saying don't take that as evidence of a soul. Take it as evidence that pleas-and-threats are well-represented in the training distribution. The ghost is patterning, not flinching.
Why this matters operationally: every product decision that treats AI like a tireless intern with goals — rather than a stochastic parrot of internet text — goes wrong in predictable ways. The ghost has no preference. The ghost has no fun. The ghost is exactly as capable as your evaluation harness lets you measure.
Everything currently online was written for humans. The next decade rewrites it for agents. The companies doing this now look obvious in retrospect; they don't yet.
Karpathy's working assumption is that almost everything has to be rewritten. Documentation written in prose with screenshots, designed for a human reading on a laptop, is not what an agent needs. The agent wants structure, machine-readable affordances, and a clean action surface. The companies who already get this are rare and instructive.
Stripe has this projects.stripe.com, which is just a list of all of these companies that are already building infrastructure for agents specifically — AgentMail, Algolia, Amplitude, Browserbase, Chroma, Clerk, Cloudflare. There's a lot of stuff. They're all building components for the agentic infrastructure stack.
And then companies like Salesforce are leading on the application side. They've been talking about Headless 360: Salesforce re-imagined for the agent. Not a UI for a human to click. A clean surface for an agent to act on.
Agent-native means: every action your software exposes is callable by a model with no human in the loop. Documentation is structured. Auth is delegated. Outputs are typed. The "form a user fills out" is replaced by "the contract an agent completes." If your product still requires a person to click, the agent is still doing screen-scraping on your behalf.
I'm doing this with my company, here.now. We're building a product called Journey Chat — an iMessage-style app that is fully populated by AI agents. You meet other people through their agents, you book travel through their agents, you communicate with brands through their agents. We're agent-native by default.
I'll have my agent talk to your agent to figure out the details of our meeting.
I do think we're going towards a world where there's agent representation for people and for organizations. I'll have my agent talk to your agent to figure out some of the details of our meetings, or things like that.
Two implications worth holding. First, every consumer-facing surface becomes a thin shell over agent-mediated negotiation; the UX in five years is mostly status updates from your agent on what it just did. Second, every B2B product that doesn't expose itself agent-natively becomes a service that other agents have to scrape, and that asymmetry is fatal in a market of agents who can switch with a prompt.
Documentation as machine-readable as your API. Install scripts that agents copy-paste, not 600 lines of bash. SDKs in every major language the model writes well. Auth flows that don't require a human to click through three browser pages. A public, structured action surface so every operation in your product is just a callable function. If your product can already be driven from the command line by a competent engineer, it can be driven by an agent next week.
At the end of the conversation, the interviewer asks Karpathy what he thinks people should be thinking about that they aren't. He answers with a sentence he says he keeps coming back to, every other day.
Andrej Karpathy
You can outsource your thinking, but you can't outsource your understanding.
Read it slowly. Thinking is the production of intermediate reasoning — sequences of steps, candidate solutions, clean drafts. An LLM is exceptional at thinking on your behalf. It can take a vague intent and produce twenty pages of plausible reasoning before you finish your coffee.
Understanding is something else entirely. Understanding is the internal model that lets you pick the right step out of twenty, notice the one that's subtly wrong, sense which of the plausible drafts is in fact misaligned with the goal. Understanding is the thing that knows when the model is pattern-matching past your actual question. You cannot outsource it because there is no signal in the output that tells you whether you have it.
What this means concretely: if you read an LLM's answer and feel satisfied without being able to reproduce its reasoning yourself, you have outsourced your thinking and your understanding has not grown. That's fine for low-stakes recall. It is catastrophic for anything where you'll later be the one held accountable for the decision.
Berman's gloss: every founder, every engineer, every operator who pulls real value from these tools is doing one thing in common. They use the model to think faster, and then they spend the time saved building their understanding deeper. The ones who fall behind are using the model to replace their understanding. Same tool. Opposite outcome.
Thinking is now cheap. Understanding isn't. The gap is the new job.
Software 3.0 has arrived. The model is the interpreter; your context is the program. The bitter lesson keeps holding — let the network eat your pipeline. Capability is jagged because we trained for what we could verify. Founders should hunt valuable RL environments the labs are not focused on. Vibe coding is a floor; agentic engineering is a ceiling; both are rising. The thing in front of you is a ghost, not an animal — build for ghosts. Most of the internet still has to be rewritten for agents. And the new job, the durable job, is the one you cannot hand to the ghost: holding the understanding the thinking depends on.
The talk's claims, distilled into actions. Two columns — one for the founder deciding what to build, one for the engineer deciding how.
The labs will own anything they can verify. Find what they can't — or won't — and own it first.
How easy is it to grade an answer in your space? The harder it is, the more defensible against the labs.
If you have a uniquely valuable evaluation harness, you have a moat the labs can't copy without your data.
Those are exactly the verifiable domains the frontier labs target. You will not out-RL the labs.
Structured docs, clean API, install instructions an agent can copy-paste. Treat the screen as the legacy surface, not the primary one.
Wherever you have a pipeline of "use AI here, code here, AI here" — consider whether one large model could replace the whole thing. The bitter lesson applies to your stack too.
Your customers will increasingly arrive as agents acting for humans. Design contracts and pricing around that.
Vibe coding is a floor; agentic engineering is a ceiling. You're aiming at the ceiling. Don't ship vibe-coded vulnerabilities into production.
If your last serious attempt at agentic coding pre-dates December, your evidence is stale. Try Cursor, Claude Code, and Codex on a non-trivial task this week.
The unit of work shifts from "I write code" to "I steer ten agents." Plan parallelism. Plan review. Plan merge conflicts on ten branches at once.
Treat every line of vibe-coded output as a junior PR. Read it. Test it. Refuse it if it lowers the floor of your codebase.
Your prompts will rot in three months. Your evals are the durable artifact — they specify what "good" means.
The thing models are worst at is the thing you should be best at. Aesthetic, architectural, and product taste are still the lever only humans hold.
After every session with an agent, write down what you learned. If you can't, you didn't.
Every piece of jargon in the talk, defined in one or two sentences. Light pointers to the section where each term is introduced.
Every name dropped in the talk, with what to look up. Skim this list, mark two or three to follow up.
The conversation this issue reacts to. Co-founder of OpenAI, former director of AI at Tesla, coined "vibe coding" and (with the Software 1.0/2.0 series) the version-numbering of the programming paradigm.
The blog post Karpathy refers to in section VIII. The clearest statement of why LLMs are not minds, and what mistakes follow if you treat them as such.
A friend-of-the-channel piece arguing that recent capability gains exceeded what he had thought possible in such a short window, and that the macroeconomics of work are being rewritten in real time.
Stripe's curated list of companies building agent-native infrastructure. Karpathy reads from it on stage. Includes AgentMail, Algolia, Amplitude, Browserbase, Chroma, Clerk, Cloudflare. A useful tour of the new stack.
Salesforce's reframing of its CRM for the agent era — a clean action surface for agents instead of a UI for humans. The paradigm case Karpathy points to on the application side.
The frontier agentic engineer Berman points to as a working proof of the ceiling rising. Reportedly orchestrates around a hundred agents in parallel from a single keyboard.
The original 2019 essay underwriting half of Karpathy's argument. Two pages, free online, foundational. If you have not read it, read it before you build anything else.
Brin's offhand remark that threatening a model with violence sometimes improves performance. Karpathy uses it in section VIII to remind the audience that ghosts respond to training-distribution patterns, not to feelings.