Vibe coding is one of those expressions that seem born to be hated and then, slowly, become useful.

At first it sounds like: I don't think, I ask the AI, I accept what comes out, keep going. A cheerful way to produce technical debt with a musical background.

But it would be too easy to dismiss it like that. The truth is that vibe coding has intercepted a real thing: programming with a model changes the relationship between idea and prototype.

First you had a thought and then a long climb. Now often you have a thought and half an hour later something moves on the screen. It's hard not to be seduced by it.

The interesting question, in 2026, is not whether vibe coding is true. It is. The question is: what happens after the honeymoon?

The prototype has become economical

This is the most important part.

AI tools have lowered the emotional cost of getting started. Before, if you wanted to try an idea, you already had to put in the work: choose stack, create project, remember boilerplate, write layout, connect APIs, wrangle with boring details.

Now you can say: give me a first version.

And a first version arrives.

Not always beautiful. Not always correct. Often fragile. But it comes. And when it arrives, it changes the conversation. You are no longer arguing in a vacuum. You're touching something.

This is very powerful for designers, founders, product managers, senior developers tired of rewriting scaffolding, curious people who wouldn't have opened an editor before.

Vibe coding is hype because it gives more people the physical sensation of the software being created.

The problem is that the software lives on

The part that the meme tells the least is the day after.

The prototype must be read. Correct. Tested. Deployed. Secured. Got it from someone else. Connected to real data. Made accessible. Maintained when a dependency changes.

Here pure vibe coding hits the wall.

A model can generate a lot of code quickly, but code is not value in itself. It is a promise of behavior. And a promise must be verified.

The risk of vibe coding isn't writing ugly code. We have always done it even without AI. The risk is losing the sense of ownership: "the model did it" becomes an excuse for not understanding enough.

But the runtime doesn't accept excuses. If the code runs in production, it's yours.

From vibe coding to agentic engineering

The mature version of vibe coding is not to stop using agents. It is to use them with a more serious cycle.

Not: it generates everything and we hope.

But:

1. describe the intention;
2. let generate a draft;
3. ask the agent to explain the plan;
4. make small diffs;
5. launch tests;
6. do reviews;
7. correct;
8. only then join.

This thing deserves a different name. I like agent engineering, even if it sounds a bit solemn. It means using agents not as slot machines, but as collaborators within an engineering process.

The point is not to take energy away from vibe coding. It's giving her tracks.

Where it works great

Vibe coding works when the cost of error is low and the value of exploration is high.

Examples:

• interface prototypes;
• personal tools;
• internal dashboards;
• small games;
• one-time script;
• API scans;
• proof of concept;
• mechanical refactors with good tests;
• technical contents to be transformed into demos.

In these cases speed is the point. You want to see if the idea has legs. You want to find out what you didn't understand. You want to get to a concrete conversation.

Vibe coding is perfect for making form emerge.

Where it gets dangerous

It becomes dangerous when the system has consequences and no one slows down.

Payments, personal data, auth, permissions, infrastructure, database migrations, sensitive legacy code, compliance, production. Here the vibe is not enough. We need rigor.

It doesn't mean AI can't help. In fact, it can help a lot. But it must work within narrow confines: branch, sandbox, test, lint, review, feature flag, rollback.

The phrase to be tattooed on the monitor is simple: the faster the agent, the more readable the process must be.

If you can't explain what's changed, you haven't accelerated. You just shifted the debt from time to understanding.

The new role of the developer

The most interesting part is that the developer's job doesn't disappear. Change density.

Less time on boilerplate. More time on intention, decomposition, review, integration, testing, boundaries.

The developer becomes a kind of technical editor. Not in the lame sense of “proofreads.” In the strong sense: it decides what must exist, what must be cut, what is consistent with the system, what deserves trust.

A good editor doesn't take everything they get. He doesn't even rewrite it all out of pride. Recognizes good material, brings it to form, protects the reader.

With agents, the reader is also the future maintainer. Often that's you in three weeks.

The pattern I see emerging

The healthiest pattern is this:

• human: intention, constraints, taste, responsibility;
• agent: variants, scaffolding, search, local modifications, repetitive tests;
• infrastructure: sandbox, CI, trace, permissions, deployment;
• team: review, ownership, standards.

When one of these pieces is missing, something becomes deformed.

Only human: slow, often bogged down by repetitive work.

Agent only: fast, but without situated judgment.

Just infrastructure: Elegant process for producing useless things.

Team only: very orderly meetings around a prototype that never arrives.

The best happens when the pieces talk to each other.

A small checklist

Before letting a vibe-coded prototype grow, I would ask myself these questions:

• do I understand the structure of the code?
• are there tests for critical behavior?
• do I know which files the agent touched?
• have I removed code generated but not used?
• have any secrets, tokens or fake data ended up in the wrong place?
• is the minimum accessibility respected?
• does the deployment have rollback?
• can anyone besides me keep it?

If the answer is no to too many questions, it's not a failure. It's just a prototype that needs to remain a prototype a little longer.

My reading

Vibe coding is a loud word for a tender thing: the joy of seeing an idea take shape before fear stops it.

I don't want to throw it away. That would be snobbish. Many good things are born like this, half crooked and alive.

But the remaining software needs more. It needs understanding, testing, ownership, infrastructure, boundaries. It needs someone to say: cool, now let's make it real.

Maybe the future isn't about choosing between "seriously" programming and "vibe" programming. Maybe it's learning to change gear: explore lightly, then consolidate with respect.

The human part is there. Know when to run and when to sit and read the diff.

Sources

• Simon Willison: Not all AI-assisted programming is vibe coding
• OpenAI: How people are using ChatGPT
• GitHub Blog: GitHub Copilot coding agent
• Anthropic: Building effective agents
• Stack Overflow Blog: Why vibe coding is the future