Why Vibe Coding Still Needs Engineering?

Damir Dobric

Here are two extremely simple C# snippets from one of my slides. If you think you can make software without needing to understand the produced code, please try to focus on these few lines only, at least. Both are generated by AI - VibeCoding. Together, they are about nine lines of code in two functions. Both compile, both look clean, and both are typical AI output.

Here is the question. How many bugs do you see?

Sample A – "Returns the average grade"

public static double AverageGrade(List<Student> students)
    => students.Select(s => s.Grade).Average();

Sample B – "Returns the top N scores"

public static int[] TopScores(int[] scores, int n)
{
    Array.Sort(scores);
    Array.Reverse(scores);
    return scores.Take(n).ToArray();
}

Take 60 seconds for each before you read on.

Six bugs in nine lines of code

A – AverageGrade (3 lines)

  • If students is null, the application will crash.
  • If the list is empty, the application crashes again. Average() throws on an empty sequence.
  • If one student in the list is null, it crashes again.

B – TopScores (6 lines)

  • It silently sorts and reverses the caller's original array, so other parts of the system now see changed data.
  • If scores is null, it crashes.
  • If n is negative, it returns an empty result without any error.

That's six bugs in nine lines, and nobody notices them in a 60-second look. Ok, try with 6 minutes :).

Now scale it up

Imagine 100,000 lines of vibe-coded software, or a million. Even if real code were a hundred times better than this example, you would still have hundreds of hidden bugs that nobody wrote consciously, nobody reviewed, and nobody understands.

Now let's picture the same thing with a car

Imagine a technology called VibeCarCreating. You describe your dream car, and an hour later it's standing in front of your house. It's shiny and quiet, the doors close perfectly, and the dashboard glows.

But nobody designed the brakes. Nobody calculated the steering. Nobody crash-tested it. It was generated, and it looks right. Your family is waiting to get in.

Would you drive it? Maybe slowly, around an empty parking lot. Would you drive it on the Autobahn at 200 km/h with your children in the back seat?

And now make it fly

Your Prompt: "Take this car and make it fly." Wow. Next Monday you go to your colleagues and will probably say: "See what I did with Cloude at the weekend."

Imagine it's a flying car. A car that fails stops at the side of the road. A plane that fails doesn't get a second chance.

We would never accept this for a car, yet we're starting to accept it for software that runs hospitals, banks, factories and energy grids.

My question: Are these two car models an 80:20 solution, which can be completed by some freelancer or a student from your neighbourhood?

Where would you drive this code?

I'm not against vibe coding. Many of us did that in the past, just manually. The result was inventing the Application Lifecycle Framework to stop engineers from being in the vibe flow. The difference now is democratisation and scale. You do not have to be a professional to jump into the Vibe flow. I also use a lot of AI to generate code every day (and night). But generated code is a prototype, not a product, until someone who understands it has tested it, reviewed it and taken responsibility for it. Usually, more than a single persona.

Here is my advice. Before you ship generated code, ask yourself the honest questions:

  • Where will it run? A prototype, or the core of a business?
  • How fast? A handful of users, or millions of transactions?
  • Can it fly? If it fails, does it stop safely or crash hard?
  • How secure is it?

Where would you drive or fly such code, and how fast?

VibeCoding #AI #SoftwareEngineering #CodeQuality #GenAI #dotnet #AgenticAI

Originally published on LinkedIn.

comments powered by Disqus