Software Is Changing (Again): My Take on Andrej Karpathy’s Talk
Why coding as we know it may be fading—and what’s replacing it.
What happens when we stop writing code—and start describing what we want instead?
Today, I watched Andrej Karpathy’s keynote, “Software is Changing (Again),” at the AI Startup School hosted by a16z.
Karpathy is a leading AI researcher and educator, known for his work at OpenAI, Tesla, and Stanford.
His talk wasn’t a technical deep dive. It offered a broad, thoughtful look at how software development is shifting in the age of large language models (LLMs). For me, it helped clarify where things are heading—and what skills and habits we need to adapt.
What follows is my summary of the talk, including a few interpretations and examples I added to better understand the talk.
Who Was This Talk For?
Karpathy was speaking to startup founders, engineers, and students preparing to build AI-first tools. But his message applies to anyone involved in software development today.
The Three Eras of Software
Karpathy describes the evolution of software in three distinct paradigms. Knowing the strengths and tradeoffs of each helps us decide which one to apply—and when.
These paradigms didn’t replace each other overnight. Each emerged in response to new capabilities, and all three are still relevant. The first has shaped several decades of software history; the second has taken hold more recently as machine learning matured; and the third is unfolding now with the rise of large language models.
Software 1.0 — Human-Written Code
Developers write logic line by line in a programming language. The system does exactly what it's told.
Software 2.0 — Learned Programs
Instead of writing program logic directly, developers train models—often neural networks—on data. The model becomes the program.
Even so, this approach still requires coding: for building the model, preparing data, training, and evaluation.
Software 3.0 — Prompt-Based Development
Now, with LLMs, we describe what we want in natural language. The model generates the code or behavior.
This shifts software design away from implementation details and toward goal-oriented interaction.
Karpathy’s message is that we need fluency across all three paradigms. Each remains useful, depending on context.
From Code to Prompts: What Changes (and What Doesn’t)
While Software 3.0 offers dramatic productivity gains, Karpathy stresses the importance of discipline and control.
He recommends working with LLMs one step at a time:
Generate a small block of code with LLM
Review and verify it manually
Then proceed to the next step
This loop—generate, verify, repeat—ensures that humans remain in charge. LLMs assist, but they don’t replace judgment or accountability.
Why Real-World Integration Still Matters
Karpathy emphasized that generating code is often the easiest part. But turning that code into a working, reliable product is much harder.
For example:
You might prompt an LLM to generate a prototype iOS app in a few hours.
But integrating that app—sign-up flows, payment systems, backend connections—can take days or weeks.
Prompting gets you started. Building something production-ready still takes engineering effort and care.
Partial Autonomy: A Better Path for Agents
Karpathy also touched on AI agents—autonomous systems built on LLMs. His advice? Don’t aim for full autonomy just yet.
Instead, build partial-autonomous agents:
Keep humans in the loop
Design systems for transparency and override
Apply guardrails in higher-risk scenarios
The result is safer and more usable systems. Autonomy should be earned incrementally, not assumed by default.
What LLMs Are—and Aren’t—Good At
Strengths:
Vast encyclopedic knowledge across domains
Handling large context windows in a single session
Limitations:
Hallucinating plausible but incorrect answers
Lacking internal truth-checking mechanisms
Forgetting everything between sessions unless augmented
These limitations are not bugs. They’re foundational constraints—and they shape how LLMs should be used responsibly.
Final Takeaway
Karpathy’s message was clear:
“Software is changing again. Developers must evolve with it.”
That evolution means:
Learning all three paradigms—Software 1.0, 2.0, and 3.0
Using LLMs with precision and skepticism
Staying grounded in what it takes to build real, integrated systems
This isn’t just a tooling shift. It’s a mindset shift. And it’s already underway.