Introduction: What This Video Is About

Andrej Karpathy, former Director of AI at Tesla, presents a compelling vision for the future of software development, arguing that we are at a unique and transformative juncture. This video explores the evolution of software from traditional code (Software 1.0) to neural networks (Software 2.0) and, critically, to Large Language Models (LLMs) programmed in natural language (Software 3.0). Karpathy highlights the profound implications of this shift, emphasizing that LLMs are not merely new tools but fundamentally new types of computers, akin to operating systems, that necessitate a rethinking of how we build and interact with digital systems.

The video is especially relevant for students and professionals entering or already navigating the tech industry, offering insights into the changing landscape of programming paradigms. It delves into the “psychology” of LLMs, their unique capabilities and deficits, and proposes strategies for designing LLM-powered applications with “partial autonomy.” Karpathy’s perspective challenges conventional software development, suggesting a future where everyone becomes a programmer through natural language, and digital infrastructure is built to cater to AI agents as much as human users. This summary provides comprehensive coverage of all key insights, frameworks, and actionable advice from Karpathy’s presentation.

Chapter 1: Software Evolution: From 1.0 to 3.0

This chapter outlines Karpathy’s foundational concept of software’s evolution, introducing Software 1.0, 2.0, and the newly designated 3.0, emphasizing the paradigm shifts in how instructions are given to computers.

What Software 1.0 Really Means

Software 1.0 refers to the traditional, human-written code that directly programs computers. This includes languages like C++, Python, and Java, where developers explicitly write instructions for tasks in the digital space. Karpathy illustrates this with a “map of GitHub,” representing the vast amount of human-crafted code that has been written over decades. This paradigm has been the bedrock of computing for approximately 70 years, defining how we build most applications and systems. It requires explicit logic and algorithms to be defined by a programmer.

How Software 2.0 Actually Works

Software 2.0 represents neural networks, where the “code” is not explicitly written by humans but rather learned. In this paradigm, the weights of a neural network are the “parameters” that program the system. Instead of writing lines of code, developers tune datasets and run optimizers to create these parameters. Karpathy cites Hugging Face and Model Atlas as equivalents of GitHub for Software 2.0, where models and their weights are shared and iterated upon. An example is AlexNet, an image recognizer that learns to map images to categories. This shift allowed for systems to perform tasks that were difficult or impossible to program explicitly, such as image recognition, by learning from large amounts of data.

The Rise of Software 3.0: Programming in English

The most recent and profound shift introduces Software 3.0, where Large Language Models (LLMs) become programmable. Karpathy defines LLMs as a new kind of computer that can be programmed using natural language prompts. This is a fundamental change because prompts, written in English, now serve as programs that orchestrate the LLM’s behavior. This means that a task like sentiment classification, which could previously be done with Python code (1.0) or a trained neural net (2.0), can now be accomplished by simply prompting an LLM. The ability to program computers in our native language is “unprecedented” and represents a paradigm shift beyond just a new programming language. Karpathy’s viral tweet, “Remarkably, we’re now programming computers in English,” captured the essence of this transformation.

Tesla Autopilot: A Case Study of Software 2.0 Eating the Stack

Karpathy draws on his experience at Tesla to illustrate the “eating through the stack” phenomenon, where a newer software paradigm replaces older ones. Initially, Tesla’s Autopilot had a significant amount of Software 1.0 (C++ code) alongside neural networks for image recognition. Over time, as the neural network (Software 2.0) grew in capability and size, much of the C++ code was deleted. Functionality previously explicitly programmed in 1.0, such as stitching information across different cameras and time, was migrated to 2.0. This demonstrated how Software 2.0 literally “ate through” the 1.0 stack, leading to more robust and performant systems. Karpathy believes the same phenomenon is now occurring with Software 3.0, suggesting it will increasingly subsume functionalities from both 1.0 and 2.0. Understanding all three paradigms is crucial for developers entering the industry today, as each has its own pros and cons, and fluidity between them will be essential.

Chapter 2: LLMs as Utilities, Fabs, and Operating Systems

This chapter delves into Karpathy’s analogies for understanding LLMs within the broader technological ecosystem, positioning them as fundamental infrastructure elements rather than mere applications.

LLMs as Utilities: The New Electricity Grid

Karpathy proposes that LLMs possess properties akin to public utilities, drawing an analogy to Andrew Ng’s “AI is the new electricity.” LLM labs like OpenAI and Anthropic invest significant capex to train LLMs, comparable to building a power grid. They then incur opex to serve intelligence via APIs, which consumers access through metered usage (e.g., pay per million tokens). Demand for LLM APIs includes low latency, high uptime, and consistent quality, mirroring demands for electricity. Just as a transfer switch allows switching electricity sources, tools like OpenRouter allow users to switch between different LLMs. The software nature of LLMs means they don’t compete for physical space, enabling multiple “electricity providers.” Karpathy notes the dramatic impact of LLM outages, which he likens to an “intelligence brownout,” highlighting our growing reliance on these models.

LLMs as Fabs: Deep Tech Trees and Capital Investment

Beyond utilities, Karpathy suggests LLMs also exhibit characteristics of semiconductor fabrication plants (fabs). The capital expenditure required to build LLMs is substantial, involving immense investment in specialized infrastructure. LLM labs are developing deep tech trees, accumulating significant research, development, and proprietary secrets, similar to the advanced processes within fabs. This suggests a centralization of core technological advancements within these labs. However, Karpathy notes the analogy “muddies a little bit” because software is inherently more malleable and less defensible than physical fabs. He draws further parallels: a “4-nanometer process node” in chips might equate to a “cluster with certain max flops” in LLMs, and using Nvidia GPUs for LLM software without building hardware is like a “fabless model,” whereas Google’s use of TPUs (owning their fab) is analogous to the “Intel model.”

LLMs as Operating Systems: Orchestrating Memory and Compute

Karpathy argues that the strongest analogy for LLMs is operating systems (OS). Unlike commodity utilities, LLMs are complex software ecosystems. The current LLM ecosystem mirrors the early OS landscape: a few closed-source providers (Windows, macOS) alongside an open-source alternative (Linux, comparable to the Llama ecosystem). These systems are becoming increasingly complex, encompassing not just the LLM itself but also tool use and multimodality. Karpathy envisions the LLM as the “CPU equivalent,” the context window as memory, and the LLM itself orchestrating memory and compute for problem-solving.

He further extends the OS analogy:

• Application Compatibility: An LLM app (like Cursor) can run on different LLMs (GPT, Claude, Gemini) just as a VS Code app runs on Windows, Linux, or Mac.
• Early Computing Era: We are in a “1960s-ish era” where LLM compute is expensive and centralized in the cloud, forcing a thin-client, time-sharing model. Personal computing for LLMs hasn’t fully emerged, though efforts like running LLMs on Mac minis are early indicators.
• Terminal Interface: Interacting with LLMs directly via text feels like using an operating system through a terminal. A general Graphical User Interface (GUI) for LLMs is yet to be fully invented, though specific LLM apps feature GUIs.

LLMs Flip Technology Diffusion: From Government to Consumer

A unique property of LLMs that differentiates them from historical technologies is their inverted diffusion pattern. Typically, transformative technologies (electricity, cryptography, computing) are first adopted by governments and corporations due to their expense and complexity, only later diffusing to consumers. However, with LLMs, the initial and widespread adoption has been by consumers (e.g., using ChatGPT to “boil an egg”), with corporations and governments lagging. Karpathy finds it “insane” that ChatGPT was “beamed down to our computers like billions of people instantly and overnight,” putting powerful computing in the hands of everyone. This unprecedented accessibility means “it is our time to enter the industry and program these computers.”

Chapter 3: Psychology of LLMs: People Spirits and Cognitive Quirks

This chapter explores the unique “psychology” of LLMs, framing them as “stochastic simulations of people” with superhuman capabilities alongside distinct cognitive deficits.

LLMs as Stochastic Simulations of People

Karpathy defines LLMs as “stochastic simulations of people,” where the simulator is an autoregressive transformer trained on vast amounts of internet text. This training imbues LLMs with an emergent human-like psychology. They generate text token by token, with nearly equal compute for each chunk, resembling how humans might process information sequentially. Because they learn from human-generated data, their output often reflects human patterns of thought and expression, albeit imperfectly.

Superhuman Abilities: Encyclopedic Knowledge and Memory

LLMs possess encyclopedic knowledge and memory, far exceeding any single human. They can remember vast amounts of information, including specifics like SHA hashes or obscure facts, because they have processed an immense corpus of text. Karpathy likens this to the autistic savant in the movie Rain Man, who has near-perfect memory and can recall entire phone books. This represents a significant superpower that developers can leverage, allowing LLMs to access and synthesize information on a scale previously unimaginable.

Cognitive Deficits: Hallucinations, Jagged Intelligence, and Amnesia

Despite their superpowers, LLMs exhibit several cognitive deficits:

• Hallucinations: LLMs frequently make up information, lacking a robust internal model of self-knowledge or truth. While improving, this remains a significant challenge.
• Jagged Intelligence: Their intelligence is “jagged,” meaning they can be superhuman in some domains (e.g., complex coding problems) but make trivial, “no human will make” mistakes in others (e.g., insisting 9.11 > 9.9, or “strawberry” having two ‘R’s). These “rough edges” can easily trip up users.
• Anterograde Amnesia: LLMs do not natively “learn over time” like humans. Unlike a coworker who gains context and expertise over months, LLMs do not consolidate knowledge or develop expertise from ongoing interactions. Their context windows are working memory that gets “wiped” after each interaction, analogous to protagonists in Memento or 50 First Dates. This means users must “program the working memory quite directly,” constantly re-providing context for sustained reasoning.

Security Limitations: Gullibility and Prompt Injection Risks

LLMs also present security-related limitations. They are quite gullible and susceptible to prompt injection risks, where malicious inputs can manipulate their behavior. Furthermore, they might leak sensitive data if not handled carefully. These vulnerabilities necessitate robust security measures and careful interaction design when building LLM-powered applications. Karpathy emphasizes that developers must navigate this complex landscape, leveraging LLMs’ superhuman powers while strategically working around their inherent deficits.

Chapter 4: Designing LLM Apps with Partial Autonomy

This chapter outlines how to build effective LLM applications by focusing on partial autonomy, human-AI collaboration loops, and learning from past challenges in autonomous systems.

The Need for Dedicated LLM Apps: Beyond Direct Chatbots

Karpathy argues that interacting directly with an LLM via a chatbot (like ChatGPT) is akin to talking to an operating system through a terminal. While possible, it’s inefficient for complex tasks. Instead, he advocates for dedicated LLM apps that provide a superior user experience and manage the LLM’s capabilities more effectively. Cursor, a coding assistant, serves as a prime example of an early, successful LLM app. These apps package LLM functionalities into a more intuitive interface, making them more productive than raw LLM interaction.

Key Properties of Successful LLM Applications

Successful LLM apps, like Cursor and Perplexity, share several key properties:

• Context Management: LLM apps do a ton of the context management in the background, automatically providing relevant information to the LLM (e.g., embedding models for files in Cursor).
• Orchestration of Multiple LLM Calls: They orchestrate multiple calls to LLMs and other models (e.g., chat models, diff models in Cursor; search and summarization models in Perplexity). This automates complex multi-step reasoning.
• Application-Specific GUI: They feature application-specific Graphical User Interfaces (GUIs). Text-based interaction with an OS is difficult; GUIs make it easy for humans to audit the LLM’s work visually (e.g., red/green diffs in Cursor, cited sources in Perplexity). This speeds up human verification and interaction. GUIs utilize the human’s “computer vision GPU,” which is a much faster highway to the brain than reading text.
• Autonomy Slider: LLM apps incorporate an autonomy slider, allowing users to tune the level of AI autonomy based on task complexity. Examples include:
  • Cursor: Tap completion (low autonomy), changing a code chunk (medium), changing an entire file (high), or “let it rip” on the entire repo (full agentic).
  • Perplexity: Quick search (low), research (medium), or deep research (high). This slider empowers humans to stay in control while leveraging AI for increasingly larger tasks.

The Importance of Fast Human-AI Generation-Verification Loops

A critical, often overlooked aspect of LLM app design is optimizing the human-AI cooperation loop. The AI generates, and the human verifies. The goal is to make this generation-verification loop go as fast as possible.

• Speeding up Verification: GUIs are paramount for speeding up verification. Visual representations allow humans to quickly audit the AI’s output, preventing the “bottleneck” of reading and interpreting large text diffs. Actions like “command Y to accept” or “command N to reject” are far more efficient than typing commands.
• Keeping AI on a Leash: Karpathy stresses the need to “keep the AI on the leash.” Over-reactive agents generating massive outputs (e.g., 10,000-line code diffs) are counterproductive, as humans still bear the burden of auditing for bugs, security issues, and correctness. Incremental, small chunks of AI-generated work, with rapid verification, are more effective.
• Concrete Prompts: Vague prompts lead to failed verifications and wasted cycles. Spending more time to write concrete, specific prompts increases the probability of successful verification, leading to faster progress.
• Structured AI Outputs: In educational contexts, for example, an AI teacher app might create an “intermediate artifact” like a course syllabus. This syllabus becomes auditable, ensuring consistency and keeping the AI “on leash” with respect to a defined curriculum, preventing it from getting “lost in the woods” when asked to teach broadly.

Lessons from Tesla Autopilot: The Decade of Agents

Karpathy draws parallels between building LLM apps and his experience with Tesla Autopilot, a partial autonomy product. Autopilot also featured a GUI (instrument panel showing what the neural net sees) and an autonomy slider (increasing autonomous tasks over time). He recounts his 2013 experience driving a Waymo vehicle with zero interventions, leading him to believe self-driving was “imminent.” Yet, 12 years later, full autonomy remains elusive, often requiring teleoperation or human intervention. This leads to a crucial warning: the “year of agents” is an oversimplification. Karpathy asserts that this is the “decade of agents,” requiring careful, human-in-the-loop development due to the inherent trickiness of software and autonomous systems.

Augmentation vs. Agents: The Iron Man Analogy

Karpathy uses the Iron Man suit as a metaphor for the ideal balance between augmentation and agency. The suit can be an augmentation (Tony Stark drives it) or an agent (it flies autonomously). With fallible LLMs, Karpathy advises focusing on building “Iron Man suits” (augmentations) rather than “Iron Man robots” (fully autonomous agents). This means creating partial autonomy products with custom GUIs and UI/UX that optimize the generation-verification loop for speed. While recognizing that full automation is “in principle possible” and products should have an autonomy slider, the current focus should be on building tools that greatly enhance human productivity through careful collaboration with AI, gradually increasing autonomy over time. This approach presents vast opportunities for product innovation.

Chapter 5: Vibe Coding: Everyone is Now a Programmer

This chapter introduces the concept of “vibe coding,” highlighting how natural language programming with LLMs is making software development accessible to a far broader audience than ever before.

English as a Programming Language: Unprecedented Accessibility

Karpathy emphasizes that the ability to program in English, a natural language, is “completely unprecedented” and profoundly “bullish” for the future of software. Traditionally, becoming proficient in software development required five to ten years of dedicated study. Now, with LLMs, this barrier is significantly lowered, allowing anyone who speaks natural language to engage in programming. This transformation means that “suddenly everyone is a programmer.”

The “Vibe Coding” Meme: A New Era of Development

Karpathy discusses the “vibe coding” meme, a term he coined that resonated widely, giving a name to a new, intuitive way of building software. Vibe coding means building highly custom software by “winging it” with LLMs, even without traditional programming expertise. He highlights a video of children “vibe coding,” demonstrating the accessibility and joy of this new paradigm. This phenomenon is seen as a “gateway drug to software development,” fostering creativity and experimentation without the steep learning curve of traditional languages.

Personal Vibe Coding Projects: iOS App and MenuGenen

Karpathy shares two personal projects to illustrate the power of vibe coding:

• Basic iOS App: Despite not knowing Swift, he was able to build a super basic iOS app in a single day, which was running on his phone by the end of it. This showcased how LLMs eliminate the need to “read through Swift for like five days just to get started,” drastically shortening the time to first working prototype.
• MenuGenen.app: He built MenuGenen, a live web app that takes a picture of a restaurant menu and generates images for each item. He created the core demo on his laptop in a few hours by vibe coding.

The Real Challenge: Making it “Real” (DevOps, Authentication, Payments)

While the code for MenuGenen was the “easy part” of vibe coding, Karpathy reveals that making it “real” was significantly harder and time-consuming. This involved tasks like authentication, payments, domain names, and deployment (Vercel deployment). These are often DevOps tasks performed by clicking around in a browser, not writing code. He describes the experience of integrating Google login, which involved a huge list of manual, step-by-step instructions (e.g., “go to this URL, click on this dropdown, choose this, go to this, click on that”). This manual “clicking stuff” took another week of effort, highlighting a major bottleneck. Karpathy questions, “Why am I doing this? What the hell?” He concludes that this “extremely slow” manual work, often consisting of a computer telling a human what actions to take, is where the next frontier of automation lies.

Chapter 6: Building for Agents: Future-Ready Digital Infrastructure

This chapter focuses on the necessity of evolving digital infrastructure to better serve AI agents, not just human users, and how this will unlock new levels of automation and utility.

Agents as a New Category of Digital Consumer

Karpathy proposes a new category of consumer and manipulator of digital information: agents. Previously, it was only humans (through GUIs) or computers (through APIs). Agents, however, are “human-like” computers or “people spirits on the internet” that need to interact with software infrastructure. This necessitates building digital systems that agents can understand and interact with effectively, rather than solely designing for human interaction.

Making Information Agent-Legible: Beyond Human-Centric Docs

A crucial step is to make digital information agent-legible.

• LLM.txt: Similar to robots.txt for web crawlers, Karpathy suggests an llm.txt file (simple markdown) that clearly tells LLMs what a domain is about. This is far more reliable than expecting LLMs to parse complex HTML, which is “error-prone and difficult.”
• Agent-Specific Documentation: A huge amount of existing documentation is written for people (with lists, bold text, pictures) and is not directly accessible by LLMs. Services like Vercel and Stripe are early movers in transitioning their documentation to markdown, which is “super easy for LLMs to understand.”
• Actionable Documentation: Beyond format, documentation needs to change content. Instructions like “click this” are useless to an LLM. Vercel, for example, is replacing “click” with equivalent cURL commands that an LLM agent could execute. This makes documentation directly actionable for agents.
• Model Context Protocol: Anthropic’s Model Context Protocol is another example of a protocol designed for direct communication with agents.

Tools for LLM-Friendly Data Ingestion

Karpathy highlights the emergence of small, focused tools that help ingest data in LLM-friendly formats:

• Get Ingest: Tools like get-ingest can transform a GitHub repository (a human interface) into a single, giant text file with a directory structure, ready to be copy-pasted into an LLM. This allows LLMs to “ask questions about” codebases.
• Deep Wiki: Devon’s Deep Wiki goes further by having an agent analyze a GitHub repo and build an entire documentation page for it. This pre-digested, structured information is even more helpful for LLMs.
  Karpathy is “very bullish” on these tools that, by simply changing a URL, make content accessible to LLMs.

The Future of Agents: Meeting LLMs Halfway

While LLMs may eventually be able to “go around and click stuff” autonomously, Karpathy believes it’s currently “very worth meeting LLMs halfway.” Directly providing agent-friendly formats is easier and less expensive than relying on LLMs to parse complex human-oriented interfaces. This “middle point” is crucial for unlocking widespread LLM utility, especially for the “long tail” of older software and digital infrastructure that won’t be immediately adapted for agents. Karpathy is “bullish on both” approaches, recognizing the long-term potential for full agentic interaction while advocating for immediate steps to make systems more legible to current LLMs.

Key Takeaways: What You Need to Remember

Core Insights from Software in the Era of AI

• Software is undergoing a fundamental transformation: We’ve moved from Software 1.0 (human-written code) to Software 2.0 (neural network weights) and are now in the era of Software 3.0 (LLMs programmed with natural language prompts).
• LLMs are not just tools, but new operating systems: They act as orchestrators of memory and compute, centralizing intelligence like utilities, and demanding an entirely new approach to software development.
• We are in the “1960s of LLMs”: Current LLM compute is expensive and centralized, leading to a thin-client, time-sharing model, with a personal computing revolution for LLMs still on the horizon.
• LLMs possess a unique “psychology”: They have superhuman memory and encyclopedic knowledge but suffer from cognitive deficits like hallucinations, jagged intelligence, and anterograde amnesia.
• Partial autonomy is key for LLM apps: Focus on building applications that augment human capabilities with an “autonomy slider,” allowing users to control the level of AI involvement.
• Fast human-AI loops are essential: Optimize the generation-verification loop through intuitive GUIs and by keeping AI agents “on a leash” with concrete, small-chunk interactions.
• Everyone is now a programmer (“vibe coding”): Natural language programming opens up software development to a vastly wider audience, making custom solutions more accessible than ever before.
• Digital infrastructure must adapt for agents: Future-proof systems by making documentation and interfaces legible and actionable for AI agents, not just humans.

Immediate Actions to Take Today

• Become fluent in all three software paradigms: Understand when to program in Software 1.0 (code), 2.0 (neural nets), or 3.0 (LLM prompts) for optimal results.
• Identify opportunities for partial autonomy in your products: Consider how LLMs can make your existing services partially autonomous, allowing humans to supervise and audit.
• Prioritize GUI development for LLM apps: Design visual interfaces that enable rapid human auditing and verification of AI-generated content.
• Practice “vibe coding” for custom projects: Experiment with building simple applications using LLMs to bypass traditional programming barriers and rapidly prototype ideas.
• Start making your documentation agent-legible: Convert human-centric docs to markdown and replace “click” instructions with actionable API calls or cURL commands.
• Utilize LLM-friendly data ingestion tools: Leverage tools that transform raw data or codebases into formats easily consumable by LLMs for analysis and interaction.

Questions for Personal Application

• How can I integrate an “autonomy slider” into my current projects or services to gradually introduce AI capabilities?
• What are the most common “hallucinations” or “jagged intelligence” quirks I’ve observed in LLMs, and how can I design my interactions to mitigate them?
• In what ways can I reformat my team’s internal documentation to be more easily understood and acted upon by AI agents?
• Which manual, repetitive “clicking” tasks in my workflow could be automated by building a simple agent-facing interface or custom LLM app?
• How can I leverage “vibe coding” to prototype a niche tool or solution that doesn’t currently exist, even without deep programming expertise?