Vibe Coding Grew Up. Karpathy Explains What's Next

Last year, Andrej Karpathy posted the phrase "vibe coding" on X and half the internet immediately knew what he meant. Not because it was a perfect technical description—it wasn't—but because it named something people were already doing and slightly embarrassed about. They were prompting their way through software without fully understanding what came out the other end. Calling it "vibe coding" made it feel less like cheating and more like a new way of working.

A year later, Karpathy sat down with Sequoia partner Stephanie Zhan at a recent Sequoia Capital AI conference to revisit that phrase—and to explain why the more interesting story is what's forming around it.

He opened by admitting something that stopped a few people short: that he has never felt more behind as a programmer. This is the co-founder of OpenAI, the person who got Tesla's Autopilot working. Worth sitting with for a second. His explanation was that December marked a clear threshold where the tools stopped needing correction. He kept asking for more, it kept coming out right, and at some point he realized he'd handed over the wheel. "I just trusted the system more and more, and then I was vibe coding." The laughter in the room suggested he wasn't alone.

But this piece isn't really about vibe coding. It's about what Karpathy says comes next—and why the difference matters if you're a small business owner trying to figure out which of these AI promises are actually real.

The Paradigm Shift Nobody's Finished Processing

Karpathy has been developing a framework he calls Software 1.0, 2.0, and 3.0. Version 1.0 is what most people think of as programming: you write explicit instructions and the machine follows them. Version 2.0 was the neural network era—instead of writing rules, you fed the system data and let it learn the rules itself. Version 3.0 is what we're in now: the model has already learned so much, from so much of the internet, that your job is no longer to write code or curate training data. Your job is to write prompts. The context window—what you put in front of the model—is your lever.

He illustrated this with a project he built called MenuGen. The problem was simple: restaurant menus rarely have pictures, and he wanted to know what things looked like before ordering. So he built an app. It took photos, ran optical character recognition, pulled in an image generator, rendered everything in a new layout. Classic software thinking—identify the steps, build the pipeline.

Then he saw someone solve the same problem with a single prompt to Gemini, using an image tool (the tool name as spoken in the transcript is unclear and could not be independently verified) that simply overlaid pictures directly onto the original menu photo. No app. No pipeline. One instruction, one output. "All of my MenuGen is spurious," he said. "It's working in the old paradigm. That app shouldn't exist."

I've been watching small business owners discover this same gap all year. A retailer I know spent three months building a custom inventory-description generator with a development firm. Eight thousand dollars and a lot of meetings. A few weeks after launch, she found she could get comparable output by describing her inventory to a general-purpose AI tool in plain language. The pipeline she paid for was already obsolete before the final invoice arrived.

The Jaggedness Problem—and Why It Matters to People Who Aren't Coders

Here's where Karpathy gets into something that doesn't get enough honest attention: these AI models are wildly uneven in ways that are hard to predict.

He's been writing about what he calls "verifiability"—the observation that AI tools automate fastest in domains where you can easily check whether the output is correct. Math has right answers. Code either runs or it doesn't. So the AI labs pour their training resources into those areas, and the models get very, very good there. Areas where correctness is fuzzy, harder to measure, or just less economically important to the labs? The models are rougher.

His illustration of this was pointed. A top-tier AI model can, he says, refactor a hundred-thousand-line codebase or identify zero-day security vulnerabilities—and then turn around and tell you to walk to a car wash fifty meters away because it's so close. Never mind that you're at a car wash specifically because you need to drive your car through it.

The gap there isn't a small bug. It's a structural feature of how these systems get built. The labs train on problems they can score. Problems they can't score cleanly—common sense, spatial reasoning, "wait, why would you walk your car"—don't get the same workout.

The practical implication Karpathy draws: you cannot fully stand down. You can go much faster, you can delegate much more, but you have to stay in contact with what the model is producing. You're the person who catches the car wash answer before it becomes a real decision. The models that handle coding superbly may stumble in ways that are genuinely surprising once you move into territory that wasn't baked into their training—and there's no reference manual that tells you where those edges are. You find them by running into them.

For a small business owner thinking about deploying any of these tools: that's not a reason to stay out. It's a reason to stay awake.

Vibe Coding Raised the Floor. The Harder Question Is the Ceiling.

This is where Karpathy draws the distinction I think matters most for practical decision-making.

Vibe coding, in his framing, is about access. Anyone can now ship software who couldn't before. That's genuinely democratizing and the lowered barrier is real. But professional software has a quality standard, and vibe coding doesn't automatically maintain it. Security vulnerabilities don't care that you moved fast. A sloppy codebase doesn't become sound because an AI wrote it quickly.

Agentic engineering is what he calls the discipline that's forming to address this. "Vibe coding is about raising the floor for everyone in terms of what they can do in software," he said. "Agentic engineering is about preserving the quality bar of what existed before in professional software." These agents—the AI systems that take multi-step actions across tools and environments—are powerful but unreliable in specific, hard-to-anticipate ways. Coordinating them without sacrificing standards is the actual skill set developing right now.

The speed-up available to someone who gets good at this, Karpathy suggests, is significantly more than the "10x engineer" comparisons that circulated for years. He wouldn't pin a number on it. What he did say is that people who are genuinely skilled at agentic engineering are separating from the pack noticeably. The operators who figure out how to direct AI agents well—setting the right constraints, reviewing the right outputs, knowing which problems the tools handle confidently and which ones need a human in the loop—are going to move at a different pace than those who either avoid the tools or trust them without verification.

I think about the bookstore I ran for thirty years. We adopted every inventory system, every POS upgrade, every e-commerce platform as they came through. Each one looked like a magic fix until you understood its specific failure modes. The shop owners who thrived weren't the ones who resisted the tools or the ones who handed everything over on faith. They were the ones who learned what the tool was actually good for and built their judgment around that. A shop owner who believed every promise made at a trade show is out of business. The one who asked "okay, but what does this not handle?" usually made it.

The AI situation is the same, just faster and with higher stakes.

What Nobody Can Tell You Yet

Karpathy's honest about one thing that should give everyone some pause: nobody can give you a straight answer on the timing of what comes next, and that's exactly the part that matters most if you're running a business and trying to plan.

He gestures toward something he calls "neural computers"—devices that process raw video and audio directly through neural networks, rendering interfaces dynamically in the moment rather than running traditional software. He invokes the early computing era, when it genuinely wasn't obvious whether the future would look more like a calculator or a brain. We went one way. He thinks the two may eventually swap positions. But when? "Piece by piece," he says. "TBD."

I've been a small business owner. I know that "TBD" is the most expensive answer to plan around. What I'd take from this conversation isn't a timeline—you won't get one that's reliable. What you can take is the underlying logic: the tools that improve fastest are in domains where outputs can be verified. If your work produces outputs that can be checked—documents, designs, analyses, communications—it's worth testing what's available right now rather than waiting for a cleaner story. The cleaner story isn't coming before the changes do.

The question Karpathy left sitting in that conference room, the one that I keep turning over: if you can outsource the thinking but not the understanding, and the tools keep getting better at the thinking—how much are you investing in the understanding?

Dorothy "Dot" Williams is Buzzrag's small business and entrepreneurship correspondent. She ran an independent bookstore in Asheville for thirty years.