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. Agents and hosted builders got better at producing something that looks finished. The forgetting problem did not go away; it just hides under prettier previews and longer agent transcripts.

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.

What I use, and for what

The debate often treats “vibe coding” as one blob. It isn’t. Intent-to-UI platforms are one thing. Coding agents that open PRs against a real repo are another. I use both, and I try not to pretend they are the same skill.

I tried the vibe platforms: Lovable, v0, Bolt, Replit, and a few others in the same lane. They are genuinely useful for prototyping. You can describe a screen, get something clickable, and show a stakeholder the same afternoon. When a platform handles auth and billing for you, that is a real advantage for early validation. I still recommend them for that job, especially when the alternative is weeks of wiring before anyone can click anything. They are not my daily drivers anymore. Once I care about the repo, the tests, and the long-term shape of the code, I want an editor and agents that work against my files.

For real product work I use an AI editor plus coding agents that work against my repo; the current list is on my stack page. That distinction is load-bearing. Vibe coding, in the popular sense, is intent to UI or app quickly. General AI coding agents and PR agents are a different loop: plan, edit files, run checks, open a diff, argue with the review bot. The tool-by-tool detail is in the CodeWalkers AI coding tools ranking and the vibe coding guide.

My own failure mode matters here too. I spent too much time on review bots and review theater, and not enough time clicking through the product as a user in a browser. None of that replaces sitting in the app, submitting the form twice, signing in as a second user, and seeing what actually breaks. I had to relearn that the hard way, after shipping things that looked clean in the diff and felt wrong in the browser.

The practical verdict I give people now is simple. Launch on a vibe platform if that gets you real feedback fastest. Harden if real users show up. Export the code early enough that you are not trapped. The last twenty percent (auth that holds, Stripe that reconciles, infra that survives a bad deploy) is harder than the first eighty percent that looked magical in the preview.

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.

The platforms make this confusion easier, because the preview looks production-ready long before the ownership model is. Hosted auth and billing help until they don’t: until you need a custom permission rule, a refund path that matches your ledger, or a backup you can restore without opening a support ticket. That is usually where “we vibe coded it” stops being a speed story and becomes an operations story.

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.

The same meal metaphor applies to agent-written PRs. A green check and a tidy summary are presentation. The plate is the diff, the migration, the permission check, and the path a stranger will hit when they ignore your happy flow. Review bots help me notice some of that. Browser-as-user testing is still how I find the rest.

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?
• Did you test it as a user, or only as a reviewer of generated diffs?

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

Prototypes and experiments: Vibe freely. Move fast. A hosted platform is often the right hammer.

MVPs: Vibe but verify. Have someone experienced review output. Test more than you think. Prefer a repo you can export and own.

Production: Transition to rigorous practices. Understand security implications. Own what you ship. Agents can still write a lot of the code. You still own the plate.

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. That honesty includes admitting when I leaned too hard on review bots and too lightly on the browser.

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?

What I care about is whether you know which stage you are in, whether you tested the product the way a stranger will use it, and whether you will own the mess when the preview lied. That is the bar I hold myself to. Everything else is labels.