Is Vibe Coding Bad? I Wrote 150,000 Lines in a Weekend. My Dev Kept 17,000.

Last weekend I let Claude Code run from Saturday morning to Sunday night. By Monday I had about 150,000 lines of backend code for a new internal assistant at CloseBot, which I co-founded, and an apology ready for Brendan, our senior backend developer.

“Brendan, I’m sorry. But how hard would this be to get into prod?”

He didn’t get angry, at least not on the outside. He scrolled for a bit and said something like: okay, it touched this file, and nothing should ever touch this file. Then: this will add about $1,000 a month to our hosting bill, and it didn’t have to.

By the time he was done, my 150,000 lines had become about 17,000. So is vibe coding bad? I don’t think so. But that weekend was a pretty good argument for why it can be, and I want to be honest about both sides.

The first time I didn’t know

I’m a self-taught developer. I built CloseBot V1 myself, in Python, and I was proud of it. Then one day while I was in Arizona, our database hit 100% CPU.

Customers were messaging me asking why their bots weren’t responding. I’d broken things before, but never with other people’s income riding on it. And for the first time, I genuinely didn’t know what to do. A fix might take me an hour, a day, or a week. I had no way to tell.

So I called Brendan. His first question was whether I had proper indexes in place. I told him the ID column was indexed. He said, “Oh boy.”

We had it fixed very quickly. I may or may not have been crying beforehand. What stuck with me was how calm he was about something that felt like the end of the world to me. It’s the difference between knowing the system and hoping the system works.

One sentence, $1,000 a month

The expensive mistake from my weekend came from a single line I typed early Saturday morning: make sure these are separate from the messages happening in production.

What I meant was simple. Don’t let this new assistant take down the live system that answers our customers’ leads. What the AI heard was “separate,” so it built a completely separate project on a completely separate server. On Azure, with the compliance and HIPAA requirements we carry, that server would have run about $1,000 a month to handle a sliver of the traffic our main system does.

I didn’t catch it, because I didn’t know to look. Then the AI spent the next 36 hours building on top of that decision. Every line after it assumed it was right.

That’s the part of vibe coding nobody warns you about. The AI doesn’t know what you meant, only what you typed. It takes your words literally and runs with them for a whole weekend.

What my senior dev sees that I can’t

We turned that review into a live fireside chat, because I’d been meaning to sit down and learn this stuff from Brendan anyway. A few things he said have changed how I work:

• AI is bad at infrastructure because the good examples are private. It learns mostly from public code, and the companies with serious infrastructure don’t publish theirs.
• AI will make the tests pass, whatever it takes. It’s built to hit the target you give it. Passing tests prove it hit the target, not that the code is good.
• Past about 50,000 lines, it loses the plot. The model can’t hold the whole project in context, so it copies whatever patterns it sees. Give it one great example and it copies that. Give it a mess and it copies the mess.
• You can’t prompt your way to security. “Use security best practices, make no mistakes” doesn’t work. The AI doesn’t know which of your endpoints should be public unless you tell it, and mine had documented some that shouldn’t have been.
• Ask it to find problems and it always will. I asked it to audit our SEO once. Its top recommendation would have redirected a pile of junk backlinks onto our main site. I only caught it because I asked a follow-up question.

I wrote up Brendan’s full technical breakdown on the CloseBot blog: languages, security, refactoring, all of it. If you’re shipping real code, read the vibe coding best practices guide there. This post is about the part I’m still working on: me.

Letting go of writing code

I stopped hand-writing code about a year and a half ago, when we stopped working on V1. V2 is written in C# and .NET, a language I’ve never written. It’s been even longer since I touched front-end code. These days, if I’m honest, I don’t understand our codebase anymore.

I loved writing code, and letting it go felt a lot like mourning. The fact that I’d have to learn a whole new language to keep up made it easier, but only a little.

What I’ve had to learn instead is how to fit into a team without making their lives hell. Here’s the uncomfortable truth: writing code is fun, and reviewing code sucks. With AI, I can produce code much faster than any team can review it. That weekend, I did not do a good job of respecting that.

Brendan said it kindly on the call: I’m a visual person, and I don’t do technical documentation. A working prototype is how I get what’s in my head to the team. That’s valuable. But I try so hard to be specific and ask good questions, and I still butcher it sometimes.

How I vibe code now

The biggest shift is treating vibe coding as a Figma replacement, not a senior developer replacement. We used to spend hours in Figma mocking up screens. Now it’s usually faster for me to vibe code an interactive version that should never ship but shows exactly what I want. These are the rules I’m trying to live by:

1. My code is a spec, not a pull request. I hand it over with full permission to scrap every line.
2. No more “it works, let’s ship it tomorrow.” If the team looks at it, says “that’s cute,” and rewrites it over two weeks, that’s the system working.
3. Constraints go in first. Cost, hosting, and what must never be touched get stated before the AI writes a line, because one vague sentence can steer a whole weekend.
4. Smaller pieces, even when the pieces are big. Each part of our analytics launch was roughly 10,000 lines on its own. Breaking things down doesn’t make them small, but it makes them reviewable.
5. Own what we build. I’d rather build in Claude Code or Cursor than host a business on a one-click app platform that can raise its price whenever it wants.
6. Keep the person who knows the system in the loop. The Arizona outage taught me that once. The 150,000 line weekend taught me again.

So, is vibe coding bad?

No. Vibe coding is bad when it’s the last step. It’s great when it’s the first one.

It lets someone like me, a founder who no longer reads the production language, turn an idea into something real people can click on in a weekend. That used to take weeks of mockups and meetings. It’s also a terrible way to put code into production when nobody who understands the infrastructure, the security, and the architecture is checking it.

The tool isn’t the problem. The problem is believing the AI made the decisions an engineer should make. Mine made a $1,000-a-month decision off one sentence, and I would never have known without Brendan.

If you’re a founder vibe coding your way into a real product, find your Brendan. And when you hand them 150,000 lines on a Monday morning, bring an apology.

Watch the full fireside chat with Brendan on YouTube, and read the technical breakdown in vibe coding best practices from a senior developer.