Blog
From vibe coding to agentic engineering
Cicero Campelo, CISSP
June 19, 2026 · 7 min read
Part of our guide to AI for startups.

Table of contents
- Vibe coding raised the floor, agentic engineering raises the ceiling
- Software 3.0: the program is the prompt
- Jagged intelligence: why you stay in the loop
- Build where the work is verifiable
- The human skill that gets more valuable is taste
- Build agent-native
- What to do this week
- Sources
- Frequently asked questions
Andrej Karpathy coined the term vibe coding. A year later, on stage at Sequoia's AI Ascent 2026, he said something stranger: he has never felt more behind as a programmer. The person who named the trend was watching it move past him. The reason is a shift he thinks most people missed, and his name for what comes next is the more useful idea for founders. It is called agentic engineering.
Karpathy points to December as the moment it changed for him. The agentic tools stopped needing corrections. The chunks of code "just came out fine," he kept asking for more, and he could not remember the last time he fixed one by hand. If you experienced AI last year as a ChatGPT-style chat box, he says, you had to look again, because the coherent agentic workflow started to actually work. Here is the talk distilled into something a founder can act on.
Vibe coding raised the floor, agentic engineering raises the ceiling
Karpathy splits the two cleanly. Vibe coding is about raising the floor: anyone can now build software, and that is genuinely great. Agentic engineering is about preserving the quality bar of professional software while going faster. His line is worth quoting almost directly: you are not allowed to introduce vulnerabilities just because you vibe coded, and you are still responsible for your software, same as before. The only question is whether you can go faster, and the answer is yes, if you do it properly.
That is why he calls it engineering. Agents are powerful but spiky, a little fallible, a little stochastic. Agentic engineering is the discipline of coordinating them to move faster without sacrificing the quality bar. He thinks the ceiling here is very high. People used to talk about the 10x engineer; he says the speedup for people who are genuinely good at this is a lot more than 10x.
This is the same shift YC's Garry Tan describes when he talks about building software with AI agents like a team: roles, review, and a gate before anything merges. Karpathy is naming the discipline; Tan is showing the assembly line.
Software 3.0: the program is the prompt
Karpathy's frame for why this is happening is that LLMs are a new kind of computer. Software 1.0 is code you write. Software 2.0 is weights you train on data. Software 3.0 is prompting a model in plain language, where the context window is your program and the model is the interpreter.
The shift sounds abstract until you see what it deletes. He built an app called MenuGen that photographs a restaurant menu and generates pictures of each dish. Then he saw the software 3.0 version: hand the photo to a model and ask it to render the images onto the menu directly. The whole app he wrote was spurious. It should not exist. For founders, the lesson is not "AI makes my code faster." It is that some of the code, and some of the products, no longer need to be built. The question becomes what is the text to give your agent.
Jagged intelligence: why you stay in the loop
The reason you cannot just hand everything off is what Karpathy calls jagged intelligence. The models are spiky. The same system that can refactor a large codebase or find a real security vulnerability will also, asked whether to drive or walk to a car wash 50 meters away, confidently tell you to walk. It is superhuman in some places and strangely dumb in others.
His explanation is that models peak in verifiable domains, math and code and their neighbors, because that is where the labs can throw reinforcement learning at them, and they get rough outside that. He also reminds you these are not human minds. In his framing, we are not building animals shaped by evolution; we are summoning "ghosts," statistical entities shaped by data and reward. Yelling at them does not help. The practical takeaway is plain: treat agents as powerful tools, not colleagues, and keep a human in the loop on the parts where they are weak.
Build where the work is verifiable
For founders deciding what to build, Karpathy's most concrete advice is about verifiability. Classic computers automate what you can specify in code. This generation of models automates what you can verify, because verifiable tasks are what labs can train against. So if you are working in a domain where outputs can be checked, that domain is tractable now, and it stays tractable even if the labs are not focused on it, because you can build your own evaluation environments and fine-tune.
There is a security dividend here that fits how we think. The same verification gates that make agent output correct are what make it safe. Karpathy's own hiring example is telling: instead of puzzles, give a candidate a big project, have them build something real and secure, then point a swarm of agents at it to try to break it. If they cannot, that is the signal. Build the checks first, and they double as your guardrails.
The human skill that gets more valuable is taste
As agents do more, what becomes more valuable, not less? Karpathy's answer is taste, judgment, and oversight. The agents are like interns with perfect recall. He no longer remembers the fiddly API details, whether it is dim or axis, reshape or permute, because the agent handles that. But he still owns the design, the spec, and the decisions that matter.
His favorite example of why is a bug from MenuGen. Users sign in with Google but pay through Stripe, and his agent tried to match accounts by email address instead of a stable user ID, so anyone using different emails would lose their credits. The agent wrote fluent code around a decision no careful engineer would make. That is the job that does not transfer: deciding there must be one unique user ID and everything ties to it. He prefers working from a detailed spec, then letting agents fill in the blanks while he holds the top-level structure and the oversight.
He closes on the durable point. A tweet he keeps returning to: you can outsource your thinking, but you cannot outsource your understanding. You are still the one who has to know what is worth building and why, and direct the agents accordingly. This is the same reason it pays to build for the next AI model, not this one: the lasting advantage is your judgment and your architecture, not any single model.
Build agent-native
One running frustration in the talk: almost everything is still written for humans. Docs tell you to go to a URL and click around. Karpathy's pet peeve is that he does not want to do anything; he wants the text to copy and paste to his agent. The deploy story for MenuGen was the same. Writing the code was easy; wiring up Vercel, DNS, and a dozen service settings by hand was the painful part. The test he proposes for whether infrastructure is becoming agent-native: can you prompt an agent to build and deploy the whole thing without touching a single dashboard?
For a founder, that is both a warning and an opening. Write your own product to be legible to agents, sensors and actuators an agent can drive, and you are early to where everything is going. It is also a real product wedge: the agent-native version of tools people still operate by hand.
What to do this week
- Pick one real task and run it through agentic engineering, not vibe coding: write a short spec, let the agent build it, then review the output against the spec before it lands.
- Add a verification gate. Decide how each agent change gets checked, by a test, a review pass, or a human, before it merges. This is your quality bar and your security gate at once.
- Choose your next bet where outputs are verifiable. If you can check it, you can build it now and improve it with your own evals.
- Write your red lines: what an agent may never do without a human, and which systems it may never touch. Karpathy's rule holds, you are still responsible for the software.
- Make one thing agent-native. Replace a manual setup with a single prompt an agent can run end to end.
Vibe coding got everyone in the door. Agentic engineering is how founders turn that into a company that ships fast and stays safe. That is the operating system we help founders install in AI Operating System for Startups: put agents to work across the company, with a human owning the spec and every irreversible call. To go deeper on the engineering side, see how to build software with AI agents like a team and the YC companies building AI coding agents.
Sources
- Andrej Karpathy: From Vibe Coding to Agentic Engineering, with Stephanie Zhan, Sequoia's AI Ascent 2026, the conversation this article distills.
- Background on Andrej Karpathy: Wikipedia. He co-founded OpenAI, led AI and Autopilot at Tesla, and coined the term vibe coding.
Frequently asked questions
What is agentic engineering?
Agentic engineering is the discipline of coordinating AI coding agents to build software faster without dropping the quality bar of professional software. Andrej Karpathy, who coined vibe coding, draws the line this way: vibe coding raises the floor so anyone can build, while agentic engineering keeps you responsible for correctness, security, and design as you go faster. The agents do more of the typing; you own the spec, the review, and the judgment, and you are not allowed to ship vulnerabilities just because an agent wrote the code.
What is the difference between vibe coding and agentic engineering?
Vibe coding is letting the model write code while you follow the vibes, which is great for prototypes and raises the floor for everyone. Agentic engineering is the professional version: you still move fast with agents, but you preserve the quality bar with specs, review gates, tests, and human sign-off on anything risky. Karpathy frames vibe coding as raising the floor and agentic engineering as raising the ceiling, where the best practitioners go far beyond the old 10x engineer.
What is software 3.0?
Software 3.0 is Andrej Karpathy's name for programming in plain language. Software 1.0 is code you write by hand, software 2.0 is neural network weights you train on data, and software 3.0 is prompting a large language model, where your context window is the program and the model is the interpreter. In that paradigm the question shifts from what code to write to what text to give your agent, and some apps stop needing to exist at all because the model does the work directly.
What is jagged intelligence in AI?
Jagged intelligence is Karpathy's term for how today's models are spiky: superhuman in some areas and oddly weak in others. The same model that can refactor a large codebase or find a security flaw might tell you to walk to a car wash 50 meters away when you asked about driving. Models peak in verifiable domains like math and code, which is where the labs train them hardest, and get rough outside that. The practical lesson for founders is to treat agents as powerful but fallible tools and stay in the loop.
Build your AI Operating System
A practical course to grow with AI, build internal tools, and operate safely. v1.0 launches July 31, join the waitlist.