Most people who write about Karpathy's Software 3.0 summarize the talk. I did something less glamorous: I turned it into a section of my repo's CLAUDE.md and made an agent follow it on every task. There is a literal heading called "Karpathy + Project Workflow" in the config file governing this website's codebase, and after months of running it daily, my position is simple — Software 3.0 isn't a prediction to debate, it's an operating change you either encode into your workflow or keep performing on Twitter.
Here's the framework, what it made me kill, and the four bets I'm actually building against in 2026.
What Karpathy actually said
The framing, from his June 2025 YC AI Startup School keynote: Software 1.0 is code humans write — explicit rules, deterministic logic. Software 2.0 is neural network weights — the model learns the function instead of an engineer specifying it. Software 3.0 is LLMs as programmable computers: you program them in English, with prompts, examples, tools, and context. The prompt is the source code; the LLM is the interpreter.
At his Sequoia AI Ascent 2026 fireside chat, he pushed the frame further. Vibe coding — his own coinage — raises the floor: anyone with taste and patience can now ship working software. Agentic engineering raises the ceiling: it's the discipline of coordinating fallible, stochastic, extremely powerful agents to ship professional software without sacrificing the quality bar. And he named December 2025 as his personal inflection point — the month AI-generated code became consistently trustworthy enough that his own hand-written share of code inverted.
I noticed the same shift on my own machine around the same time; I just didn't have language for it. I stopped reading every Claude Code diff line by line, because the cost of full review had started exceeding the benefit. The floor moved. But — and this is the part almost nobody says clearly — the floor moving doesn't mean your app ideas got better. It means a lot of them stopped needing to exist.
The MenuGen test
Karpathy's own example is MenuGen, an app he built that took a photo of a restaurant menu and rendered images of each dish. Useful, shipped, real. Then frontier multimodal models got good enough that you could drop the menu photo into a chat and type "show me what each dish looks like" — an app that can be fully engulfed by the model layer, in his words.
The test I now run on every project idea before writing code: if a single multimodal LLM prompt can do 80% of what this app does, it shouldn't exist as a standalone app. It should exist as a prompt, a saved skill, or not at all.
I evaluate client briefs against this constantly, and after 8+ years and 1,500+ projects I can tell you roughly half the AI-app ideas that reach my inbox fail it. They're SaaS wrappers around a twelve-line prompt — auth, billing, a dashboard, and a thin orchestration layer around a capability the model already ships natively. The founders aren't building software; they're building plumbing with a subscription price, and the next model release deletes them.
The test isn't pessimism. If your product can be replicated by one prompt, you're building a feature for someone else's product.
What I actually killed
The talk's what-should-die framing is easy to nod at and hard to apply to your own work. Here's my honest kill list from this year:
An automated news-content pipeline. I had an agent-driven AI-news section on this site. When I finally audited it properly, most of its cited sources were dead or never existed — the pipeline was generating plausible-looking journalism with no verification loop. I unpublished all 36 articles in one pass and purged the caches. That kill taught me more about Software 3.0 than any keynote: an agent pipeline without a mechanical correctness check doesn't degrade gracefully, it fabricates confidently. Which is exactly Karpathy's verifiability point, from the wrong side.
Eleven near-duplicate service offerings. My services catalog had accumulated overlapping gigs the way agent-assisted content always accumulates — cheap to generate, expensive to maintain. I merged eleven near-duplicates into five canonical services with 301s. Generation cost collapsing means curation is now the scarce input.
Six thin portfolio stubs. Same logic, merged into one real showcase. The pattern across all three kills: the model made producing things free, so the discipline moved to deleting things.
The workflow, operationalized
Here's the part I can show receipts for. My repo's CLAUDE.md contains this, verbatim:
## Karpathy + Project Workflow
**Before implementing, state:**
1. **Domain** — Blog / Shop / Website / core...
2. **Sibling pattern** — which existing file am I copying from?
No new abstractions without a reason.
3. **Verify steps** — concrete project commands, not "make it work"
Three constraints, checked before any code gets written. The agent names the domain it's working in, names the existing file whose pattern it's copying, and lists the exact verification commands — the test filter, the formatter, static analysis at level 8. There's a matching "skip list" for trivial tasks (typo fixes, translation keys), because ceremony that applies to everything applies to nothing.
This is agentic engineering at kitchen-table scale: specs before code, plans before edits, tests as the primary signal, diff review on anything touching auth or data. None of it is new — it's the engineering discipline that survived the last decade, aimed at a collaborator that is fluent but not careful. The value of judgment went up; the value of typing went down. My guide to installing Karpathy-style CLAUDE.md and skills covers the mechanical setup.
One honest note on multi-agent orchestration, since the discourse is obsessed with it: parallel agents work for me only when the tasks are genuinely independent — batch content migrations, isolated worktree builds, worker pools with no shared creative state. Every time I've tried parallelizing work where agents needed each other's context, reconciling their outputs cost more than one well-fed agent would have. Karpathy's caution against running ahead of what models can coordinate matches what my own pipelines keep teaching me, and knowing when not to spawn another agent is mostly a discipline problem.
The four bets I'm building against
1. Clarity tools, not speed tools. The first wave of AI products sold speed; that race is over — everything is fast now. The durable pattern is "let me show you what you're missing": tools that surface unasked questions, implicit assumptions, and weaknesses before shipping. My own content pipeline runs self-evaluation rubrics that block publishing until quality gates pass — the output isn't faster, it's checked. Speed is a commodity. Clarity is a moat.
2. Agent-first infrastructure. Agents are becoming the second audience for every website and API, and they don't want your UI — they want clean structure, machine-readable metadata, predictable errors. I practice this on my own platform: this site serves /llms.txt and /llms-full.txt from a dedicated controller, cached and rebuilt every six hours from the live content — courses, posts, services, projects — so AI crawlers get a current, structured map instead of scraping HTML. Ship the MCP server for your product too; if a tool can be called from inside an agent runtime, it's an order of magnitude more useful to builders. My rundown of the MCPs that earn their place is the practical version of this argument.
3. Verifiable domains. The deepest and least-repeated insight from the talk: durable moats live where output correctness can be mechanically checked — code (tests, types, CI), data pipelines (schema and referential integrity), compliance (rules either pass or fail), trading (P&L). Verification signals compound: production feedback becomes training signal, and your system genuinely improves at your niche while prompt-wrapper competitors plateau together. My AI-news failure is the negative proof — I was operating in a domain (news accuracy) where I had no mechanical verifier, and the system rotted invisibly. If your product has a measurable correctness signal, you can compound. If it doesn't, you're a wrapper.
4. Software 3.0-native apps. Most "AI features" in 2026 are 1.0 apps with a bolt-on — the spreadsheet with an explain-formula sidebar. A 3.0-native app is one that couldn't have existed before LLMs were the substrate: the model is the runtime, not a feature. Ephemeral apps that exist for one workflow and dissolve. Agent-managed services where the customer-facing layer is the reasoning loop. Personal context engines that generate tools tailored to one user. The question that finds these: not "how do I add AI to my app," but "what app could only exist because LLMs exist?" Vibe coding is how you prototype the answer in a weekend; agentic engineering is how you make it survive contact with users.
What changed in my own work
The concrete restructuring, after sitting with the talk: every new idea goes through the MenuGen test at intake — failures get saved as prompts or skills, not repos. Every active project gets audited against the four pillars, and things that fit none of them go on the chopping block; the kill list above is that audit running. The agent-facing surfaces of my sites (llms.txt, structured APIs, MCP-callable tools) get treated as first-class product, not SEO garnish. And the verification layer — tests, rubrics, link checkers, schema validators — gets investment before the generation layer does, because generation is no longer the bottleneck and hasn't been since December.
The line from the talk worth sitting with: the job isn't to build software anymore. Software was the goal when software was the constraint. The job now is to build the things software-as-substrate makes possible — and to be honest enough to delete the things it makes unnecessary.
Open your projects folder tonight and run the test on everything in it. Be honest about which ones are plumbing around capabilities the model already has. Then kill one. Founders bring me the survivor of that exercise most weeks and ask whether it clears the MenuGen test; bring me yours and you'll get a straight answer, including the unwelcome version of it.
