Karpathy placed one sentence on his blog that may be the most direct line in the whole talk:
I have never felt more behind as a programmer.
This comes from someone who wrote micrograd and nanoGPT and has just opened Eureka Labs. On April 20 he spoke with Konstantine Buhler at Sequoia AI Ascent for more than half an hour; on April 30 he posted the edited transcript to Bear Blog. After reading it, I kept returning to why he would say that. He is not selling anxiety. He is marking a professional divide.
A Date Line
Karpathy names December 2025 as a line.
Before it, agents writing code were “usable, but you had to watch them.” After it, he thinks macro actions crossed a reliability threshold: you say “implement this feature,” “refactor this subsystem,” “study this library,” “run the tests and fix what breaks,” and you get back work that is approximately correct.
It is not only faster. The grain changed.
You used to ship “lines.” Now you ship “tasks.” Once the minimum unit of a commit rises from a function to a feature, the shape of programming has to be redrawn.
Floor and Ceiling
His names for the divide are clean:
- Vibe coding raises the floor - almost anyone can generate software through natural language.
- Agentic engineering raises the ceiling - coordinate a group of fallible agents while preserving correctness, safety, taste, and maintainability.
Vibe coding was a late-2024, early-2025 phrase. It meant, loosely, “go by feel, talk to the model, do not inspect the lower layers.” Karpathy does not dismiss it. He explicitly says it is good. But he stresses that it only lowers the entry barrier. The real engineering act is a new and harder discipline: write specs, supervise plans, review diffs, write tests, run eval loops, manage permissions, isolate worktrees, maintain taste.
He draws an exaggerated boundary for the new role: the old idea of a 10x engineer may be pushed to a more extreme place.
The reverse side is sharper: people who do not learn agentic engineering are not simply replaced; the value they create moves into the denominator.
Three Strange Samples
He does not like the narrative that AI merely makes existing software faster. What interests him is that LLMs make possible forms that were previously impossible. Three examples:
- MenuGen - his small app that turns menu photos into dish images. Old version: OCR, image generation, stitch it back together on Vercel. New version: send the photo to Gemini with a line like “use Nano Banana to overlay an image of every dish in the right place,” and get back the menu with images. His own joke is: “All of MenuGen is spurious. That app shouldn’t exist.” The entire app should not exist, because the model directly replaces it.
install.md, notinstall.sh- installation docs become prose you can paste straight into an agent. “You do not have to spell out every detail. The agent has intelligence.” The carrier of automation moves from shell script to natural language.- LLM Wiki - not RAG as just-in-time retrieval, but agents incrementally turning messy source material into a living Markdown knowledge base: summaries, entity pages, contradictions, cross-links. No traditional program can robustly do this. LLMs can.
The common point is not spectacle. It is that the shape itself changed.
It Is Not an Animal
Karpathy repeats one point: an LLM is not an animal; it is a ghost - a statistical simulation of human artifacts, shaped by pretraining, post-training, RL, product feedback, and economic incentives. Animal or human analogies push your reasoning in the wrong direction.
He splits model capability along two axes: verifiability and training attention. Their projection produces jagged intelligence:
A SOTA model that can refactor a hundred thousand lines of code and find a zero-day may tell you to walk to a car wash 50 meters away.
And leave you pushing an unwashed car under the sun.
For startup builders, he leaves a question: are you on the model’s trajectory? Does your business live in a region with high verifiability and abundant training attention? If not, you need to build your own ladder. You cannot wait for the model to “naturally get better.”
Writing Software for Agents
Most software is built for humans clicking screens. Karpathy proposes a less discussed view: users are increasingly human agents, not humans themselves.
That means the new infrastructure must be designed for agents:
- Markdown documentation instead of rich text
- CLI instead of GUI wizards
- MCP servers, structured logs, machine-readable schemas
- setup instructions an agent can copy and execute
- headless installation and deployment flows
His original line is blunt:
Why are people still telling me what to do? I don’t want to do anything. What is the thing I should copy-paste to my agent?
He uses an engineering metaphor: sensors and actuators. The model is the brain; your product has to give it senses - what can be read - and muscles - what can be done.
Hiring changes too. His new interview question is: “Write a Twitter clone for agents. It has to be safe. Then let agents simulate activity on it. I will use ten Codex agents to attack it, and it must not break.” Whiteboard questions are relics of the previous paradigm.
Closing
After reading the transcript, I noticed one sentence he leaves near the end, in the self-assessment section:
You can outsource your thinking, but you can’t outsource your understanding.
You can hand off decision-making. You cannot hand off understanding. Understanding must pass through your own mind, and that bandwidth does not expand just because you have more agents.
He says: “I am becoming the bottleneck in my own system - even the question of what we are building has to enter my head first.”
When the person who wrote nanoGPT says he is the bottleneck, that is not modesty. That is the fault line made clear: the floor has dropped, the ceiling has risen, and the distance between them still has to be crossed by a human being.
He says he has “never felt more behind” not because the models are faster, but because more of the necessary work now has to be written inside his head.
Vibe made us all lighter. Engineering did not.