Why Vibe Coding Feels So Productive
(and how to get back on track when it isn't)
The first time I heard about vibe coding it sounded too good to be true.
If you’re not familiar with vibe coding, basically it’s where you use common English to describe what you want to build, and AI makes it happen. It can handle everything from the design and the code, to the marketing and in-app copy.
I studied business, programming and design at University. I spent years getting better at my craft. Experimenting, learning, practicing.
So the fact that anyone can now create digital products without writing a single line of code is incredible, but at the same time can feel a bit unnerving.
It won’t be as good. I thought confidently to myself. It’s going to lead to poorly designed products, filled with bloated code that crash, go rogue or get hacked.
But one night a few months later, bored and curious, I decided to see what all the fuss was about. I created an account with Replit and within 10 minutes, I recreated an app that I’d spent days building in the past. Hell, the first version looked even better than mine.
Ok I see the appeal, I thought.
Let’s see what else it can do.
And then I spent 2 more hours adding features until I hit the paywall.
But the paywall wasn’t the problem. I’d turned what started as a nice, easy-to-use product, that solved a specific problem, into a Frankenstein monster.
I’d added so much complexity and features, it no longer looked good. And I’d drifted so far from the original goal and problem that the product set out to solve.
Even though I have decades of experience building products, I got caught up in the experience, ignored all my own advice and just kept adding features just to see what it could do.
Why it’s so addictive
Building products used to have friction. You’d have an idea, then spend days, sometimes months, translating it into something that actually worked. There was always a gap between the idea and the thing.
Vibe coding closes that gap almost entirely. You describe something. A few minutes later it’s done.
Your brain does something with this. It interprets “I made a thing” as “this thing is good and worth making.”
Those are not the same conclusion. But in the moment, feeling excited and proud of what you made, they feel the same.
This is a dopamine trap.
And if you’ve ever lost three hours (or three days) tweaking something that didn’t actually make the product better… you know exactly what I mean.
Vibe coding is a powerful tool. I use it. I recommend it.
But the faster you can build, the easier it is to build the wrong thing.
What the trap looks like
You just keep adding new features.
It’s so easy to add features now that it’s easy to fall into the trap of thinking more features = better product.
When I built my journalling app Fern, I spent weeks layering features on top of the MVP. Just one more thing, I kept telling myself.
And then another. And another. Each feature usually took less than an hour to add I thought. What’s the harm? What’s the rush in shipping. I have time.
But then months went past. And I hadn’t gotten feedback from any real users because I was too busy tweaking things for how I might like them. When I finally shipped the app not a single user asked about all those extra features I’d been adding.
You become convinced that your idea is amazing.
But when you look back on it later with some perspective you realise it might not have been as great as it felt in the moment.
Months ago I had what felt like a great idea. A game inspired by two truths one lie. The idea was simple — make staying up-to-date with the news more fun, while at the same time showing people how easy it is to get tricked by AI headlines. You had to pick which was the fake news headline, and see how many rounds you could get through.
I was so excited, I added another domain to my growing collection and got to building. I spent 3 nights polishing it and it was so close to being done. But then I hit a Claude code usage limit and was forced to take a break. Taking a step back made me realise this was much less exciting then I felt in the moment. I never shipped the app.
You love working on it. It feels so good to be creating. To see your ideas come to life. You want to spend as much time as possible building.
So much so that you prioritise it over things that are more important. You find yourself saying things like Sorry honey I can’t play right now mummy has to work. Or when a friend asks you to hang out and you say sorry I’m busy because you just want to work on your project.
You can no longer describe in one sentence what your product does.
You find yourself needing multiple sentences to explain what previously took one. Each feature adds more value you tell yourself, it makes the product better. But it also adds more complexity, not just in the codebase, but also in how you explain your product, and how your customers can understand it.
How to work through it
Vibe coding is great at creating prototypes. To see how your idea feels when you can actually see it, touch it, use it. But I’ve found it’s helpful to set a few guardrails before you get started.
Here are three things I’m doing to help stop myself falling into vibe coding traps:
#1 Have a plan
Plans don’t need to be complicated. The best product briefs are one pagers. The more complicated you make your plan, the less likely you are to read it.
If you’re not sure what to include or where to start, here are seven questions to help you get clear on what you are building, who for and why:
What is the core problem you are trying to solve?
(Go deep- why is this a problem? Why is it important to solve this problem?)
Who does this impact? (Be specific. A real person, not a demographic. What does their day look like? How much pain does this actually cause them?)
Will they change their behaviour? (Is it a painful enough problem that they are looking for a solution and will change their behaviour? Will they actually use your product?)
What would an MVP (Minimum Viable Product) look like? (If you only had 2 days to build this, what features would you include?)
Why am I building this? (Your personal why. Is it to make money? To learn? To have fun? Something else? Why you?)
What makes my product / solution different to what else is on the market? (Do some quick competitive research to see what else is on the market, and get clear on what makes your offer different)
What does success look like? (How will you know if it was successful? Revenue? Users? Something else?).
Pro tip: Plans are worthless if you don’t refer back to them. It’s easy to create a plan and not look at it again. To help hold yourself accountable, add your project plan and MVP feature list to your claude.md instructions file and add a line like this:
This is my project plan and MVP features list. If I ask you to create a feature that isn’t outlined here, before you start building it prompt me with some questions to validate if this is actually important and should be added to the plan, or if I’m getting distracted.#2 Timebox it
Get clear upfront how long you want to put into this idea. Here’s an example of what that might look like:
1-2 hours to build a quick prototype using a tool like replit or lovable to do some early exploration and see if this is something you might want to build.
1-2 hours to create the project plan
1-2 days to build the MVP
#3 Get real customer feedback before expanding past your MVP
An MVP (Minimum Viable Product) should be quick to build and create. You’d be surprised how many successful products that are now valued at billions of dollars, were built and launched in a single weekend.
Real customer feedback helps you see things that you otherwise would have missed. It helps validate if your assumptions are correct. Will people actually change their behaviour and use your product? Are you building the right thing?
The only way to know is to get real customer feedback.
Feeling productive ≠ building something valuable
Just because it feels good to make something, doesn’t mean it’s a good thing.
Vibe coding can be addictive. It’s easy to get swept away in it. Thinking you are working on the right things.
It makes building feel easy.
And sometimes it makes the wrong things feel worth building.
Not every project has to make money. Sometimes building for fun or to learn can be even more valuable.
But be honest with yourself and know the difference.
You don’t need to have everything planned out.
But a little upfront planning can be the difference between spending months chasing an idea, and actually making something that matters.
I’m curious… have you experienced this? what’s something you built that felt amazing at the time… but later you realised maybe wasn’t worth building?
Leave a comment, I’d love to hear about it!
Claude Code is wonderful but agree it also enables feature creep! 😂 I usually create a separate experimental git branch where I can try out experimental features without breaking my working app!
This is the first article I've read about the addictive nature of vibe coding. It's something I've really felt. Thanks for sharing.