Opinion

The Vibe Coding Hate Is Justified. For All The Wrong Reasons

Vibe coding's critics are loud and vocal about their opinions, and they're right.

Their reasoning, however, is completely wrong.

Ever since the introduction of OpenAI's ChatGPT in November 2022, followed by releases from Meta, Anthropic, and Google for their initial Llama, Claude, and Gemini models in February, March, and December of 2023, respectively, people have been utilizing it in any way they can dream of, which has allowed its adoption to spread quickly within 2 to 3 years of its original release.

These AI models are really useful in helping speed our productivity. Whether it's asking it for home decor ideas, looking for clarification on how to solve a calculus problem via different approaches, or developing a full product without the need to put in the hard work that is usually required for it, it has made a significant impact not just worldwide, but especially in the tech industry.

But that's where the incorrect reasoning starts to form amongst the critics who are pushing a valid point on why vibe coding should not be encouraged.

In February 2025, AI researcher and software engineer Andrej Karpathy described a habit where he utilized AI-generated code, which he attributes to giving into the "vibes" associated with development while forgetting one crucial task: checking the code itself. He connected this to what he labels as "throwaway weekend projects", projects that are made for practice, for fun, or as a prototype for a bigger project.

Karpathy makes a valid argument that vibe coding is harmless if it's isolated and stays within small projects that don't truly go to production to actual consumers. However, what he does not account for is the person who does the actual vibe coding.

There are people in the tech industry who have worked for more than 10+, 20+, 30+ years, and some of them have embraced AI to help speed up the software development lifecycle, especially as projects become more ambitious and have tighter deadlines. Because of their long-term experience, these individuals either consciously or unconsciously use the training they had to gather before the generative AI area to make decisions before utilizing AI-generated code, walking the fine line between risk and reward.

Karpathy is one of those individuals. He has been studying and working in the tech industry for the past 20 years overall. This is shown by his work at Stanford University as a PhD student, becoming one of the founding members of OpenAI in 2015, spending 5 years as the Director of AI at Tesla, briefly returning to OpenAI, and eventually focusing on making YouTube videos, educating his audience about LLMs (large language models).

However, people who have no training and/or experience working in production environments involving multiple users, clients, and/or stakeholders have a higher risk in terms of liability. Of course, the opposite is also true, as experienced individuals could repeat the same patterns as an inexperienced software engineer and vice versa.

For example, between late January 2026 and early February 2026, Moltbook, a Reddit-style social network where AI agents post and chat with other AI agents, had its database completely exposed. According to Wiz.Io's analysis and findings, they found millions of authentication tokens (approximately 1.5 million) and thousands of email addresses (approximately 35,000).

After the Moltbook team patched the exposure within 3 hours of the report being made, the founder, Matt Schlicht, publicly stated on X that he didn't write a single line of code, defending his choice by stating that it was the "golden ages" and that AI should be allowed to prosper.

A second notable instance involving a similar incident as a result of vibe coding occurred back in April 2026. Lovable, a vibe coding platform that allows users, even those that are not in the tech industry, to build production grade full-stack applications using just AI prompts had a breach in their database that was reported by a security researcher going under the pseudonym, @weezerOSINT. They reported to the team that there was a mass data breach that was affecting every project created within their platform before November 2025. It was discovered that as a result, anyone could access the source code of users' projects, and read other sensitive information, such as database credentials. This marked a third major incident in just over a year, with the first occurring from March 2025 to May 2025, and the second occurring in February 2026, which exposed 18,000+ user records pertaining to major institutions such as UC Berkeley and UC Davis, along with K-12 schools who used the software to make exam questions.

Third, this is coming from my own experience as a software developer who has worked with an actual software that has multiple clients, customers, and staff management. Back in September 2025, I was working on this same software for a client, and I was working with a junior developer when an incident occurred that same month. This junior developer was a brilliant up-and-coming software engineer who was on the brink of graduating with his bachelor's degree in computer science. He was ambitious, very smart, and was hungry for getting things done quickly and efficiently.

However, quickly is what cost him in this case.

While I was working on maintaining a module in the software that I was in charge of, I noticed that he was moving too fast and asked him what he was doing. He claimed that he was working on a form for a client, but unfortunately, as much as I hate having to point out his lack of professionalism, his response certainly demonstrated both attitude and hurriedness. While this was happening, I observed that he was using AI to generate code for a change he was making to one of the pages. He made the changes and pushed them to production. However, I realized too late that the changes he made were in the login page file, not the file he was supposed to be working on for the client's form.

After I reviewed his code and realized what he had done, I firmly gave him 15 minutes to fix his error before escalating it to our supervisors. He attempted to push back, but I reiterated my point. He went ahead and got it done within 10 minutes thanks to a backup, but unfortunately, the damage had already been done.

That's when the realization hit me. While typing code forces you to focus on your coding environment, prompting an AI to do it for you will remove that focus entirely. In other words, you can accept a suggestion without verifying the file or directory it was actually included on, especially if you're not familiar with how programming works.

Despite being an up-and-coming software developer who wanted to learn everything he needed to know, the use of AI coding tools, such as Copilot, and Claude had quietly removed the one critical habit that required him checking both the code and the file it's being distributed in before deploying it to production, thus eliminating any safety nets that were remaining at this point. It was not because he stopped caring, but because placing his trust in a tool that a lot of people depend on today made him more relaxed in his approach. In other words, he got too comfortable.

These three examples (the Moltbook breach, the Lovable breach, and my anecdote) all point back to my earlier argument about the person who does the actual vibe coding. If the person using the AI-generated code has experience, they are expected to do a thorough code review to ensure that no vulnerabilities and other bugs arise while simultaneously applying their training to patch them. However, if the person has no experience or very little experience and/or little awareness of how these tools can have a significant impact that can go either way, there is a higher risk for liability and fallout.

That was the case for the junior developer I was mentoring at the time, who departed next month for reasons that were not related to the login page takedown, and for the companies who experienced database breaches or were at high risk for experiencing one.

Which all points to my original argument. Yes, vibe coding is hated for a reason, and I agree that it is justified. Look at the three incidents and the impact they had. Critics say AI and vibe coding make people careless. However, critics are wrong in their reasoning. It's very easy to blame hiring processes, code review culture, and mentorship since this was the norm before AI entered the picture.

But ultimately it was the person's dependency on it that got them too comfortable, and that's what cost them. Comfort is not something that can be afforded when the stakes are high, especially when a product impacts customers not just financially, but also personally.