🚀 The fastest way to tell if you're vibe coding... or actually building a product
A few months ago, I realized I was measuring the wrong thing.
Every day I'd look at questions like:
✅ How many features did I build?
✅ How many prompts did I write?
✅ How many commits did I make?
It felt like progress.
But none of those numbers answered the only question that really mattered.
💡 Did the product become more valuable today?
AI makes building incredibly fast.
That's amazing.
But it also creates a new trap.
You can spend an entire day shipping features nobody asked for, fixing bugs introduced by yesterday's prompts, or redesigning something that was already good enough.
At the end of the day, you've written thousands of lines of code...
...without making the product meaningfully better.
Now, before I ask an AI agent to build anything, I stop and ask myself one question:
🤔 "If this feature disappeared tomorrow, would any user actually miss it?"
If the answer is:
"Probably not."
I don't build it.
Ironically, AI hasn't made saying "yes" more important.
It's made saying "no" one of the most valuable product skills.
💬 I'm curious how other builders think about this.
What's one feature you built with AI that felt productive—but later realized didn't actually improve the product?
I'd love to hear the stories behind those decisions. I think they're often more valuable than the success stories.
Replies
Built a whole settings page last month that literally zero users have touched since.
@elliott_reed 😄 I think every builder has a version of this story. The upside is those moments usually teach us to validate before polishing. Sometimes the feature we don't build ends up being the biggest win.
The hard part isn't asking the question, it's actually killing the feature once you don't like your own answer.
@mia_sullivan1 💯 Exactly. Saying "no" gets harder the more time you've already invested. AI makes building cheap, but it doesn't make letting go any easier.
The hard part isn't asking the question, it's actually killing the feature once you don't like your own answer.
@lily_foster2Â Couldn't agree more. I think founder discipline shows up more in what we remove than in what we add.
I'm curious, do you measure the difference by user feedback or by shipping frequency? For me, real conversations with users reveal far more than clean commits every could
@new_user___090202674ab6e030a7a9c52Â Great question, Mukesh. For me, user feedback carries much more weight than shipping frequency. Shipping is an output, but conversations with users reveal whether the product is actually solving a problem. I still track releases, but I treat user feedback as the leading indicator for what to build next.
No is the real skill here.
@chloe_bennett 🎯 Absolutely. AI has reduced the cost of saying "yes" to every idea, which makes knowing when to say "no" even more valuable.
This framing matters most for solo devs on a runway — every feature nobody asked for is time you can't get back.
@caleb_hunter_guahip That's exactly how I think about it. For solo founders, time is usually the scarcest resource. Every unnecessary feature has an opportunity cost.
Tracking output instead of outcomes isn't new, it just used to be called "hours logged" before it became "commits pushed."
@charlotte_reed1 I love that perspective. The metrics changed—from hours logged to commits pushed—but the underlying trap is the same. It's a good reminder that productivity metrics aren't always product metrics.
The commits-as-progress line got me. mistaken volume of output for actual movement more times than i'd like to admit.
@evelyn_clark1Â Same here. AI makes it even easier to confuse momentum with meaningful progress. I've had to consciously separate "busy" from "valuable."
Rebuilt a whole onboarding flow last month because it felt unfinished, not because anyone asked. Nobody noticed the change either direction. The commit count went up, the product didn't.
@irahimiam That's a great example. It's surprisingly easy to optimize for our own sense of completeness instead of user impact. Sometimes "good enough" really is the right product decision.