Andrej Karpathy — former Tesla AI director, OpenAI co-founder, and one of the most influential voices in AI — has been quietly sketching a map of where software development is heading. Across three distinct ideas — Software 3.0, vibe coding, and the LLM Wiki — he outlines a world where natural language replaces traditional code as the primary programming interface. Each concept builds on the last, and together they paint a coherent picture of what the next decade of software engineering looks like.
The Three Eras of Software
In his YC AI Startup School talk in June 2025, Karpathy laid out a clean taxonomy of software evolution:
Software 1.0 is everything we know as traditional programming. You write explicit instructions in Python, Go, C — the computer does exactly what you tell it. The programmer is the bottleneck and the source of truth. This paradigm has dominated since the 1950s.
Software 2.0 emerged around 2017 with the deep learning revolution. Instead of writing rules, you write training pipelines — collect data, define architectures, optimize weights. The "code" is really the dataset and the neural network parameters. Tesla's Autopilot is a canonical example: no human wrote explicit rules for every driving scenario. The network learned from millions of miles of data.
Software 3.0 is the LLM era. The programming interface is natural language itself. You don't write code or curate datasets — you write prompts. The LLM interprets your intent and produces the output. The system prompt is the program. Karpathy describes this as "the built environment becoming programmable" — every app, every workflow, every business process becomes something you can reshape by describing what you want in plain English.
The recursive twist: LLMs are now generating Software 1.0 and 2.0 code. Software is eating software. The boundaries between the three paradigms blur as LLMs write the traditional code, design the neural architectures, and generate the prompts for other LLMs.
Vibe Coding: Give In to the Vibes
In February 2025, Karpathy coined "vibe coding" in a post that resonated so deeply it became Collins Dictionary's Word of the Year:
"Fully give in to the vibes, embrace exponentials, and forget that the code even exists."
The idea is deceptively simple: instead of reading, understanding, and manually editing code, you describe what you want to an AI coding assistant and accept the result. You don't debug line by line — you paste the error back into the LLM and let it fix itself. The programmer becomes a director, not an author.
This isn't theoretical. Y Combinator reported that 25% of their Winter 2025 batch had codebases that were 95% AI-generated. Tools like Cursor, Claude Code, Codex, and Antigravity made this practical — you describe a feature, the model writes it, you test it, iterate via natural language.
Even Linus Torvalds — not exactly known for embracing trends — acknowledged in early 2026 that he uses AI assistance for kernel development. When the creator of Linux and Git adopts a practice, it's no longer fringe.
The Criticism
Vibe coding has real risks. CodeRabbit's analysis found that AI-generated code produces 1.7x more major issues compared to human-written code. Security researchers have flagged patterns where LLMs confidently introduce vulnerabilities that pass superficial review. The "forget that the code exists" philosophy works for prototypes and personal projects but breaks down in production systems where you need to understand failure modes.
The pragmatic middle ground — which most experienced developers have settled into — is using AI as a force multiplier rather than a replacement. You vibe-code the scaffolding, then review and harden the critical paths. The ratio of AI-generated to human-reviewed code varies by stakes: a weekend project might be 95% vibes, a payment processing system might be 20%.
The LLM Wiki: From Code Generation to Knowledge Management
Karpathy's LLM Wiki concept extends the Software 3.0 philosophy beyond code generation into knowledge management and research workflows. Instead of RAG (Retrieval-Augmented Generation) — where you dump documents into a vector database and hope similarity search finds the right chunks — the LLM Wiki takes a fundamentally different approach.
The idea: maintain a persistent markdown knowledge base where the LLM acts as both librarian and author. The wiki has three core operations:
Ingest — feed raw sources (articles, papers, documentation, meeting notes) to the LLM. It reads, synthesizes, and writes structured wiki pages. Not copy-paste — genuine synthesis that connects new information to existing knowledge.
Query — start from index.md, navigate the wiki's structure, and synthesize answers with citations back to specific wiki pages. Because the LLM wrote the wiki itself, it understands the structure intimately. No embedding similarity heuristics — the LLM navigates its own curated knowledge graph.
Lint — periodically review the wiki for contradictions, outdated information, orphaned pages, and gaps in coverage. The LLM maintains its own knowledge base the way a head librarian maintains a reference collection.
Karpathy describes this as "a curated library with a head librarian who is constantly writing new books to explain the old ones." The key insight is that LLMs are better at navigating structured text they authored than at searching through raw documents via embeddings.
Why This Matters for Developers
The LLM Wiki pattern is already showing up in practice. Claude Code's CLAUDE.md files are a lightweight version — persistent project context that the LLM reads at the start of every session. Memory systems in AI assistants follow the same principle: structured, LLM-maintained knowledge that grows over time.
For developers building AI-powered applications, this suggests a different architecture than the standard RAG pipeline. Instead of: raw documents → chunking → embeddings → vector search → LLM synthesis, consider: raw documents → LLM ingestion → structured wiki → LLM navigation → answer with citations. The upfront cost is higher (ingestion requires LLM calls), but the query quality is dramatically better because the knowledge is pre-organized rather than searched ad hoc.
The Decade of Agents (2025–2035)
Karpathy frames the current moment as the beginning of a "decade of agents." The progression he envisions:
Current state (2025–2026): partial autonomy apps — Cursor, Claude Code, Perplexity — where the AI does heavy lifting but humans verify and steer. Karpathy calls this the "jagged intelligence" phase, where LLMs are superhuman at some tasks and surprisingly fragile at others. The key limitation is "anterograde amnesia" — models that can't form new long-term memories within a session, requiring external scaffolding (like the LLM Wiki) to maintain context.
Near future (2027–2030): agents that manage entire workflows end-to-end, with humans providing goals and reviewing outcomes rather than supervising each step. The Software 3.0 stack matures — natural language interfaces become the default for configuring business logic, not just generating code.
Longer term (2030–2035): the distinction between "using software" and "programming software" dissolves entirely. Every user becomes a programmer in the Software 3.0 sense — describing what they want and having the system figure out how to deliver it.
What This Means in Practice
If you're a developer today, Karpathy's framework suggests a few practical shifts:
Invest in prompt engineering as a core skill. If prompts are the new programs, then writing effective prompts is the new programming. This isn't about tricks — it's about clearly specifying intent, constraints, and success criteria in natural language.
Build for LLM-native architectures. Instead of bolting AI onto existing systems, design systems where the LLM is the primary logic engine. The oCMS blog you're reading this on, for example, could have its entire content pipeline — from drafting to SEO optimization to image generation to publishing — driven by a single natural-language workflow.
Embrace the hybrid model. Pure vibe coding and pure manual coding are both suboptimal. The sweet spot is knowing when to let the AI drive and when to take the wheel. Critical paths, security boundaries, and data integrity logic deserve human attention. Everything else is fair game for vibes.
Think in knowledge structures, not just code. The LLM Wiki concept applies far beyond personal note-taking. Product documentation, internal knowledge bases, onboarding materials, API references — anything that needs to stay current and internally consistent is a candidate for LLM-maintained knowledge management.
The Bigger Picture
Karpathy's three ideas — Software 3.0, vibe coding, and the LLM Wiki — are really one idea seen from three angles. Software 3.0 is the paradigm (natural language as programming). Vibe coding is the practice (letting the model carry the implementation burden). The LLM Wiki is the extension (applying the same approach to knowledge, not just code).
Together, they describe a future where the primary skill of a software engineer isn't writing code — it's clearly articulating intent. The code still exists, the neural networks still train, the databases still store data. But the human interface to all of it shifts from syntax to semantics, from implementation to specification.
Whether you find this exciting or unsettling probably depends on how much of your identity is tied to the craft of writing code versus the craft of solving problems. Karpathy's bet is clear: the problem-solvers win.
