Things I Wish I Knew Before Vibe Coding

3 months ago 1

If you follow us on X or LinkedIn, you may have seen we’re deep into vibe coding.  Specifically, trying to build basic B2B apps — for real — using the leading vibe coding platforms like Loveable, Replit, Bolt.new, etc.

After being deep into vibe coding a some complex (but not super complex) B2B product for the SaaStr community, I’ve already learned a lot.

These platforms are very cool, but super quirky.  The “AI agents” that build the apps are so powerful but they are also … unpredictable.  And they get more and more unpredictable the deeper you get into a project.  That’s what you need to learn.

Here are the 10 things I wish I knew before I started.

1. The AI Agent Will Often Be Wrong. Deal With It.

AI agents are wrong 30-40% of the time on anything complex. API integrations, edge cases, architectural decisions — they’ll give you confident-sounding answers that are just wrong.

What to do: Always ask for multiple approaches. “Give me three ways to build this algorithm” became my default. Push back on suggestions that don’t sound right.  And if it said it’s done something — verify that it actually has.  Don’t move on.

Stop treating AI suggestions like they are … right. They’re hypotheses to test.

2. Slow It Down. Work on Small Pieces.

Vibe coding feels fast, so you want to keep going. “Add payments! Add user roles! Add notifications!” This is a trap.

I tried to build an entire dashboard in one conversation. I ended 200 lines of code that technically worked but was impossible to debug or extend.  And nothing on it really worked.

What works: 15-20 minute focused sprints. Build one thing, test it, move to the next. If it takes more than 30 minutes to build and test, it’s too complicated.  Even any feature that takes longer than a few minutes to build is likely too complicated. Break it down further.

3. The Agent Will Change Stuff Without Asking. Accept It.

Your code will constantly evolve. Variable names will frustratingly change. Functions get refactored. Architecture shifts.  Without you ever asking or even knowing.

At first, it will be funny.  You’ll log back in, and your app wlll have … changed.  You’ll just fix it.  But then as you go further and further into a project, it’s less funny.  Because as you go deeper into any project with any level of complexity, there will be so many moving pieces in flux.  This is why so many folks abandon their vibe coding project 70% of the way in.  At that phase, it’s now changing way too many things you thought were done or more likely, close to done.  You just have to learn to work around this.

Vibe coding may well be slower and less efficient than normal coding after you are about 70% of the way in.  But if you aren’t a coder, you just need to live with that.

Reality check: As long as functionality works and tests pass, let it evolve. The AI often improves code in ways you wouldn’t think of.  If it’s done enough, don’t touch it again.

4. Don’t Ask More Than Twice. Start Fresh Instead.

The pattern I see constantly, and that I’ve been ‘guilty’ of, even again today: You ask the AI agent to fix a bug.  The fix doesn’t work. You ask again. It still doesn’t work. So you ask a third time… and it starts to go off the rails.  Deleting things.  Making up test results.  Inserting “demo” user data that hides the fact the function just doesn’t work.

Stop. Don’t ask an AI agent 3 times to fix something — ever.  The context window gets polluted with failed attempts. The AI builds on false assumptions.  No matter what, it’s just not going to work if you have to ask the AI prompt 3 times.  You’ll end up in a sea of endless bugs you can’t fix.

Rule: Never ask the same agent to solve the same problem more than twice. Start a new conversation. Describe the problem from scratch.  Approach it in a simpler way, if possible.

5. Some Stuff Is Harder Than It Looks. Plan Accordingly.

Email integration, OAuth, payments — they look simple until you hit SPF records, refresh tokens, and webhook validation.  A lot of this stuff just doesn’t work reliably today.  Not unless you get close to getting into the code youself.  The AI will give you a basic implementation that works in dev but fails in production.

I actually don’t have all the answers here other than be aware many things that seem to work won’t actually work.  And use the ‘hardpoints’ in your vibe coding platform.  Use their authentication, their database, their core choice for email, everything core you can vs. writing your own.

The platform I’ve used most desperately wants to use Sendgrid for email for example, by default.  Every time I lock down Resend instead, it fights me.  One way or another.  Giving up and using the default vendor it wants to use (Sendgrid) is the right choice of 95% of us.

Budget accordingly: Anything involving external systems takes 3-5x longer than the AI estimates. Build the simplest, happy path first, then iterate on edge cases.  Use the default “hard points” like OAUTH, email, etc. that the vibe platform provides.  Don’t import your own unless you are 100% sure you really need to.

6. Don’t Build an App That’s Hard to Test

When you’re moving fast, you skip testing. “I’ll just click through it.” This doesn’t scale.  Not even past a few days of vibe coding.

By hour 20 or so, you’ll spend more time testing than building.

Solution: Design for testing from day one.   Unit tests, API testing, reusable test data, easy rollbacks. I spend 60% of time on testing infrastructure, 40% building features.  40% max.

@garrytan talked about getting rid of P2 bugs after every few sprints. Before you build more features.

The thing is in vibe coding, you can do a sprint … in 17 minutes.

And it's so, so tempting to build new features.

So it's so easy to skip over the P2 bugs, or…

— Jason ✨👾SaaStr.Ai✨ Lemkin (@jasonlk) July 25, 2025

7. Just Roll Back. Don’t Try to Fix Everything.

When you introduce a bug, resist the urge to debug in place. Instead ask youself: “Should I just roll back?”

Vibe coding platforms are really, really good at rolling back.  And they automatically make save points, just like video games.  So before you debug something that isn’t working, ask yourself if instead you should just … roll back.  Get used to rolling back multiple times a session.  It works elegantly, so take advantage.

Strategy:  When your gut tells you something isn’t going to get fixed, just roll back.  RIght then and there.  When something breaks, you always have a recent checkpoint.

8. Accept Your App Will Never Be 100% Stable Until Production.  And Probably Not After That If You Keep Vibe Coding It.

This a tough one and one I didn’t fully get at first.  AI will keep suggesting “improvements” that introduce bugs. Features that worked yesterday break today.  The further you go down a path with any complex app, the more this compounds.  If your app is too complex, honestly, it will never be stable.  If it changes 1-2 things per session, you can work around that.  20?  It’s hopeless.

I used to try for 100% stability.  These platforms are evolving and we may get there.  But it’s not practical, let alone possible, today.  Your AI Agent will just keep changing things.

Reality: Launch at 80% stability when the core user journey works. Real user feedback beats perfect code.  And make the app as simple as possible.  Complex apps are not ready for prosumer vibe coding yet.  Not really.

9. You May Want to Just Plan to Rebuild Entire Pages of Your App.  Probably All of Then.

Sometimes it’s faster to rebuild from scratch than debug existing code.  Because AI agents generate code quickly, rebuilding often takes less time than debugging complex issues.  Don’t fear rewriting every single page of your app.

When to rebuild: If you’ve been debugging the same component for over an hour, start fresh. Ask the AI to build a “v2” of your page and see where it takes you.  Preserve the v1 in case it doesn’t go where you want.

10. A Lot of Stuff That Looks Like It Works at First Glance … Won’t

Code that looks perfect has subtle issues that only surface under specific conditions.  Lots of functions and buttons and workflows that look like they work … won’t.  Your app will load with demo data in dashboards and algorithms that are “simulated”.  To make them look like they work.

You’ll become frighteningly good at breaking your own app. You’ll need to be.  It will be job #1.  And you’ll need to get great at seeing anything that looks wrong.  It was probably made up.

Vibe Coding Day 12,

Maybe the final thread here. I spent 100 hours building a commercial-grade app with vibe coding.

Some observations from the experience. My top 13 learnings to help you — vibe code your own one.

A thread🧵

— Jason ✨👾SaaStr.Ai✨ Lemkin (@jasonlk) July 21, 2025


Summary

Vibe coding is magical but it isn’t magic. It’s a tool that changes how you build products — more iterative, faster feedback loops, different skill requirements.  But it’s early.

Finally, a big topic I’ll do a deep dive on later sn security.  The more your app stores any sort of customer information, practically speaking, the more important this is.  And the more risky using a vibe coding tool on its own is.  This will get its own stand-alone post soon.  For now, be cautious if your app stories any confidential or customer information and is public facing.

And another great summary here from Sr Director of AI products at Pendo:

Read Entire Article