After reading Marty Cagan's interesting article A Vision For Product Teams I started to think about the topic of product discovery. I think the discourse discourse on prototyping and creating proof-of-concepts with AI misses the point.
Speeding up parts of the iteration with AI is only sub-optimisation of the process. When thinking in typical model of discovery and delivery, discovery includes activities such as:
In short: discovery is about finding a problem wort of solving. Gaining understanding. Building empathy. Formulating a position and foundation. In abstract, it's a cycle interacting with the environment and thinking. So why does LinkedIn commentators, tech influencers, founders and the industry in general push the narrative that these new tools will now replace INSERT DESIGN ACTIVITY, and INSERT DESIGN ROLE OR DESIGN TASK is becoming obsolete because it can be replaced with INSERT TOOL?
I understand there are monetary reasons that incentives founders and other entrepreneurs to maximise cash-in during the gold-rush age of AI tools. There are probably some hierarchical and social reasons as well, but I would like to highlight a problematic area that originates from incomplete understanding the activity of design itself.
Vibe coding – or any GenAI(TM) approach for that matter – does not replace, cover or address the wide range of activities mentioned earlier. Designing via prompting is like technically advanced version of the famous "5-whys" method. The inherit problem of 5-whys is its reliance on the knowledge and biases of the person who is asking. Without interacting with the environment and outside world it only takes you only so far.
Chip Huyen quote (from the above linked article): "I don’t think AI introduces a new kind of thinking. It reveals what actually requires thinking."
Prototyping and building proof-of-concepts is an old idea. It was the inheritly human mindset from the beginning of computers and software. The point worth of repeating is that these new AI tools did not invent the idea of making quick prototypes of the real versions for validation purposes.
It's not that long ago when low-code/no-code was the next big thing. Speeding up the frustrating phase of defining, implementing and validating was the inherit promise of the movement. Reaching the end result quickly is a recurring topic and it touches all aspects of development: processes, technologies, people (teams, organisations), etc. And in case of low-code/no-code, it is still about improving parts of the processes only. In the end: someone still needs to understand what, for who and why.
It is likely that in the future we start to see more "real looking" examples in our day-to-day digital work, but fundamentally it's not a new thing. It's more about something that already existed.
Let's go back to the design tools and design related roles in the industry. I believe confusion originates from roles and the required skillsets needed in those roles. The fallacy is to think that speeding up parts of the process within one activity makes one capable of rotating roles – with different activities – without any issues. Product Owners can now do quick ideas on the side before client meeting or developer can now draft the UI for the new feature. All possible because of AI! Or is it really?
Even if you have access to new fancy AI tool does that make you an expert in the domain of the tool. I want to emphasise that I have absolutely nothing against developer who also designs, quite the opposite. My point is that replacing parts of an activity by the tools does not constitute the craft required for the activity. You cannot replace the human judgement and taste with a tool, that has to be non-AI property of the actor. (Even the AI system themselves follow this idea by following the design principle of "human in the loop", conveying the idea user stays in control while using the system.)
Creating a tangible PoC for review (or to support discussion, or whatever purpose during the discovery) has been a thing long before LLMs. It will always be, because that's how humans build stuff. The degree of how well that has been done in context of individuals' own experience is the key factor generating the illusion that using the tools is the activity itself. In other words: if one has only understood the design as going through Figma screen and discussing about user flows and screens then that might very well be the full understanding of what is actually going on. It's rather common – yet incomplete – mental model of what design is about.
Maybe it's about subjective views and experiences in software development. Maybe people are used to certain things and forget the craft of design and discovery in the first place. Maybe getting exposed to an idea – rapid prototyping – makes one think it's a new idea altogether.
It's worth repeating: using LLM makes parts of the process faster. What it cannot do is add skills to roles. The benefits remain mostly within improved flexibility in time-allocation within role.
Just because you can vibe stuff out does not mean the you understand it.
If you choose to ignore the fundamentals and avoid the craft, it cannot be replaced with more prompts later. In trivial cases you can fake it some time, but sooner or later you need to understand things on deeper level.
I’m not against coming up with ideas and making them tangible quickly — I’m all for it. At the same time, it’s not reasonable to expect such speed to replace activities that actually require thinking and real work. Spinning up a convincing weekend PoC is indeed amazing, but at the end of the day, it’s better to avoid making statements that give the impression no more discovery work is needed. It’s never that easy.
I own a washing machine, but that doesn’t make me an expert in doing laundry. I know almost nothing about fabrics, their properties, and how they interact with different water temperatures. I don’t understand the chemicals either, or when they are introduced during the wash cycle. The analogy isn’t about machines replacing human tasks — it’s about my relationship to the task within a specific context. Fundamentally, it’s about not lying to myself by claiming I’ve mastered an area just because I have access to a tool.
But wait,
The truth is, when you're building software, you’re not the user — you’re the builder. And the builder needs to understand the system inside and out. If you don’t know your software, you’re not building it — you’re just reselling it. Real builders can make thoughtful, deliberate changes with confidence and taste. Letting AI exclude you from that understanding is, especially in the long run, the most unproductive choice you can make. Don't let the temptation of trivialising actual work become your main course of action.