DEV Community

Cover image for Vibe Coding Is Everywhere. But Is It Actually Good Software Engineering?
Kilowott for Kilowott

Posted on

Vibe Coding Is Everywhere. But Is It Actually Good Software Engineering?

Software development is changing. AI can now write code, build prototypes, generate tests, debug issues, and take on tasks that once took developers hours to complete.

At Kilowott, we’ve seen this shift firsthand. AI-assisted development can help teams move from an idea to a working prototype faster, explore solutions more efficiently, and take some of the repetitive work out of software development. But the biggest value doesn’t come from simply producing more code. It comes from knowing how and when to use AI as part of a proper engineering process.

That distinction is becoming increasingly important.

There’s a difference between using AI as a development tool and letting AI take over the development process. And that’s where vibe coding enters the conversation.

Vibe coding, prompting an AI to write software and accepting the output with little or no manual review can be useful for experimentation and rapid prototyping. But when it becomes a substitute for engineering judgment, testing, security reviews, and code ownership, things can quickly become complicated.

AI can produce working code. That doesn’t always mean it has produced good software.

For developers, the real question isn’t whether AI should be part of the development process. It’s how to use it without losing the engineering discipline that makes software reliable, maintainable, and scalable.

In this article, we’ll look at where AI-assisted coding can genuinely help, where it can fall short, and what developers and the teams building with them need to keep in the loop.

What Is Vibe Coding, Exactly?

The term comes from a February 2025 post by Andrej Karpathy, and it has since split into two very different things that get talked about as if they're one:

  • AI-assisted development, a professional developer uses tools like Copilot, Cursor, or Claude Code inside a normal engineering workflow: architecture is planned, output is reviewed, tests are written.
  • Vibe coding proper, you describe what you want, accept the output with minimal scrutiny, and iterate by re-prompting rather than by reading and reasoning about the code.

Most of the discourse, the hype and the backlash alike is actually about #2.And the confusion between the two is a big part of why every "vibe coding is amazing" post and every "vibe coding is a disaster" post can both be citing real experiences.

Why It Took Off

The appeal isn't mysterious. When it works, it's genuinely fast:

  • Boilerplate, CRUD scaffolding, and standard API integration have shown time savings as high as 81%
  • A February 2026 McKinsey study of 150 enterprises found routine coding tasks saw a 46% average time reduction, with code review cycles shortening by 35%
  • Prototypes that used to take weeks now take hours

If your job is "get something working to show someone," this is close to magic. That's exactly why dev.to's own trending page, GitHub's explore feed, and Hacker News all skew toward projects that look finished, polish is cheap to generate now, and platforms reward what looks complete over what's actually well-built.

That gap between looks done and is done is the whole story.

The Part the Demos Don't Show You

Vibe coding is honest about the easy 80% of a feature and quiet about the hard 20%. Generating a checkout flow, an admin dashboard, or a CRUD panel takes minutes. What quietly falls apart is:

  • The payment call that partially fails halfway through
  • Two admins editing the same record at the same time
  • Auth edge cases that only show up under real traffic
  • Data validation that a demo never needed

The apps that look the most finished in a screenshot are often the most fragile underneath because AI is extremely good at producing something that reads as production-ready, and only a trained eye can tell the difference between "looks done" and "is done."

The Numbers Nobody Wants Attached to Their Launch Post

If you strip out the vibes and just look at the research from 2025–2026, a pretty consistent picture shows up:

  • Around 45% of AI-generated code samples fail security tests, including critical OWASP Top 10 vulnerabilities, per Veracode's 2025 analysis
  • An independent December 2025 audit of five major vibe-coding platforms across 15 test apps turned up 69 vulnerabilities, several critical
  • A real-world case: a 2025 CVE tied to a popular vibe-coding platform exposed over 170 production apps through a missing database access-control setting — full user data exposed to anyone with the public key
  • 92% of U.S. developers now use AI coding tools daily but only 29% trust the code those tools produce. That trust gap is the whole crisis in one stat
  • Projects with a high "vibe score" (polished presentation, little underlying substance) were found to be 3.2x more likely to be abandoned within 18 months, with 42% higher rates of critical vulnerabilities

Meanwhile, Gartner is projecting that ungoverned prompt-to-app development could increase software defect rates by 2,500% by 2028 if organizations don't put quality controls in place. That's not a typo, that's the scale of the gap between adoption speed and governance maturity.

Experience Level Changes the Outcome - A Lot

Not everyone gets the same result from the same tool, and this is where "vibe coding is great" vs. "vibe coding is a disaster" often comes down to who's holding the wheel:

  • Senior developers (10+ years) report the strongest gains around 81% productivity improvement because they use AI to offload routine work while keeping architecture and review under their own judgment
  • Mid-level developers see solid gains too, but spend meaningfully more time reviewing and correcting generated output
  • Junior developers get the most mixed results, a notable share admit they ship code they don't fully understand

That last point is the actual engineering risk. AI-assisted coding doesn't remove the need for engineering judgment, it just moves where that judgment has to happen, from writing to reviewing. If nobody in the loop has the judgment to review, the judgment simply doesn't happen.

So - Is It Good Software Engineering?

Software engineering, as a discipline, isn't really about how fast code gets typed. It's the set of practices, architecture, testing, review, security thinking, maintainability, that make software reliable over time, not just functional in a demo. By that definition:

Vibe coding, on its own, is not software engineering. It's a prototyping technique that happens to produce runnable code.

That's not necessarily an insult, sketching, prototyping, and fast iteration have always been valuable. The mistake is treating the sketch as the deliverable. The 63% of vibe-coding tool users who identify as non-developers (PMs, founders, designers) aren't doing anything wrong by building an internal tool this way the risk shows up when that prototype's code quietly becomes the production system with nobody applying engineering discipline to it retroactively.

Where AI Coding Adds Real Value

AI coding tools are at their best when they accelerate work without replacing engineering judgment.

They can be particularly effective for:

  • Rapid prototyping: Turn an idea into a working proof of concept before committing significant development resources.
  • Boilerplate and repetitive tasks: Generate common components, API structures, test cases, documentation, and other predictable code.
  • Exploration and experimentation: Try different approaches, libraries, or architectures quickly before deciding which direction makes sense.
  • Internal tools: Build lightweight dashboards, scripts, automations, and single-purpose applications where the risk and complexity are relatively low.
  • Developer productivity: Let experienced developers delegate routine implementation while they focus on architecture, problem-solving, and review.

The common thread is simple: AI handles more of the execution while developers remain responsible for the decisions.

Where Human Expertise Still Matters Most

The equation changes when the cost of getting something wrong becomes high.

AI-generated code deserves significantly more scrutiny when it involves:

  • Security-critical functionality: Authentication, authorization, payments, sensitive data, and access control require careful human review.
  • Complex business logic: AI may produce technically valid code that doesn't correctly reflect the rules or requirements of a business.
  • High-concurrency systems: Distributed systems, real-time applications, and concurrency-heavy code can fail in ways that aren't obvious from a simple code review.
  • Production-critical infrastructure: Code responsible for reliability, performance, deployment, or core services needs to be understood and tested by engineers who own the system.
  • Long-term architecture: AI can generate a solution that works today but creates unnecessary complexity, technical debt, or maintenance problems tomorrow.
  • Code nobody understands: The biggest risk isn't AI-generated code itself. It's shipping code that the team cannot explain, test, debug, or confidently change.

The Real Divide Isn't AI vs. Developers

The question shouldn't be “Should developers use AI?”

The better question is:

“Which parts of software development should we delegate to AI, and which decisions should remain human?”

AI can dramatically reduce the time it takes to produce code. But production software requires much more than code generation. It requires architecture, context, security, testing, accountability, and long-term thinking.

The strongest engineering teams aren't removing humans from the development loop.

They're using AI to make experienced engineers more effective.

The Bottom Line

Vibe coding isn't the villain the backlash makes it out to be, and it isn't the free lunch the hype promised either. It's a fast way to produce a shape of software. Whether that shape becomes real software engineering still depends on the same things it always did review, testing, architectural judgment, and someone in the loop who actually understands what shipped. The tools got faster. The bar for good engineering didn't move.

AI is changing how software gets built. The teams that benefit most won't simply be the ones using the most AI tools, but the ones that know where AI adds value, where human expertise matters, and how to bring the two together responsibly.

For more thoughts on AI, software development, and how the industry is evolving, follow Kilowott on LinkedIn and Instagram.

Top comments (0)