Table of Contents
- Introduction
- Building a Product Is a Team Sport
- Mental Models & Misalignment
- Can Vibe Coding Be the Answer?
- Things To Keep In Mind
- Conclusion
Introduction
It's been a long time since I wrote about vibe coding, and for good reason - it's not a topic I like to talk about. As a seasoned software engineer, I'm all for AI-assisted coding, but vibe coding? That's still a hard no from me.
If you want to understand why I feel this way, check out this article:
And here's where the good old 'however' comes in.
However, today we're going to play a little "😈's 🥑".
After crunching and grinding through the data, my brain finally figured out exactly where vibe coding can actually be useful. Yes, you heard me right, I just mentioned "vibe coding" and "useful" in the same sentence. Who'd have thought?
Spoiler alert: it's not what you think. It's not the traditional, hype-driven version of vibe coding. If you're a software engineer hoping for an excuse to drop everything and dive headfirst into the vibe coding world, sorry, this isn't that place.
In my world, there's no such thing as a developer without coding skills, no matter how hard the influencers who've never written a single line of production code try to sound cool by telling everyone that "Software engineers won't be needed in a month."
They've been saying that for at least three years.
Instead, we're going to explore vibe coding from a different angle, with an open mind. I'm not the type of person who's hostile toward an idea just because it's unfamiliar. That's why I've been thinking about this topic for a long time.
Building a Product Is a Team Sport
No Developer Is Perfect And That's Okay
If you're a software engineer, chances are you've worked in a team with people in very different roles.
The single most important factor in successful teamwork is Communication.
You could assemble the world's best developers in one team, but if they can't communicate effectively, they won't achieve much. Just like in sports, talent alone isn't enough, teamwork and clear communication are what make the real difference.
But there's a problem that often gets overlooked.
A developer might be brilliant at designing systems, writing maintainable, optimized code, and thinking through architecture, basically, everything you'd want technically. Sounds perfect, right? But that doesn't automatically make them a strong communicator when explaining what they're doing.
Even more challenging is understanding exactly what's needed from the business side. For many developers, translating business requirements into technical implementation, or the other way around, can be far harder than just writing code. And there are multiple reasons for this, which we'll explore soon.
Yes, we all know developers should be good communicators, but that's just "shoulda, coulda, woulda". It doesn't always happen. Sometimes a developer is so good at solving problems that you overlook the fact they're not the most talkative or expressive. Sure, they'll ask questions, understand the context, and gather the requirements. But once they feel they understand, they often assume everything's fine and dive into designing the solution, and sometimes, they get something wrong because of those assumptions.
Then there's another category of developers, usually beginners, who worry that asking "too many" questions will make them look unqualified for the job (been there myself and it's miserable until you realize that's not how it works.)
Either way, the result is the same: they end up doing things the wrong way, which is far from ideal.
No Project Manager Is Perfect And That's Okay Too
Project managers usually aren't deeply familiar with the technical side of the product. Sure, there are PMs who understand what's going on at a high level, but they're typically either former software engineers who, for some reason, have had enough of writing code and moved toward the client-facing side, or people who are genuinely curious about how everything works under the hood.
However, those cases aren't that common. Let look at the Venn diagram:
And this diagram isn't just about PMs and developers. The same idea applies to almost any job, technical or non-technical. There are hundreds of roles where the overlap of "excellent at communication" and "excellent at the core skill" creates the mythical, superhuman type.
As a project manager, communication is your superpower. Your primary job is to understand exactly what your client wants and gather the right information from them. Then comes the next step: translating that information clearly to your developers.
And that's when things can get really tricky.
As mentioned, you won't always have developers who understand the product language the same way you do. You might use different terms or conceptualize things differently, and for developers, your terms could have completely different meanings.
Let's look at an example. A simple term - "Real-Time".
PM says: "We need real-time updates."
What the PM might mean is when users refresh, they see fresh data. The numbers feel current. No obvious delay.
What the developer hears? WebSockets, persistent connections, complex state management, scaling challenges.
Now engineering effort multiplies... exponentially.
All because "real-time" meant different things.
This might sound like a funny or even nonsensical example, because surely you'd think it would get clarified, right? But to be honest, I've heard much worse horror stories than this.
Even PMs and Clients Can Misalign
Especially when PMs are working on highly technical products and their clients are also technical. I can only imagine how challenging it must be to listen, gather information you don't fully understand and then translate it clearly to your developers. You're the only bridge between these two overly complex technical worlds, and doing it flawlessly is no small task. That must be a lonely place to be.
Common Language
Developers usually think system-first, while product people think product-first. There's nothing outrageous about this, that's exactly why different roles exist in a company.
But these different mindsets can create gaps in language, perception, and understanding, which sometimes lead to problems. Think of it like Lego pieces: they can be used to build many different things. One person might build a horse🐴, while another builds a bear🐻. Neither is wrong, but the client only wants one of them.
Mental Models & Misalignment
Cognitive Science Tells Us Something Important
It tells us that words don't carry meaning, they trigger mental models.
When you say "dashboard", you're not transmitting an image. You're just activating one. That image is built from your own experiences, your past projects, your preferences, your assumptions. I do the same. And even if we both nod in agreement, we might be visualizing completely different products. That's why teams who've worked together for a long time make hard things look easy.
Their words trigger similar mental models.
The interpretation gap is tiny.
And when you remove that gap, you've already solved half the problem.
That's the hidden danger of language in product development.
It feels precise. It feels shared. But it's interpretive.
Our brains have to decode words, attach context, fill in gaps, and construct internal pictures. That process is fast but it's also personal. Which means two intelligent, competent professionals can agree on the same sentence and still walk away with different realities in mind.
Visualization Changes the Equation
The human brain processes visuals dramatically faster than text. Images don't need to be translated. They don't require semantic negotiation. They're concrete. Immediate. Shared.
When we're both looking at the same interface, the same layout, the same interaction flow, the interpretation layer completely goes out of the window. The mental models collapse into a single reference point. We're no longer debating what something means. We're directly looking at that thing.
So why do we keep trying to align through paragraphs?
If visualization is the fastest path to alignment... then what happens when creating that visualization becomes effortless?
Can Vibe Coding Be the Answer?
Yes, Absolutely
However, not to create the product itself, but to create a visual representation of the product, or a major new feature that's difficult to model clearly in your head.
What I'm trying to say is this: vibe coding can give project managers something close to a superpower, the ability to communicate with near-perfect clarity. Instead of relying solely on words, they can create a working prototype. A tangible blueprint. Something engineers can look at, explore, question and then use as a foundation to build the real system.
As mentioned earlier, misalignments sometimes even happen because clients and product teams visualize ideas differently. This approach can solve that problem as well, and arguably, that's even more important.
Project managers can use this "blueprint" to validate requirements with precision, walking clients through quick demos and confirming alignment before a single line of production code is written.
Potential Issues
But let's address the potential issues with this approach:
1. Not Everyone Builds Visually Tangible Products
What about teams that aren’t building something visually tangible? Teams developing internal libraries or purely technical tools, for example.
In those cases, this approach might not even be necessary. The conversations are already deeply technical and everyone involved likely shares a similar mental model. The language gap is smaller and alignment happens through architecture diagrams, interfaces, and code, not UI prototypes. In cases like that, often the developers from different teams have direct communication with each other for steamlining the whole process.
2. What About Mockup Tools?
Conceptually, this isn't a particulary new idea, tools for creating mockups have existed for a long time.
Absolutely. But those tools are quite limited: they can only do so much, and often your requirements are far more complex than what they support. That's why many companies and project managers skip this practice, it doesn't always deliver enough value to justify the time, and if used incorrectly, it can create more problems than it solves.
With vibe coding, however, you can generate much more advanced, customized visuals that tell the full story. You don't need to learn complex software, it's much faster, and the result communicates your idea clearly to both clients and developers.
3. Speaking of Speed, It Still Takes More Time Than Just Talking Verbally
Even though vibe coding is faster and more precise than traditional mockup tools, It still takes more time than just explaining the concept verbally to developers. Sure.
But... does it?👀
I've seen developers and product people go back and forth tweaking a simple feature for months, only to get it wrong repeatedly.
Think of it like racing: inexperienced drivers think that going "all in", way too hot into a corner will make them faster, but fast in doesn't always mean fast out. Sometimes the opposite is true. Experienced drivers know that to maximize speed on the next straight, you often need to slow down on entry: slow in, fast out.
The same principle applies here: it's better to invest a little extra time upfront, creating clear visuals and alignment, than to deal with endless issues down the line.
Things To Keep In Mind
Make Sure Your Company Allows It
Every company has policies around sharing confidential information. Sometimes, a project, or even a single feature, can be sensitive enough that you're not allowed to mock it up using an external AI model. Typically, this isn't an issue if the company provides its own internal AI model, which keeps all data in-house.
Do the Research Yourself or Consult Your Technical Team
Yes, vibe coding is essentially telling an AI agent what to create, in plain English. But you still need a proper setup, which usually involves a small amount of configuration to get everything running. Consulting with your developers can make this even easier, they can have you up and running in just a few minutes.
AI Models Do Exactly What You Tell Them, So Be Specific
Make sure your instructions are precise. AI models often assume you want a fully functional system, complete with databases, caching, external requests, scaling, security - everything that comes with real software, because most people use vibe coding to actually build software (this is not recommended by me).
If all you need is a dummy or mockup to use as a demo, you have to tell the AI that explicitly. Doing so makes the model's job exponentially easier, produces more flexible results, and uses far fewer tokens.
Examples:
Simple Visual Mockup
Prompt:
"Create a simple mockup of a project management dashboard for a web app. Include task lists, progress bars, and a calendar view. This is just a visual demo, do not include actual databases, APIs, or backend logic."
Feature Prototype
Prompt:
"Generate a prototype for a feature where users can create, edit, and delete items. The prototype should show screens and buttons, but it does not need to connect to a database or have real functionality."
Internal Tool Demo
Prompt:
"Produce a mockup for an internal reporting tool. Include charts, filters, and tables. Only visual elements are required, do not add real data fetching, authentication, or backend services."
Mobile App Example
Prompt:
"Create a visual prototype of a mobile to-do app with three screens: task list, task details, and task creation. This is just a demo, no actual storage, API calls, or notifications are required."
Interactive Demo with Dummy Data
Prompt:
"Build a mockup for a CRM dashboard with dummy data. Include client cards, search filters and activity logs. This is only a prototype for demonstration purposes, skip real functionality like databases, caching, or external requests."
Conclusion
As a developer, I'm not a fan of vibe coding, it's definitely not coding (nor "vibe"), and the name is kind of silly if you ask me. But that doesn't mean it's useless. In software development, everything is a tool. There are no inherently good or bad tools, only good and bad ways to use them.
Vibe coding can be a superpower for project managers, product managers, product owners, and others with limited technical knowledge. It's right there for you to use, with almost no learning curve. That's where I see the real value.
If you're a product person, try suggesting this to your team: practice it, create a demo, and show the value in a tangible way.
If you're a technical person struggling to understand requirements, invite your product people to try this approach. Make it a fun, knowledge-sharing session where you vibe code a dummy or mock application that looks like the real deal. The opportunities here are endless.
Top comments (11)
Oh wow, this article really hit home for me.
When AI coding tools first started showing up everywhere, I was pretty skeptical. Not in a hostile way - I just had this nagging feeling that something important about software engineering was getting lost in the hype. So I started playing with the tools.
At first I went all in. Let the AI generate big chunks of code, whole components, sometimes even full feature skeletons. And pretty quickly I ran into something that caught me off guard: the biggest limitation wasn't the AI. It was my own ability to say clearly what I actually wanted. The more complex the system got, the more obvious it became that vague instructions give you vague systems, and vague systems turn into architectural chaos really fast.
So I switched gears. Instead of asking AI to build systems, I started using it more selectively - almost surgically. I've always worked this way: listen really carefully to the business problem, figure out the real constraints and invariants, shape the domain model and boundaries, get the mental model aligned with the product team, and only then start implementing. With AI tools speeding development up, that became especially important. And that's when something similar to what you describe started happening. We started being more thorough about how we discuss new features with product people. You're right that words trigger mental models, and those models are rarely the same between developers, PMs, and clients. The more we get that straight in discussion, the less interpretation and guessing, and alignment happens way faster. The racing analogy (slow in, fast out) really got me - I used to do karting and now sometimes winter rally cross, so that one landed. I often see the same thing when designing.
Another thing that came out of these conversations: I started trying to explain architectural decisions not in engineering jargon but in metaphors from the customer's own domain. Instead of talking about services, queues, databases, event flows, I try to translate the architecture into concepts the business already gets. Like, instead of "this service processes events asynchronously" I might say something like "this part of the system works like a logistics hub - requests come in, get sorted, and then move on on their own without blocking the rest." Once you explain architecture in the language of the domain, talks with PMs and clients get a lot clearer.
With AI speeding things up, all of that became especially important. Development got faster but understanding didn't - so you end up with coding that's cheap and architectural mistakes that cost a lot. What matters most now is the ability to get from those conversations everything you need for a solid architecture, and then convince them - in the language of business and economics - to do it this way and not another.
Great insights, thanks for such a thoughtful and detailed comment. Your perspective on AI and how it intersects with business requirements is spot-on. As developers, it's important for us to step into the shoes of less technical roles and recognize that something obvious to us can be incredibly difficult for them to grasp, and sometimes the reverse is also true.
That's why approaches like vibe coding can act as a useful bridge between those two worlds. When technical and business perspectives don't align, a product is far less likely to succeed or even make it to implementation.
Rallycross sounds like a lot of fun, by the way. It's great to see someone who also appreciates the excitement and beauty of motor racing!
This is honestly something I never considered until I started building side projects with AI tools on weekends. I work with PMs all week and the number of times we talk past each other about the same feature is wild. Then I started vibe coding prototypes and realized - wait, if the PM could just describe what they want to an AI and get a rough working version, we could skip like 3 rounds of back and forth about what "intuitive" means.
The catch though is exactly what you said about being specific. PMs who write vague tickets will get vague prototypes from AI too. So in a weird way it might actually force better requirement writing which... honestly benefits everyone. I tried letting a non-technical friend describe a feature to Claude and the prototype was surprisingly close to what I would have built, just messier. But the intent was right and that is usually the hardest part to communicate.
Thanks for sharing the interesting insights. AI models also have their own “mental models” when describing something to them, but it’s much easier, faster and less painful to have back and forth with Claude than a senior developer or PM.
I’m glad this article resonated with you.
Totally agree, the back and forth with Claude feels way more iterative than trying to schedule 30min with a senior dev just to validate an approach. Glad the article sparked some thoughts 🙌
I like the practical approach to vibe coding that you introduce here. I agree that it's great for prototyping and can be beneficial for both PMs and Devs if approached with the right mindset.
Devs could benefit from upskilling their product thinking and PMs from understanding better the technical implications of building software. At the end of the day, it feels like it boils down to communication and culture.
Absolutely. When it comes to teamwork, communication is even more important than individual skills. But when strong communication is paired with exceptional individual talent, it creates a truly dominating combination.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.