Could Vibe Coding Be the Missing Communication Link Between PMs and Developers?

Table of Contents

• Introduction
• Building a Product Is a Team Sport
  • No Developer Is Perfect And That's Okay
  • No Project Manager Is Perfect And That's Okay Too
  • Even PMs and Clients Can Misalign
  • Common Language
• Mental Models & Misalignment
  • Cognitive Science Tells Us Something Important
  • Visualization Changes the Equation
• Can Vibe Coding Be the Answer?
  • Yes, Absolutely
  • Potential Issues
• Things To Keep In Mind
  • Make Sure Your Company Allows It
  • Do the Research Yourself or Consult Your Technical Team
  • AI Models Do Exactly What You Tell Them, So Be Specific
• 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:

1. 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."

1. 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."

1. 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."

1. 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."

1. 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.