I manage mobile engineering teams for a living. I review architecture, push back on scope, and know when someone's over-engineering something. I've shipped production apps to millions of users. So when I decided to build a side project using AI, I assumed the hard part would be deciding which shortcuts to take.
I was wrong about what the hard part would be.
The problem I wanted to solve
Every shopping app gives you a flat list. You add items in whatever order you think of them, then wander the store like you're solving a maze. Back to dairy because you forgot it was next to the eggs. Back to produce because it was at the top of the list, but physically at the other end of the store.
I wanted a list that follows the route you actually walk, aisle by aisle. You define your store layout once, and from that point on, every list you create sorts itself to match it. Check off an aisle, move on, never backtrack.
Simple idea. I'd thought about it for some time. I knew exactly what I wanted to build.
Or so I thought.
So I opened Claude and asked it to build
I described the concept, hit send, and watched it generate something at a speed that still catches me off guard, no matter how many times I see it.
It built something. Fast. Impressively fast.
And I stared at it and thought: this isn't it.
Not because the code was wrong. The code was fine. It was because I'd never actually decided what "it" was. I had been carrying a blurry vision in my head for some time and mistaking it for a plan.
The questions I never asked myself
"A shopping list organized by aisle" sounds like a complete idea. It isn't. The moment something is running in front of you, questions appear that you never consciously asked yourself:
- What happens when you add an item with no aisle assigned yet? Does it go to a catch-all section at the bottom, block you until you assign one, or silently wait?
- What does checking something off feel like? Does the item disappear immediately, fade out, or drop to a completed section?
- Does the completed section live at the bottom of each aisle, or as one global section at the end of the whole list?
- How does a new user set up their store layout? A guided wizard, a blank slate they fill themselves, or a default template they edit?
- What happens to an empty aisle header once all its items are checked? Does it stay visible or collapse?
- When the same item appears across multiple lists, does it remember its aisle assignment automatically?
None of these is a hard decision. But I hadn't made a single one of them. I had a feeling of a product, not a definition of one.
The code was never the problem
When I used to build things the traditional way, I'd answer these questions as I coded. Implementation forced decisions, and I made them in line, half-consciously, just to keep moving. The friction of writing code slowed things down enough that my brain had time to fill in the gaps. The code became the spec.
Vibe coding removed that friction entirely. The AI moves too fast for decisions to hide inside implementation. It builds whatever your blurry vision implies, makes its own assumptions about every gap you left open, and then holds the result up for you to look at.
That's when you find out how blurry your vision actually was.
You need to be a PM before you can be a vibe coder
This is the thing nobody talks about in the vibe coding conversation. Everyone is debating whether AI can write good code. That's the wrong question, or at least it's not the first question.
The first question is: do you actually know what you want to build?
Not a vague concept. Not a feeling. A real answer to every decision the product requires before a single line of code makes sense. What happens in the edge cases? What the experience feels like at each step. Why is one behavior right, and another wrong, for this specific product?
That is a product management skill. Not the PM who writes tickets and runs standups. The original meaning of the role. Someone who can close their eyes and describe exactly what an experience should feel like, and why. Someone who has made every decision before the builder starts building.
I thought I had that skill because I've been close to product decisions my whole career. Vibe coding showed me I was used to hiding behind implementation. The moment that the hiding place disappeared, I had to actually think.
That skill turned out to be harder than I expected. Possibly the actual skill that determines whether vibe coding produces something good or just something fast.
The app I eventually built is called By Aisle. It took much longer than expected, not because the code was hard, but because I had to figure out what I was building before I could ask anyone, human or AI, to build it.
If you've been through something similar with a vibe coding project, I'd love to hear how you handled it. And if you haven't tried vibe coding yet, my honest advice is to spend an hour writing down every decision your product requires before you open the AI. You'll be surprised how many you haven't made.