Live data from Hacker News

The "Vibe Coding" Wall of Shame

crackr.dev

41–50 of 88 posts

Re: The "Vibe Coding" Wall of Shame

#41
post #7

For CVE-2026-0755, that's a vulnerability in gemini-mcp-tool. gemini-mcp-tool's Github repo says "This is an unofficial, third-party tool and is not affiliated with, endorsed, or sponsored by Google." but this list shows the Google logo next to the vulnerability. Also, it's not entirely obvious to me that the vulnerability was introduced by vibe coding. https://github.com/jamubc/gemini-mcp-tool Disclosure: I work at…

>Also, it's not entirely obvious to me that the vulnerability was introduced by vibe coding. IDK why people act as if vibe coding invented software bugs that lead to vulnerabilities, as if those weren't already a thing by human programmers.

The same reason some use crime committed by illegal immigrants to push action, while ignoring the fact that citizens are more likely percentage-wise to commit those same crimes. It's confirmation bias at the least, and intellectual dishonesty at the worst, but either way, they want their worldview to be validated.

Re: The "Vibe Coding" Wall of Shame

#42
post #35

Earlier quoted context omitted.

No, I mean everything. It's not reasonable to suggest that AI is only going to repeat older patterns that have been trodden before, or 'things that don't matter'. AI will be writing most new code, by far. Without even getting into complicated arguments about 'creativity' - the AI is an encyclopedia of best practices, and can think a couple of steps ahead for most things you'll ever want to do. Like pro chess players…

Goodluck

People riding horses in the age of automobiles are the one's who need 'luck'.

Re: The "Vibe Coding" Wall of Shame

#43
post #28
post #7

For CVE-2026-0755, that's a vulnerability in gemini-mcp-tool. gemini-mcp-tool's Github repo says "This is an unofficial, third-party tool and is not affiliated with, endorsed, or sponsored by Google." but this list shows the Google logo next to the vulnerability. Also, it's not entirely obvious to me that the vulnerability was introduced by vibe coding. https://github.com/jamubc/gemini-mcp-tool Disclosure: I work at…

The first link claims the 6-hour outage wiped 99% of order volume. I went to the "source" and found an (AI generated?) ad by a company that wants to sell a product, where I cannot find the 99% number. This whole website and everything around it are almost ironic.

Yea, I was about to comment the same thing. I have noticed a lot of people weaponizing people's hatred of AI/slop and using rage baiting to drive views. No doubt someone would have looked at that entry of "Amazon lost 6M orders due to slop!" at face value and come away thinking it was true.

Re: The "Vibe Coding" Wall of Shame

#44

Is this meaningful at all, without a control? How often does software fail in production with human-written code? How many times has a production failure been avoided because an LLM didn't make a typo or mistake that a human would have? This is pushing an agenda. It's not measuring anything meaningful.

A control? This is just a list of incidents, not an experiment.

Re: The "Vibe Coding" Wall of Shame

#45
post #12

Why is the LiteLLM incident on there? The linked article for that one is a 404. I didn't read any credible arguments suggesting that was caused by vibe coding. They had their PyPI publishing credentials stolen thanks to an attack against a CI tool they were using. Plus the linked article for the Amazon outage is https://d3security.com/blog/amazon-lost-6-million-orders-vib... which appears to be some other vendor prom…

> Why is the LiteLLM incident on there? The linked article for that one is a 404.

-> [Endor Labs] https://www.endorlabs.com/learn/teampcp-isnt-done

-> On March 24, 2026, Endor Labs identified that litellm versions 1.82.7 and 1.82.8 on PyPI contain malicious code not present in the upstream GitHub repository. litellm is a widely used open source library with over 95 million month downloads. It lets developers route requests across LLM providers through a single API.

Re: The "Vibe Coding" Wall of Shame

#46
post #39
post #13

I kind of think that the "Human Coding" Wall of Shame would be quite a bit larger and contain examples that are every bit as egregious.

I don’t think that’s the point of showcasing these issues. The specific point is that you cannot prompt your way to reliable software (AKA vibe coding). Just as you cannot reach the same goal by glueing together stackoverflow snippets without understanding them.

I understand that, but the interesting bit is to compare how it performs relative to the average human coder. We can point out specific flaws for eternity, but if it makes 1% fewer mistakes or allows humans to code faster without increasing the number average number of mistakes, then I'd say that that's still providing value. I feel like just enumerating different mistakes that it's made is sort of biased against it because it leaves out a comparison to the alternative.

Sort of like showing off self-driving car crashes. You can spend all day listing the crashes and showing people how it has problems, but if it's statistically safer than the average driver it would save thousands of lives per year to deploy it anyway even if it's not perfect.

Re: The "Vibe Coding" Wall of Shame

#47

Is this meaningful at all, without a control? How often does software fail in production with human-written code? How many times has a production failure been avoided because an LLM didn't make a typo or mistake that a human would have? This is pushing an agenda. It's not measuring anything meaningful.

A control? This is just a list of incidents, not an experiment.

The "Why this matters" section at the bottom is clearly drawing conclusions as if it were an experiment.

Re: The "Vibe Coding" Wall of Shame

#48

Earlier quoted context omitted.

>Also, it's not entirely obvious to me that the vulnerability was introduced by vibe coding. IDK why people act as if vibe coding invented software bugs that lead to vulnerabilities, as if those weren't already a thing by human programmers.

The same reason some use crime committed by illegal immigrants to push action, while ignoring the fact that citizens are more likely percentage-wise to commit those same crimes. It's confirmation bias at the least, and intellectual dishonesty at the worst, but either way, they want their worldview to be validated.

I know this is extremely off topic, but illegal immigrants are far more likely to commit crimes than citizens, not that this has anything to do with software bugs...

Re: The "Vibe Coding" Wall of Shame

#49
post #22

AI might have been an opportunity to take engineer hubris down a knotch. Perhaps to reassess the excesses (bad performance, bad UX, poor reliability, costly development & operations, etc) . Instead of reflection, we decided to shame AI as vibe coding . How much abysmal code and products have we all shipped? Exploitative, clumsy , dangerous, vulnerable? What was our excuse? I find the entire anti-vibe coding movement…

> How much abysmal code and products have we all shipped? > We should be using it to fix all of the terrible software we’ve made over the past 20 years. Instead there are 2-3 camps. People building stuff, people hyping AI and people shaming the first 2. This seems like an odd take. The pro who are using and hyping AI are not fixing all of the crap we put out the last 20 years. They are putting the gas pedal on the am…

I am currently wrestling a vibe-coded codebase into a shippable state and we should call these tools out for what they actually are - technical debt generators.

Re: The "Vibe Coding" Wall of Shame

#50
post #35

Earlier quoted context omitted.

Goodluck

People riding horses in the age of automobiles are the one's who need 'luck'.

The key to this argument is that we won’t need to rely on Anthropic/OpenAI soon — will they exist in the same way they do today in 12-18 months? The “open” models are getting better and better, and people are figuring out ways to make inference run on lesser hardware. It already might be viable for people that don’t expect “instantaneous” and are doing more hybrid development.

But you’re also never going to convince the people who still only run vi on the Linux console, without Xorg…

Post reply on HN