Is Vibe Coding Real Programming?

When someone asks whether vibe coding is “real programming,” they’re rarely asking a neutral question. There’s usually an edge to it: defensiveness from someone who vibe codes and feels judged, or skepticism from someone who spent years mastering a craft and resents the idea that prompts in a chat window might count.

I’ve been on both sides. I stepped away from management to get back to hands-on coding, taking a lower title and lower pay because I missed building things. Even during the management years I never stopped: Python scripts, Chrome extensions, web scraping tools, late-night tinkering. Building feels different from managing. When I eventually stepped back from management, people thought I was crazy. I was happier. I was building again.

So when someone asks whether vibe coding is “real” programming, they’re touching a nerve. They’re asking whether the thing I restructured my career around can be delegated to a chatbot.

I once sat a technical interview built around date handling. Most candidates reached for libraries and got tangled in timezones and parsing. I spent the first ten minutes mapping what the user actually needed, realized the whole thing collapsed into plain integers, and got the highest score the recruiter had ever given. I wrote up that story in the interview I won by not writing code. Was that “less” programming because I barely touched a date library? Or more, because I solved the right problem?

The case against vibe coding

You don’t understand what you ship. When Andrej Karpathy described vibe coding as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists,” critics seized on the last phrase. Forgetting code exists is a liability. If you don’t understand your code, you can’t debug it at 3am, maintain it across framework upgrades, or extend it intelligently. Traditional programming builds understanding as you go. Vibe coding can short-circuit that loop.

Security and production stakes are real. This isn’t theoretical. AI-generated code often defaults to insecure patterns. Non-technical builders don’t always know what questions to ask. The attack surface from hastily shipped apps is growing. I’m not going to recite vendor research stats here; the pattern is visible enough in the wild. Senior developers spot the missing auth check. People without that background see a working UI and assume they’re done.

The Dunning-Kruger trap. The app looks good. The buttons work. For someone without experience, a working demo feels like validation.

It can devalue the craft. For developers who spent years mastering syntax, debugging production at midnight, and learning why things break, vibe coding can feel like an insult. Anyone can type prompts. Where’s the skill? There’s a legitimate anxiety about economics: if AI generates the implementation, what happens to junior roles and the career path that built senior engineers?

The case for vibe coding being real

Programming has always climbed abstraction ladders. Assembly programmers said C wasn’t real programming. C programmers said Python wasn’t. On-prem engineers said cloud wasn’t real ops. Each transition: higher abstraction, lower barrier, complaints from incumbents, eventual acceptance. Vibe coding is another step. You describe intent instead of syntax. You verify outcomes instead of micromanaging implementation. The fundamental work, solving problems with software, stays.

Shipping beats perfection. Reid Hoffman: if you’re not embarrassed by v1, you launched too late. Silicon Valley has always valued getting something into users’ hands over polish in a private repo. By that standard, vibe coding is the philosophy taken seriously. Idea to prototype in hours instead of months. Validate demand before investing months of engineering.

The skills transferred, not disappeared. Critics focus on what vibe coding removes: syntax mastery, line-by-line control. They miss what it requires: clear communication, product thinking, architectural judgment, verification. These aren’t less valuable than memorizing APIs. They transfer across tools.

I’ve shipped with React, TypeScript, Python, Swift, and Rails over the years, starting from HTML files and Visual Basic the way a lot of us did. The specific frameworks mattered less than I thought. What transferred was meta-knowledge: how to structure apps, how to debug, how to read docs, how to evaluate whether an architecture makes sense. Vibe coding amplifies that meta-knowledge. When AI generates code in a framework I’ve never used, I can still ask whether the error handling is adequate and whether the security patterns look sane.

One comment on a Hacker News thread stuck with me: experienced developers get more from AI, not less, because verification is the critical skill and verification requires knowing what good looks like.

The backlog finally opens. For years I had side projects that would take months and tools I wished existed but couldn’t justify building. Vibe coding removes friction that kept skilled builders from scratching every itch. It’s making them more productive.

Prototype, MVP, and production are different games

Here’s where both sides of the debate miss nuance.

Prototype: A concept model. Test whether an idea is worth pursuing. Show stakeholders. Throw away or rebuild.

MVP: Works reliably enough for real users. Validates a market hypothesis. Shippable v1, not perfect.

Production: Security, performance, maintainability matter.

Critics act as if all vibe-coded software ships straight to production. Some founders absolutely do that with payments and user data, which is dangerous. Defenders act as if vibe coding never needs to graduate beyond prototype. But the point of building is eventually having users.

The danger zone is confusing the stages. A demo that works for friends is not a system that survives strangers probing your API. I’ve seen the pattern repeatedly: polished UI, buttons work, data saves. Then launch. Then publicly accessible user records. Then API keys in frontend JavaScript. Then client-side “authentication” that checks a flag anyone can flip.

Would I trust my payment information to an app vibe-coded by someone who doesn’t understand the database layer? No. It’s appropriate caution about sensitive systems.

Would you trust health data to someone who doesn’t know what injection attacks look like? It’s about protecting users from builders who don’t know what they don’t know.

What’s actually on your plate

A friend who lived in China took me to dinner and refused to tell me what we were eating until the plates were empty. “If I tell you first, you won’t eat it.” The food was excellent. Afterwards she told me the “beef” was chicken hearts and the “squid” was cow tendon. I enjoyed every bite until I knew what was underneath.

That’s the cleanest picture of vibe coding I’ve got, and I’ve written the longer version of that meal. The app looks good. It runs. But if you never read what the model wrote, you don’t know what’s on the plate. Usually that’s fine. Occasionally it’s a payment handler quietly charging twice, and you find out after the fact.

Experienced programmers look at vibe-coded apps and see the chicken hearts. The auth that looks secure but isn’t. The queries that work until someone probes them. The architecture that functions today and becomes unmaintainable in six months. The vibe coder sees a working app. The expert sees what’s actually on the plate.

For personal projects, enjoy the meal. For anything touching user data, payments, or sensitive information, the gap between perception and reality is where incidents live.

Where I’ve landed

Vibe coding is real programming if you define programming as creating software that solves problems.

But vibe coders aren’t necessarily “programmers” in the craft sense, and that’s fine. Labels matter less than we think. You don’t need to be a “programmer” to create valuable software.

What matters: honesty about what you know and don’t know, and rigor matched to stakes.

Questions that matter more than the label:

• Are you solving real problems for real users?
• Do you understand the responsibility of what you ship?
• Are you honest about what you don’t know?
• Are you using appropriate rigor for the stakes?

Not everything needs the same rigor. Match it to prototype vs production:

Prototypes and experiments: Vibe freely. Move fast.

MVPs: Vibe but verify. Have someone experienced review output. Test more than you think.

Production: Transition to rigorous practices. Understand security implications. Own what you ship.

Smart builders move along that spectrum based on context. I’m a programmer who vibe codes. It doesn’t make me less of one. It makes me more productive, because I bring decades of verification instinct and I’m honest about when I’m prototyping versus building for production.

What’s “real” has always been more complicated than gatekeepers admit. That doesn’t mean all criticism is wrong. Some vibe-coded apps are security disasters. Some AI output is unmaintainable. Standards matter.

Is it useful? Is it responsible? Does it serve users? Can you stand behind it?

I write about AI coding tools for a living at Codewalkers. This piece is my personal take, not a panel debate. What matters is what you build, who it serves, and whether you take responsibility for it. Everything else is labels.