Vibe Coding: Is Building Software Without Understanding the Code the Future?

Sahil Sharma

 

 

 

 

 

 

This semester, my team built a dungeon game for our OOP course project, in C++ with raylib and CMake. It had a player, enemies, rooms, and the whole thing. The first version came together way faster than it should have. I described what I wanted to an AI, accepted whatever it gave me, and it worked. I felt like a genius for about forty minutes.

Then the game started crashing every time an enemy died. No helpful error, just a segfault. I opened the code and realized I couldn’t explain why my own project was broken. There was a vector of enemy pointers, a pile of virtual functions, and an inheritance tree I had never actually read. I stared at the screen like it was a viva question I hadn’t prepared for.

That’s vibe coding in a nutshell, and as a second-year engineering student, I have a lot of feelings about it.

So what even is it?

Vibe coding means you describe what you want in plain English, an AI writes the code, and you go with the flow. You don’t read every line or worry about the architecture. If it runs, it ships. It blew up because it’s genuinely fun. You feel like Tony Stark talking to Jarvis.

And honestly, the tools are insane now. Setting up a CMake project with raylib used to eat an entire evening of linker errors. Now it takes five minutes. For hackathons, side projects, and quick MVPs, it’s a cheat code. I won’t pretend otherwise.

The part nobody posts on LinkedIn

Here’s what the “I built a startup in 3 hours” posts skip: debugging.

Writing code is maybe 30% of the job. The rest is figuring out why something broke. If you don’t understand the code, every bug is a black box. In my case, the crash came from erasing dead enemies from a std::vector while looping over it. That is a classic mistake, and it’s exactly the kind of thing you’d catch instantly if you’d written that loop yourself. I didn’t, so I pasted the error back into the AI, got a patch, and the patch broke the enemy movement. Suddenly I was three layers deep in a mess nobody understood, including the AI.

The worst part was our project review. Our professor pointed at one function and asked, “Why is this virtual?” I knew the textbook definition of polymorphism. I could not explain why my game needed it. That moment hurt more than any segfault.

Security is the scary bit

There’s also the stuff you don’t know you don’t know. AI-generated code can quietly include insecure patterns, like hardcoded keys, weak authentication, or missing input validation. If you can’t read the code, you can’t catch it. For a college game, who cares. For an app handling people’s real data, that’s a disaster waiting to happen.

But let’s be fair

I don’t think the “real programmers write everything by hand” crowd has it entirely right either. Every generation of developers has had a layer of abstraction that the older ones complained about. High-level languages were cheating because you weren’t writing assembly. Then it was frameworks. Then Stack Overflow copy-paste. Nobody understands every transistor under their code, and we’re fine.

So maybe not understanding everything isn’t the problem. The problem is understanding nothing.

There’s a big difference between “AI wrote the boilerplate, but I know what it’s doing” and “I have no clue what’s in my project and I’m just praying.” The first is smart. The second is gambling.

How I use it now

After the dungeon game fiasco, I changed my approach. I still use AI heavily, but I follow a few rules:

• I read what it generates, even if I only skim. If something looks unfamiliar, I ask it to explain.

• I write the core logic myself when I’m learning a concept. Let the AI handle CMake and window setup, but I’ll write my own class hierarchy and virtual functions, because that’s the whole point of an OOP course.

• I treat it like a fast, slightly overconfident senior. Useful, but I verify its work.

Weirdly, this made me learn faster. Asking “why did you design it this way?” after every generation is basically a free tutor available at 2 AM. I only truly understood inheritance and virtual functions when I rebuilt the enemy classes myself and watched update() behave differently for each type.

So, is it the future?

Yes and no.

Vibe coding is definitely part of the future. The barrier to building things is dropping fast, which is amazing. A designer, a student, or a small-town entrepreneur can now make software that would’ve needed a whole team a few years ago. Gatekeeping that would be silly.

But “building without understanding” as a long-term career strategy? I don’t buy it. When everyone can generate code, what sets you apart is judgment: knowing what to build, spotting what’s wrong, and fixing it when it breaks. Those skills come from understanding, not vibes.

I think the engineers who win will be the ones who use AI to go faster and still know what’s happening under the hood. The tool gets you to the starting line quicker, but you still have to know how to run the race.

As for me, I’ll keep vibing. I’m just going to keep one eye on the code while I do it. Because the next time my game crashes, I want to be the person who fixes it, not the person hoping the AI feels generous.