Vibe coding: what it is, how real it is, and when it's worth using

Vibe coding is the fastest-growing search term in the industry in Argentina right now, and yet almost nobody explains it without falling into one of two extremes: "it's the end of programming" or "it's a fad for people who can't code." Neither helps if you're actually trying to figure out whether it fits your project.

What it actually is

The term was popularized by Andrej Karpathy in 2025: coding by letting an AI assistant write the code while you steer by outcome ("make it look like this," "have it do that"), without reviewing every line it generates. That's the real difference from coding with AI in the traditional sense: it's not using a smart autocomplete inside your workflow, it's letting go of line-by-line control and trusting the final result.

That sets it apart from "coding with AI" the way an experienced developer does it, where a developer with judgment uses AI as a tool but still reviews, tests, and decides on every change before it reaches production.

How real it is vs. how much is hype

It's real as an adoption phenomenon: a huge number of people with no technical background are building functional prototypes in hours, something that simply didn't happen before. That's a genuine shift, not smoke.

The hype starts when it gets sold as a replacement for serious software development. There, the industry's experience (ours included) is consistent: a system built entirely on vibe coding works fine until it needs to scale, integrate with another system, handle sensitive data, or survive a traffic spike. That's when the problems nobody looked at because nobody understood them show up: security, data architecture, performance, maintainability.

When it makes sense to use it

For specific cases, vibe coding is a legitimate tool, and we use it ourselves:

• Validating an idea before investing in real development. If you need to show something to an investor or a potential client next week, a vibe-coded prototype gets the job done.
• Disposable internal tools. A script to process a spreadsheet once, a small internal dashboard, something with no external users and no critical data.
• Very small-scope, short-lived MVPs, where the goal is to learn fast whether there's a market, not to build the foundation of a product meant to grow.

When it ends up costing you more

The problem isn't the prototype, it's what happens next: when that prototype "works" and the company decides to take it to production as-is, with real customers paying and real data on the line.

That's where we see projects land at Manivela: systems built on vibe coding that hit a ceiling (they don't scale, they have security holes, nobody understands why what works actually works), and a good chunk of the foundation has to be rebuilt to keep growing. Rebuilding usually costs more than starting right, because on top of writing the new code, someone has to understand and take apart the code that's already there.

How we think about it at Manivela

We use AI every day to move faster, as we explain here. The difference from pure vibe coding is that every line the AI generates goes through an engineer who understands architecture, security, and performance before it reaches production. AI provides the speed; the team provides the judgment.

In short

Vibe coding is good for fast prototyping and validating ideas. It's not good for building the system your business is going to depend on for the next few years. If you're at the point of deciding whether your prototype is ready to grow, or whether it's better to build it right from the start, let's talk.