We are living through an interesting shift in how software gets made. AI has dramatically lowered the barrier to entry to building digital products. People who may have never considered themselves tech-savvy can now turn an idea into a functioning application in a matter of hours, days, or weeks. I get why this may seem like an exciting development. More founders can experiment and build without raising capital and assembling a product development team to get their idea off the ground. People with deep knowledge of a particular problem in their field can quickly translate it into a solution.
However, as a UX and product designer, I find myself thinking about what happens when building becomes almost frictionless. It certainly doesn’t mean that we should skip the conventional approach to UX and product design.
Vibe coding isn’t the problem
I’ve seen lots of criticism of vibe coding and the products being created with AI assistance. A lot of it is warranted. We’re seeing applications that are technically functional but poorly conceived, unnecessarily complicated, or difficult to use. I still don’t think vibe coding is the problem. The real problem occurs when the ability to build outpaces the need to think critically about what is being built and why.
Traditionally, there were significant barriers between having an idea and shipping a product. You had to conduct user research, explain the idea to a designer, think through requirements, make decisions about scope, work with a developer. Development took a significant amount of time and money which forced founders to prioritize and be intentional about product decisions.
To many, vibe coding has removed the need for this process. It has become tempting to dive straight into development mode because you’ve identified a problem that could be solved with a product.
There’s a caveat to this approach to vibe coding. The fact that you could build something doesn’t mean that you should. You must also take into consideration that building a functional application doesn’t mean you’ve created a good product.
A product can work exactly as it was programmed to function and still fail to solve a meaningful problem.
Founder-problem fit isn’t market-problem fit
So, how do we determine when a problem is meaningful to solve. Naturally, founders are building from their own experience. You have observed a challenge, witnessed a frustration, seen clients struggle, and found a workaround. There’s a trap with this approach though.
Founder-problem fit does not automatically equate to market-problem fit.
Just because a problem is real for you doesn’t mean it’s valuable, feasible, and viable to support a business case for product development. Your experience can be the starting point for an idea. However, it cannot be the entire validation process.
You still need to understand who else has the problem, how they are dealing with it, how often they experience it, how important it is to them, and whether they are actually willing to change their behavior to solve it.
This is where product thinking comes in. It forces you to step outside your own experience and examine the problem from the user’s perspective. There’s a big difference between “I had this problem, so I built a solution” and “I believe this is a problem worth solving, so I’m going to find out how other people experience it before deciding what to build.”
Both approaches will produce a product. The latter gives you a better chance of creating one people actually need.
Building is not the same as product development.
One of the things that gets lost in the conversation about AI-assisted development is the difference between building software and developing a product. Building is the act of creating something. Anyone can use AI to build. Product development, however, is figuring out what should be created, for whom, why it matters, how it should work, and whether it delivers value. AI has become remarkably good at helping with building, but it has not eliminated the need for applying product thinking in the development process.
Product thinking requires you to step back from the excitement of the solution and understand the problem first.
- Who is experiencing it?
- How are they dealing with it?
- Is it significant enough for them to change their behavior?
- What alternatives already exist?
- What would make your solution meaningfully better?
- What assumptions are you making about the problem, the user, and the solution?
These aren’t hurdles standing between the fun part of building. They are the foundation of the product.
The temptation to build before you think
I understand why founders want to jump into vibe coding a product. There is something incredibly satisfying about seeing an idea come to life. AI has made that feedback loop almost instantaneous, and I don’t think we should underestimate how powerful that is.
The problem is that momentum can easily be mistaken for progress.
- You add a feature, so you feel like you’re moving forward.
- You improve the interface, so the product feels well-designed.
- You add another workflow because AI can build it quickly.
Eventually, you have something substantial enough to call a product. Yet none of those things necessarily tell you whether you’re moving in the right direction. This is where product thinking creates an important discipline. It asks you to distinguish between speed and progress.
The question isn’t simply “What can I build next?” It should be “What is the most valuable thing for me to learn or accomplish next?”
Sometimes that means generating code. Other times it means prototyping. It may also mean talking to users. It could even mean removing a feature you were excited about. Sometimes it simply means admitting that the original idea needs to change.
You’re not being inefficient because you’re slowing down to think. You’re engaging in good product development.
AI makes scope creep easier
There’s another consequence of removing friction from development that I think deserves more attention. Prioritization becomes harder when everything feels possible.
When building a feature required significant time and resources, you had a natural reason to question whether it was worth doing. AI changes that calculation. If a feature can be generated in an afternoon, it becomes tempting to add it simply because you can. However, the fact that something is inexpensive to build doesn’t make it valuable to the user. This is why product thinking becomes increasingly important in an AI-assisted development environment.
Someone still has to determine what belongs in the product and what doesn’t. A strong MVP isn’t simply the smallest product you can technically build. It is the smallest version of the product that can meaningfully test your assumptions and deliver value to the user. That requires judgement which comes from understanding the problem and determining user needs outcomes. This is the foundation of product thinking.
UX isn’t something you add after the product is built
The same principle applies to UX. AI can generate interfaces quickly, but good UX has never been about producing screens. It’s about understanding the relationship between the user, the task they’re trying to accomplish, and the system you’re asking them to interact with.
A polished interface can still be confusing. A visually impressive onboarding flow can still ask for information the user doesn’t think they need to provide. A sophisticated dashboard can still overwhelm someone who only needs to accomplish one simple task.
Good UX requires you to think about the experience before you think about the pixels.
- What does the user need to know at this point?
- What decision are they trying to make?
- What should happen when they take an action?
- What happens when they make a mistake?
- What information should be presented now and what can wait until later?
These are product questions as much as they are design questions. They can’t be answered simply by generating more screens.
You cannot validate a product by building
Perhaps the most important principle to carry into this new era of product development is this: Building is not validation.
You can build an application that works perfectly and still discover that your users don’t understand it. You can build the feature you were certain people wanted and discover that they barely use it. You can launch a product and discover that the problem wasn’t as important as you thought. You can build a beautiful solution to a problem that only really mattered to you.
That isn’t a reason to avoid building. It’s a reason to learn earlier. User research and testing exist precisely because our assumptions are often biased.
The goal isn’t to prove that your idea is brilliant. Your aim should be to learn enough to make better decisions.
This is where I think the speed of AI development presents an interesting challenge. When you can build something that quickly, there is a temptation to keep going instead of taking a necessary step back to learn. Sometimes the most productive thing you can do is pause.
- Talk to the people you’re building for.
- Watch them use the product.
- Ask what they expected to happen.
- Pay attention to where they hesitate.
- Find out what they actually value.
Then decide what to build next based on what you’ve learned.
Think before vibe coding
AI and vibe coding has changed the development process. It hasn’t changed the fundamentals of building good products.
We can use AI to dramatically reduce the cost and time involved while still applying the principles that have always contributed to purposeful product development: understanding users, defining meaningful problems, challenging assumptions, prioritizing strategically, designing thoughtful experiences, and learning from real-world behavior.
In fact, I think that’s the opportunity. The founders who benefit most from AI will not necessarily be the ones who can generate the most code or ship the most features. They will be the ones who can combine the speed of AI with the judgement to know what deserves to be built in the first place.
AI can help you build faster. It can help you explore possibilities faster, prototype faster, and ideate faster. However, you still need to decide what the product should do, who it’s for, whether the problem is actually worth solving, and whether the solution you’re creating is delivering value.
AI can accelerate execution. It doesn’t eliminate the need for product thinking.
That’s the philosophy behind my new offer Think Before You Vibe.
I’m not interested in convincing founders to stop using AI to build. I want to encourage you to use it more intentionally by bringing product and UX thinking into the process from the beginning.
The goal shouldn’t simply be to build more products. It should be to build better ones. If AI gives us the ability to build faster than ever before, then perhaps the competitive advantage isn’t speed alone. Perhaps it’s knowing how and where to direct that speed.