Vibe Coding Isn't the Problem. Calling It Engineering Is

Let's Address the Elephant in the Room Again

Vibe coding has always been a weird topic to talk about. Lately it's gotten even weirder.

Say "vibe coding is a creative process, but it's not engineering" and people get defensive immediately, calling you a gatekeeper and all those interesting terms.

So I decided to write this brief article to answer those opinions in a short and precise manner, without too much sugarcoating or dancing around.

---

Engineering is Part of Creation

There's a real difference between the two. Creation is much broader term. engineering is part of the creation process. It's also part of maintenance, debugging, refactoring, and most of what engineers actually spend their days doing.

So the question worth asking is: during the creation process, who does the engineering? You? Your coding agent? Both of you?

Definitions Matter Here, Critically

Vibe Coding

You write a prompt and hand it to the AI. You don't edit the code and you don't review it. You might not know the first thing about programming and still ship something.

AI-Assisting

AI-generated, human-reviewed. The AI writes all of it, you read all of it. THIS IS NOT VIBE CODING, it takes enough skill to tell good code from bad.

AI-assisted

You and the AI write the code together, and you're the one driving. AI gives you speed, a second opinion, and the edge cases you'd have missed. ALSO NOT VIBE CODING.

---

Where This is Going

The trend is toward more semantics and more abstraction. It's been that way since assembly. Vibe coding is the next step on that line, and it will keep taking over more of the work. Maybe one day the job is 95% writing prompts, and to be honest, I'll welcome it, that makes my life easier too.

But the question right now is whether we're ready to build financial systems, health apps, and anything else touching sensitive data without analyzing the code.

We're not. Doing it anyway to prove your point will cause absolute chaos.

The line I'd draw:

Building something for yourself, for fun? Vibe code all of it. It's genuinely a good time.

Building something real, something that processes people's personal data, handles money, and turns a profit and vibe coding it from start to finish? That tells me one of three things:

1. You're not willing to spend two to four weeks learning the absolute basics of coding, security, and best practices.

2. You don't care about the quality of your own product, and ultimately other people's personal data and security.

3. You're not curious about how any of it works under the hood. And if you're calling yourself an engineer, you should be eager to understand the mechanics of software engineering and coding.

All three happen constantly now, and that's the sad part.

---

What I Actually Do?

I've been a software engineer for ten years. Even so, when I need to build something in a language I'm not fluent in, I still spend a day or two on the language reference, the docs, the basic mechanics, enough that I can understand what the AI produces.

Then I review everything it generates and ask so many follow-up questions that I probably spend more tokens interrogating the code than creating the project.

Every strong engineer I know works this way. We use AI extensively, every single day. We also take everything it gives us with a grain of salt.

So what's stopping you from doing the same?

We'll get to the point where you can let go of the steering wheel. We're not there yet. Keep holding the wheel to make sure you don't go off the road.

Comments

[luka jaja]

Great article, I completely agree with this viewpoint, especially this:

We'll get to the point where you can let go of the steering wheel. We're not there yet. Keep holding the wheel to make sure you don't go off the road.

For me it means that classic (the-old-time) engineering is dead. CRUD app like engineering problems will no longer take our night sleep, but we'll be left with harder and more niche and exciting problems to solve.

[Giorgi Kobaidze]

Totally true. Once thing AI does well is eliminating routine work and giving us more time for the interesting and creative parts of the work.

[Jo Do]

The three-tier split lands because it puts the boundary where it actually is: not who typed the code, but who reviewed it. "You don't edit the code and you don't review it" is the whole definition, and it explains why the discourse keeps talking past itself - people defending vibe coding are defending creation, people attacking it are describing engineering, and both are right about different activities. The review tier is also where the skill floor lives: AI-assisting takes enough skill to tell good code from bad, which is exactly the skill the no-review workflow never develops.

[Giorgi Kobaidze]

That sums up the whole idea very well. Thanks for that!

As an engineer, I don't really hate vibe coding, quite the contrary, I think vibe coding can be a great technique for things like quick prototyping and creating demos.

I actually wrote an article about this a few months ago: dev.to/georgekobaidze/could-vibe-c...

But we all need to agree that it's not engineering, we shouldn't lower the bar for calling someone an engineer, because if we do so, it'll became just another vague term that doesn't really mean anything at all.