If You're Gonna Vibe Code, At Least Take Testing Seriously

When Code Just ‘Feels’ Right

In the age of large language models (LLMs), a growing number of developers — and not just beginners — are starting to adopt what what folks have taken to calling "vibe coding." The premise? You don't need to understand the code you're writing — not really. You just describe what you want to an LLM, let it generate some code, run it, and if it crashes or fails a test, you feed the error back in and repeat until it looks like it's working.

I’ll admit the appeal: it’s fast, it’s productive (sometimes), and it lowers the barrier to building software. I’m not here to sneer at it. (Not today, anyway, but give me a follow for the future.) But if you’re going to accept the vibe coding premise — that understanding can be deferred or outsourced entirely — then you must accept the consequences for how you test software too.

And here’s the blunt truth: if you're vibe coding, unit tests are nearly worthless.

Why Unit Tests Fail in the Vibe Coding Paradigm

Unit tests are built on the assumption that developers understand the internal behavior of their system well enough to write meaningful tests around that behavior. They act as guardrails for refactoring, as specifications for collaborators, and as safety nets when edge cases rear their heads.

But in a vibe-coded system — one stitched together by copy-paste and iterative LLM guesses — those assumptions don't hold. You often don’t really know what the code is doing at a low level. You might not know what the actual responsibilities of a module are, or whether the boundaries of those responsibilities even make sense. Unless you are well-versed enough in the software engineering paradigm, you might not have “modules” with “boundaries” at all.

So what are your unit tests even testing? Often, they're testing your guess about what a function is supposed to do — not whether the larger system is behaving correctly. Worse, when written by LLMs, these tests tend to devolve into trivial, self-confirming nonsense. “Test that add(2, 2) equals 4.” Thanks, Copilot, green bar.

Unit tests, already prone to becoming a performance in traditional development, devolve fully into “testing theater” in the vibe coding world. They offer the illusion of safety, while the real bugs lurk in the cracks between modules, in misunderstood business logic, and in the edge cases no one bothered to model.

System and Integration Tests Are Non-Negotiable

If you're not going to bother to understand the internals of your vibe-coded system, you must verify the externals. That means high-quality system and integration tests — ones that simulate realistic usage scenarios, cover happy and unhappy paths, and validate business outcomes, not implementation details.

These tests are not optional. They are the only thing standing between you and shipping a broken product.

But here's the twist: you cannot offload this work to an LLM. You need business understanding. You need domain knowledge. You need to talk to people — product managers, operations staff, subject matter experts — and deeply understand what "correct" behavior actually means in the real world.

Vibe coding defers understanding at the code level. But testing cannot defer understanding at the business level.

A Better Way (Or At Least a More Honest One)

Here’s the thing: I’m not totally opposed to vibe coding. Used carefully, it can supercharge prototyping, accelerate learning, and cut through boilerplate. But if you’re going to use it in production-grade systems, you need to complement it with rigorous, scenario-driven, domain-aware system testing.

That’s not something you get from your friendly neighborhood AI. That’s something you get from experience, from business conversations, and from people who’ve shipped systems that lived and evolved for a long time and ultimately mattered.

From Vibes to Value

I help teams cut through the noise and build software that actually works — not just compiles and gives the illusion of running correctly. As a software consultant with deep expertise in testing strategy and engineering leadership, I focus on designing systems that are verifiable, resilient, and aligned with real business needs. Whether you're prototyping with LLMs, scaling a team, or trying to bring discipline to a chaotic codebase, I can help you move from vibes to value and true engineering productivity. If you're ready to take your testing and development practices seriously, let’s talk. I offer consulting and fractional leadership services across Asia and beyond.