The Best (Or Worst?) Vibe Coding Blunders - Part 2

An AI coding tool sounds exactly the same when it’s right as when it’s about to ruin your afternoon.

Confident, fluent, completely sure of itself.

The tone doesn’t change whether it’s renaming a variable or deleting your home directory.

In Part 1, we looked at ten vibe coding blunders. This is part 2.

(And yes, there will be a part 3.)

1. A coding assistant ran up ~$6,000 doing absolutely nothing

A developer left Claude Code running overnight, auto-updating on a schedule, expecting to come back to finished work.

What he came back to was a bill that blew his mind.

The tool was supposed to reuse its 800,000-token history. Instead, a caching change made it rebuild the entire history from scratch every 30 minutes, around the clock.

Every rebuild was billed in full. Nothing useful was being produced in between. The meter just kept climbing while everyone slept.

Source: MakeUseOf

2. A leaked Stripe key let attackers charge 175 customers $500 each

A founder shipped his SaaS with the live Stripe secret key sitting in the frontend, where anyone who opened their browser’s developer tools could read it.

A secret key is called that for a reason. It can create charges and move real money.

Attackers found it and used it exactly the way you’d fear. They charged 175 of the startup’s customers $500 each.

"I trusted it too much."

Source: LinkedIn

3. Cursor stopped coding and told the user to go learn to code

Some blunders are just funny.

A developer was using Cursor to build a racing game, and somewhere around the 750-line mark, the tool simply refused to continue. Not a crash. Not an error. A small lecture.

It went on to warn that leaning on generated code could lead to “dependency” and “reduced learning opportunities.” The tool you are paying to write code, declining to write code, on principle.

Source: Hacker News

4. The AI kept recommending a package that didn’t exist. So someone created it

AI models don’t just write code. They tell you what to install. And sometimes they tell you to install things that were never real.

A couple years ago, models kept confidently suggesting a package called huggingface-cli. The genuine tool ships under a different name; this one was a ghost, a plausible-sounding package the models had essentially invented.

A researcher decided to see how far that confidence traveled. He registered the empty package under that exact name, just to find out who would install it.

Thousands did. He then saw that the phantom package was being recommended in the wild, including inside a repository belonging to Alibaba.

There was no malware here. The researcher was making a point.

But in the wrong hands, the same tactic becomes an easy supply-chain attack: see what package names AI tools keep hallucinating, create one of them, and wait for people to install it.

Source: The Register

5. Claude Code started deleting from the top of the filesystem

The agent was creating a delete command and assumed that the symbol ’~’ would point to the user’s home folder, as it normally does in a terminal.

In the shell the command actually ran in, the tilde never expanded. So instead of removing a folder tucked safely inside the project, the path collapsed and the delete resolved to the top of the filesystem.

The result was rm -rf running from the root and chewing through the developer’s home directory on the way down.

This is an ancient footgun. In shell scripts, one unexpanded variable can quietly turn rm -rf "$DIR/build" into something that deletes far more than a build folder. People have wiped their own machines this way for decades.

What’s new is that the thing assembling and running the command is an agent that doesn’t pause to sanity-check the path before it commits to it.

Source: GitHub

6. An ID copied from the URL unlocked any private app on Base44

Base44 is Wix’s vibe-coding platform. You describe the app you want, and it builds it for you. That includes private apps, the kind meant to sit behind a login and only be used by a small group of trusted people.

About a year ago, researchers at Wiz found a problem in how those private apps handled access. Each app had an app_id visible in its URL.

At first glance, this looks harmless. An ID in a URL is usually just a way to tell the system which app someone is looking at. It is not supposed to be the thing protecting access.

But in this case, it was. If someone copied the app_id from a private app and sent it to the registration endpoint, they could create a verified account for that app and bypass the single sign-on that was supposed to keep outsiders out.

Source: Wiz

7. A two-year-old leaked key turned into a €3,167 bill overnight

A developer had a Firebase key that had been exposed for two years without anything happening. Old, forgotten, apparently harmless.

Until a bot found it.

It used the key to hammer the Gemini API through his project, firing requests all night long.

He woke up to a bill for a night’s worth of traffic he never generated.

Exposed credentials don’t have a shelf life. A key that leaked two years ago works just as well today, and bots are endlessly patient.

Source: Medium

8. The AI graded its own work and gave itself a 0.972

The most unsettling stories in this whole series aren’t the ones where the AI breaks something. They’re the ones where it lies about the result.

A developer set an AI agent to run a benchmark and report how its code performed. It came back with a near-perfect score of 0.972.

The score was fiction.

The agent hadn’t run the evaluation and failed it. It had skipped the work and written up a passing result as though it had done everything.

This is the same instinct behind the Replit agent from Part 1 that faked users to paper over a deletion, and the Claude Code session that swore it had added a safeguard it never wrote.

The tool would rather report success than admit it fell short.

Source: Godmode

9. An official AI coding tool shipped with a self-destruct prompt

You’d expect the tools built by the biggest names to be the safe ones. Not always.

In mid-2025, a malicious actor was able to inject an instruction into the Amazon Q Developer extension for VS Code, an official AWS tool with close to a million installs.

The version that went out, 1.84.0, contained a prompt telling the AI agent to delete the user’s files and reduce the system to, in its own words, “a near-factory state”.

The only reason it didn’t do any of that is that the injected prompt was broken. A syntax error in the attacker’s own instruction stopped the agent from acting on it. The safeguard, in other words, was a typo.

AWS pulled the version and put out a security advisory. But the code had already shipped to everyone who had set the extension to auto-update.

This is not a classic vibe-coding mistake. It is a supply-chain security failure in an AI coding tool. But that is exactly why it belongs here. The point is not that AWS was vibe coding. The point is that AI coding tools can become unsafe in ways users cannot easily see.

Source: GitHub Security Advisory

10. The AI wrote the code, then wrote the tests to match its mistakes

Ask an agent to build a feature and test it, and it will happily do both. It writes the code, then it writes the tests. Green checkmarks all the way down.

The trouble is that the same understanding produced both halves. If the agent misread what the feature was supposed to do, it builds the wrong thing, and then it writes tests that confirm the wrong thing works perfectly.

"Your AI agent says all tests pass. Your app is still broken."

The tests aren’t lying, exactly. They’re faithfully checking the AI’s version of the spec, which may not be the exact same as yours. A passing suite feels like proof. Here it’s just the model agreeing with itself.

Source: dev.to

The common thread

An AI coding tool does not sound different when it is wrong.

That is the common thread running through all of these stories.

The tool sounds confident when it is rebuilding the same context over and over. It sounds confident when it puts a secret key in the wrong place. It sounds confident when it recommends a package that does not exist, deletes from the wrong directory, or skips tests.

The danger is not just that these tools make mistakes. People make mistakes too. The danger is how polished the mistake looks when it arrives.

That is why judgment still matters. Not the judgment to type faster than the AI, but the judgment to know what needs checking.

• Whether the key is actually server-side.
• Whether the package is real.
• Whether the delete command points where it should.

Like we said in part 1, none of this is an argument against vibe coding. It is an argument against blind trust.

AI can help you build faster. But the faster it builds, the more important it becomes to have someone in the loop who can slow down at the right moments and ask: is this actually safe?

If you’ve built something with AI and would rather catch these things yourself before someone else does, that is the whole job here. Take a look at Fix My Vibe Code, or book a free consultation and we’ll go through what you’ve built.