Vibe Coding Gets You There Faster — It Doesn't Choose Where You're Going

In early 2025, Andrej Karpathy Definition Co-founder of OpenAI posted something on X that stuck with me. The gist: he’d been building software in a new way — no code, just talking to an AI, describing what he wanted, and accepting whatever it generated. He called it Vibe Coding . The term spread fast.

It describes a development style where natural language is the primary input and the AI handles code generation. You don’t need to know syntax. You don’t need to configure a dev environment. You just need to describe what you want. From idea to working product, sometimes a few hours.

The appeal is obvious: ideas that used to require a dev team and several weeks to validate can now be tested by one person over a weekend. I tried it myself almost immediately. I built a personal expense tracker — AI-powered import of bank statements, automatic categorization, monthly reports. Idea to working app: roughly one weekend. I used it for about two weeks, then stopped. Not because the app was broken. Because I’d figured something out.

What It Changes

Karpathy said something in 2023 that I keep coming back to: English is the hottest new programming language¹. His point was that LLMs had crossed a threshold where humans no longer needed to learn specific syntax to get computers to do things — you just had to articulate what you wanted.

Vibe Coding is that logic taken further. At its core, it’s a format-conversion capability: one language into another, one form of information into another.

The most basic layer is natural language to code. One layer up: turning a fuzzy description into an interactive interface. One layer above that: taking the logic inside a domain expert’s head and turning it into something other people can directly see and manipulate.

That third layer is where I think the real underappreciated value sits.

Here’s a concrete example. Working in AI products, I’m constantly explaining to non-technical stakeholders what a given AI solution is, why it’s designed the way it is, and what problem it actually solves. Pure verbal explanation falls apart in these conversations — the other person has no reference frame, so even when you’re using the same words, you’re activating different concepts.

The old approach: build a demo prototype, then wait on the dev cycle. Now, someone who understands the business logic can turn an idea into something clickable and tangible within a few hours. That visibility — that’s the cost Vibe Coding actually compresses. Not development cost. The cost of getting someone to understand what you’re talking about.

Karpathy updated his framing in early 2026. He now uses “agentic engineering” to describe the professional form of this practice, and he specifically emphasized the word “engineering” — meaning this isn’t tinkering, it’s a craft that requires judgment and expertise². That shift says something important: the tools got stronger, but the demands on the person using them didn’t drop.

What It Doesn’t Change

The mistake I made with my expense tracker was a classic one: I confused “this is technically possible to build” with “I actually need this.”

That confusion has nothing to do with how advanced the tools are. It happened because I never seriously asked myself before starting: what’s the real problem I’m trying to solve? Can’t my bank statements already handle this? If they can, is the extra thing I want actually a feature — or just the feeling that having it would be nice?

At the personal project level, the cost of that mistake is a wasted weekend. At the organizational level, the structure is identical, and the cost is much higher.

I’ve seen it happen. A team poured significant resources into building a user behavior analytics system. The data came out clean. The reports looked sharp. Then in a retrospective, someone asked a question: what share of our actual business does this user segment represent? The answer: a small one, and not a core growth driver.

The system was technically sound. From a requirements standpoint, it was answering a question that didn’t exist.

In that situation, Vibe Coding’s speed just gets you to the wrong place faster.

Technical Debt Is Real — But It’s Not the Biggest Risk

There’s already a lot of discussion about the technical debt that comes with Vibe Coding. In September 2025, Fast Company reported on engineers inheriting AI-generated codebases — hard to maintain, hard to extend, because the generation process involved no human understanding or review³. Security is the same story: Veracode’s research shows that while the functional quality of AI-generated code has improved significantly, security improvements have lagged far behind⁴.

These problems are real and deserve serious attention. But in my view, they’re second-order problems.

The first-order problem is: are you building the right thing?

Technical debt is “you built the right thing, but built it badly.” Misaligned requirements are “you built the wrong thing, and built it fast.” The former can be fixed. The latter requires starting over.

Vibe Coding lowers execution costs — but it also lowers the pressure to think carefully before you execute. When development was expensive, the cost of iteration forced you to get requirements right before starting. That pressure is gone now, which means you have to consciously do the thing that “expensive” used to make mandatory.

What Actually Gets Scarcer

When the barrier to building drops, the result isn’t just “more people can create things.” It’s also “more things that shouldn’t have been built get built.”

So what matters more in this environment?

My observation: people who can fluently move between business logic and technical implementation are becoming rarer, not more common.

These people need to hold several things in mind simultaneously: what the actual business problem is; what’s technically feasible and what has real costs; and how to translate between the two for whoever’s on the other side — whether that’s a decision-maker who only speaks business, or an engineer who only sees technical specs.

That translation ability is structurally similar to what LLMs do. An LLM converts natural language into code, turns ideas into interfaces. But before it can do that, a human has to do something else first: judge whether the direction of that translation is right.

No matter how capable the tools get, that judgment stays with the person.

Back to the Expense Tracker

I never went back to that app. But I don’t think the weekend was wasted.

Because it was only after building it and using it for two weeks that I finally understood what I actually needed from expense tracking. That need, it turned out, could be fully met by a spreadsheet I look at once a month. No AI required.

Vibe Coding gave me a fast path to an answer. But the most valuable part of that answer wasn’t the software — it was that the software exposed a misconception I’d had about my own needs.

Whether that happens depends on whether you stop, after you’ve built something, and honestly ask: does this actually solve the problem I started with?

That question doesn’t answer itself just because the tools got better.