Vibe Coding: The Risks of Relying on AI for Programming

Explore the implications of Vibe Coding, highlighting the potential pitfalls of using AI tools for coding without proper review.

Introduction

Last week, I helped a friend debug a project he wrote using Cursor. The combined frontend and backend had about twenty thousand lines of code. It looked decent when running, but upon reviewing the code, I was shocked— the same API request logic was copied and pasted four times, database connections were never closed, and environment variables were hardcoded.

Image 2

I asked him if he had reviewed the code. He replied, “No, as long as it works, it’s fine. Isn’t that Vibe Coding?” I immediately sensed something was off.

What is Vibe Coding?

To provide some background, the term “Vibe Coding” was coined by Andrej Karpathy in a tweet last February. The gist of it was: you just describe your requirements in natural language, and AI helps you write code without needing to review it line by line—just go with the flow.

This half-joking remark was later recognized by Collins Dictionary as the word of the year for 2025. By early this year, about 85% of developers were using AI programming tools in their daily work.

Honestly, I use them myself—every day. I alternate between Cursor and Claude Code, and my coding efficiency has indeed improved significantly.

However, recent data made me rethink the idea of “going with the flow.”

The Data That Kept Me Up at Night

In December last year, the code review platform CodeRabbit conducted a solid study. They analyzed PRs from 470 open-source projects on GitHub, comparing code written with AI assistance to that written entirely by humans.

The results were alarming:

  • AI code had 1.7 times more major issues than human-written code.
  • Configuration errors were 75% more frequent.
  • Security vulnerabilities were 2.74 times more common.

2.74 times more security vulnerabilities. Just think about that number.

Moreover, Alibaba recently released a benchmark called SWE-CI, which tested AI agents maintaining code in real projects (not just solving isolated problems). They found that 75% of models would unintentionally break previously functioning features while modifying the code.

Two independent studies pointed to the same conclusion: AI writes code quickly, but the quality of that code has systematic flaws.

This doesn’t mean AI is unusable; it means you cannot use it casually.

How Are Current Tools Performing?

Objectively, the evolution of tools is indeed rapid. Let me discuss a few that I have used.

Cursor is currently the most widely used tool. Its strength lies in its ability to understand your entire project, not just the current file. It performs well in making cross-file code changes while maintaining consistent style.

However, it has a drawback—it’s too “helpful.” Sometimes, it’s not immediately obvious what changes it has made. You need to carefully review the diffs; otherwise, you might end up like my friend, with code that runs but is fraught with hidden risks.

Claude Code operates differently. It runs directly in the terminal; you describe a task, and it reads, modifies, and tests the code on its own. It feels more like hiring a programmer while you act as the project manager.

Recent updates have added MCP integration (directly connecting to databases and Jira) and parallel sessions (using Git Worktree for isolation, allowing multiple tasks to run simultaneously), significantly enhancing its practicality.

Replit Agent is suitable for non-programmers. You can say a sentence in the browser, and it helps you build an app from scratch. It’s great for prototyping, but I wouldn’t recommend using it for production systems.

Lessons Learned from My Experiences

After using AI programming tools for over half a year, I’d like to share some real lessons.

The Costliest Lesson: Letting AI “Run Wild”

Once, I asked Claude Code to refactor a file parsing module with just a one-sentence description. It did refactor it, and the code looked nice. However, it “conveniently” changed the function signature, causing three other modules to fail.

The CI ran for twenty minutes before everything broke. Rolling back took even longer because the changes were scattered across seven or eight files.

Since then, I’ve learned my lesson: always let AI make small changes, run tests, and then proceed. Don’t let it touch too much at once.

The Importance of Code Review

Why were CodeRabbit’s findings so bleak? I believe the core reason is simple: most people are not seriously reviewing the code written by AI.

When humans write code, every line is generally well thought out (at least most of the time). With AI-generated code, you only “glance” at it, but “looking” and “understanding” are two different things.

My current approach is to treat AI as a fast outputter with limited experience, akin to a junior developer. While it can produce code quickly, each line needs to be vetted by a senior developer. What boundary cases were overlooked? Which variable names are ambiguous? What logic seems correct but could fail if the conditions change?

These are things that AI won’t proactively inform you about.

The Quality of Prompts Directly Affects Output

For the same task, saying “help me write a user management system” versus “write a REST API using Express that includes registration and login endpoints, with passwords hashed using bcrypt, JWT expiration set to 2 hours, and errors returned in the format {code, message}” results in vastly different outputs.

Now, I have a habit of writing prompts: first stating constraints (technology stack, what not to use), then the functionality, and finally providing an example of input and output. I also make sure to say, “do not add any features I haven’t mentioned,” as AI tends to over-design.

Git is Your Lifesaver

This point cannot be emphasized enough. Commit after every small step. Did AI break something? Just revert the git commit.

I once forgot to commit and let AI modify over ten files continuously. When I realized the direction was wrong halfway through, I couldn’t go back. That feeling was more despairing than not using AI at all.

Conclusion

Vibe Coding is not a choice; it’s a trend. You have to use it whether you want to or not.

However, “vibing” doesn’t mean being careless. The reality in 2026 is that tools are powerful enough to save you a lot of time, but not strong enough for you to trust them blindly.

Have you ever seen a good tech lead who just “goes with the flow”?

Code reviews, automated testing, and incremental commits—these “old-school” engineering practices are more important than ever in the age of AI programming. Because AI produces code several times faster than humans, if your quality checks can’t keep up, bugs will accumulate at an alarming rate.

Ultimately, knowing how to use AI for coding is just the beginning. The real valuable skill is being able to judge whether the AI’s output is correct.

When Karpathy mentioned Vibe Coding, he could understand every line of code himself.

Was this helpful?

Likes and saves are stored in your browser on this device only (local storage) and are not uploaded to our servers.

Comments

Discussion is powered by Giscus (GitHub Discussions). Add repo, repoID, category, and categoryID under [params.comments.giscus] in hugo.toml using the values from the Giscus setup tool.