The Blind Men and the Elephant
What Vibe Coding Taught Me About Product Taste
blind men and elephant
In Chinese, there’s an idiom called “blind men touching an elephant.” A group of blind men encounter an elephant for the first time, each touching a different part: the one who touches the leg says it’s a pillar, the one who touches the belly says it’s a wall, the one who touches the trunk says it’s a rope, the one who touches the ear says it’s a fan. Every one of them is describing something real, but none of them has seen the elephant.
I’ve come to feel that before vibe coding came along, the way many designers and engineers collaborated looked a lot like this story.
Not because they weren’t good enough, but because the technical boundaries of the past made it nearly impossible for anyone to take on multiple stages of the process at once. Designers focused on design, engineers focused on implementation. That’s a reasonable division of labor. But the division itself comes at a cost: each person can only touch the part they’re directly involved in.
There’s an important pattern here: we cannot gain insight from stages we haven’t participated in. Once we go the route of secondhand information, it becomes very hard to truly develop perception in that area. The feelings, constraints, and opportunities that others relay to us can never be as vivid or as visceral as experiencing them firsthand.
product elephant
This problem is symmetrical for designers and engineers. When an engineer hits a technical bottleneck, they have to first digest it, then summarize it, then bring it to a meeting and say “this feature probably can’t be done.” What we hear is already a translated version. We don’t know why it can’t be done; we can only passively accept it. The reverse is just as true: when a designer presents a solution, they’ve already weighed countless trade-offs behind the scenes. But during review, others might suggest Option A, Option B, Option C, and those are precisely the options that were already considered and deliberately set aside. All the back-and-forth alignment that follows takes a great deal of time and energy.
📌
This isn’t anyone’s fault. It’s a structural problem of information asymmetry.
When we actually build something ourselves, that asymmetric structure breaks down. When a path doesn’t work, there’s no need to wait for someone else to explain why. The moment we hit that wall with our own hands, we understand. A real empathy for the constraint emerges, and pivoting happens more naturally, more quickly.
Speed is one thing, but what matters more is the quality of decisions and the growth of product instinct. Testing a prototype and using a real, shipped product feel completely different. With a real product, every rough edge gives immediate, direct feedback. The discomfort is instant and firsthand, something no prototype or secondhand test report can replicate. When I’m the one designing, building, testing, and shipping all at once, my understanding of the product accumulates in an entirely different way. I’m no longer just hearing someone describe the elephant, or even just touching it. I’m seeing it from a higher dimension.
This isn’t anyone’s fault. It’s a structural problem of information asymmetry.
When we actually build something ourselves, that asymmetric structure breaks down. When a path doesn’t work, there’s no need to wait for someone else to explain why. The moment we hit that wall with our own hands, we understand. A real empathy for the constraint emerges, and pivoting happens more naturally, more quickly.
Speed is one thing, but what matters more is the quality of decisions and the growth of product instinct. Testing a prototype and using a real, shipped product feel completely different. With a real product, every rough edge gives immediate, direct feedback. The discomfort is instant and firsthand, something no prototype or secondhand test report can replicate. When I’m the one designing, building, testing, and shipping all at once, my understanding of the product accumulates in an entirely different way. I’m no longer just hearing someone describe the elephant, or even just touching it. I’m seeing it from a higher dimension.
“Something feels off” is easier to express in voice
Recently I used AI to remix, redesign and launch a Chrome extension called Tab Pano, built on top of Zara Zhang’s open-source project Tab Out. This wasn’t my first time going through the full lifecycle of shipping a vibe coding product, but it was the first time I faced rejection after submitting for review, had to revise, and resubmit.
Before listing it, I had to do my own branding, create screenshots, and write feature descriptions for the review team. After submitting, it was rejected twice: once for insufficient permission justifications, and once because the reviewer interpreted the search logic as replacing the user’s default search engine. Each time it came back, I had to go into the code, understand the reviewer’s reasoning, and resubmit. None of this exists in the traditional designer role, but these are precisely the most direct ways to understand how a product actually lives in the world.
What vibe coding gives designers isn’t just an addition to their skill set. It’s a real sense of ownership, and a pair of eyes that can finally see the whole elephant.
This isn’t to say every designer needs to become a full-stack engineer. Constraints aren’t a bad thing; people with clear boundaries often go deeper within them. But if what you want to sharpen is product judgment and taste, the kind of ability that tells you what’s worth building, why it’s worth building, and what happens after you build it, then now is the best time to reach out and touch the part of the elephant you’ve never touched before.
📌
You might find vibe coding is more interesting than you imagined, and genuinely fun.
It feels nothing like staring at design files, and it’s pretty addictive.
You might find vibe coding is more interesting than you imagined, and genuinely fun.
It feels nothing like staring at design files, and it’s pretty addictive.
🤔 A note on trying vibe coding
One last thing: getting the functionality working and the design looking passable probably takes about 20% of the time. But making every detail match the design system, making it truly usable, meeting your own standards, that still takes a huge amount of time to refine, iterate on details and flows. Vibe coding doesn’t make that part easier; it just gets us to a real product faster. So if you want to make something you’re truly satisfied with in every way, don’t believe the “I whipped up a vibe coding product in two or three hours” stories. It still takes sitting down and putting in the work.
✨ That’s Summary #3 of my AI Design Trails.
Follow along — more experiments, failures, and surprises to come.
👉 You can check out all my Trails below or email me for more details :)
[ X / Medium / Substack / Figma Community].
Follow along — more experiments, failures, and surprises to come.
👉 You can check out all my Trails below or email me for more details :)
[ X / Medium / Substack / Figma Community].
