Karpathy Said Software 3.0. Most People Are Building the Wrong Skill Tree.
Andrej Karpathy's Software 3.0 framing isn't about prompt engineering. It's about a complete shift in what software development is — and most people are still building skills for Software 1.0.
Software 1.0 is explicit code. Software 2.0 is learned weights. Software 3.0 is prompts. The barrier to programming just dropped by an order of magnitude. The skill that used to make you valuable isn't the differentiating skill anymore.
Here's the answer up front: Andrej Karpathy has been describing this progression for a while — and the May 2026 Sequoia Ascent talk sharpened it significantly. (In the same month, Karpathy joined Anthropic to lead pre-training research, which tells you something about where he thinks the work matters most.) Most people hear "Software 3.0" and think it means they should get better at writing prompts. That's the wrong takeaway. The skill that matters in Software 3.0 isn't describing what you want. It's knowing whether you got it — and why you didn't when you didn't.
Quick translation: This post is about skill priorities. If you're a developer thinking about where to invest your learning time, or a non-developer wondering if the door just opened for you, this is the post.
What the progression actually means
Software 1.0 is what most of us learned first. You write explicit instructions. If this, then that. The computer does exactly what you wrote, precisely, including your mistakes.
Software 2.0 is neural networks. You stop writing rules. You define the desired behavior, you give it examples, and the model learns the path. The programmer shifted from writing the solution to writing the specification and the training setup.
Software 3.0 is where we are. LLMs as the runtime. You describe what you want in natural language. The model figures out the structure, the steps, the code. The line between "writing a program" and "describing what you want" has dissolved.
Here's what that means: anyone who can describe clearly what they want, and verify whether they got it, can now program a computer. Whether or not they've ever touched a for loop.
Why verification is the real skill
In Software 1.0, the value was in writing correct code.
In Software 2.0, the value moved to designing the right training setup and evaluating model outputs.
In Software 3.0, generation is cheap. Fast, cheap, available to everyone. The constraint moved again. The value now is in knowing what outcome you want, catching when the output doesn't match, and diagnosing why your specification allowed the failure.
That last clause is the whole game.
Generation is a commodity. Verification isn't. And most developers haven't invested in it because the history of software development never required it. When you wrote the code yourself, the review was built into the writing. You knew what you intended. You could read what you wrote.
When someone else writes the code — and the "someone else" is a model that's confident by default — the review is a separate, deliberate skill. And most people skip it because it's slower than just accepting and shipping.
That gap is where most AI-assisted work goes wrong.
From my own bench
I train healthcare workers on clinical software as my day job. Have for years. What I've noticed is that the people who pick up new systems fastest aren't the ones who know the most about technology.
They're the ones who can describe clearly what they need the system to do, notice when it doesn't, and adapt when the path changes.
That's Software 3.0 thinking. It's not new — it's what good systems operators have always done. What's changed is that it's now the primary skill. Not the meta-skill on top of coding. The primary skill.
I've watched brilliant developers get slower with AI tools because they trust the output of a model less than they trust their own code — which is reasonable — but then do nothing with that distrust except feel uneasy. The move is to turn that instinct into a discipline. Write the spec. Check the output against the spec. Find the gap. That's the loop.
Try it today
| Step | What you do | Why it pays off |
|---|---|---|
| 1. Write the spec first | Before you open your AI tool, write what you want in plain language: goal, constraints, definition of done | Spec quality determines output quality more than any prompting technique |
| 2. Generate, then verify | Let the model implement it. Then read the output against your spec, not your intuition | Intuition accepts things that "look right." Spec-checking catches the thing that's wrong in a non-obvious way. |
| 3. Diagnose the miss | Find the one thing it got wrong. Ask: what in my spec allowed that? Revise the spec. | The feedback loop on your specification is the actual learning. The model isn't getting better at your problem. You are. |
Where people get burned
- Over-investing in prompt tricks. Prompt engineering courses exist. They're mostly teaching local optima in rapidly changing models. Fix: invest in specification — knowing what you want — not the specific incantation that gets there. Models improve and prompt hacks expire. Clarity doesn't.
- Under-investing in verification. "Generate, accept, ship" is a pipeline for confident wrong answers. Fix: every time you accept agentic output, check it against a spec. Not your intuition. A spec.
- Thinking Software 3.0 is primarily an opportunity for developers. It's not. It's primarily an opportunity for domain experts who can describe their domain clearly. Fix: the best AI users will be the people who understood their field deeply and can articulate it precisely. Developers have a head start. Not an insurmountable one.
- Treating "I can't code" as a permanent ceiling. In Software 3.0, the ceiling moved. Fix: the question is whether you can specify and verify, not whether you can write loops.
Tools, and a question worth sitting with
- A thing to try: Karpathy's framing in the Sequoia Ascent 2026 talk is worth watching directly. He's precise in a way that summaries miss. The Software 1.0/2.0/3.0 breakdown comes in the first twenty minutes, and the "jagged intelligence" section is just as useful — it explains why the same model that can refactor 100k lines of code also gives confidently wrong walking directions. Understanding that jaggedness is part of operating it well.
- A thing to read: His previous writing on Software 2.0 from a few years back sets up the progression. The 3.0 framing builds on it directly. Find it with a quick search — it aged well.
- A question to actually sit with: What percentage of your AI workflow is generation — and what percentage is verification? If you can't answer, you probably don't have enough of the second one.
The bottom line
Software 3.0 didn't move the goalposts on coding. It moved them on what matters. Generation is a commodity. Knowing what you want and catching when you didn't get it — that's the durable skill. And most people are building the wrong thing.
The door opened for people who can think clearly about outcomes. Are you building that skill?
— Dru Edwards