Table of Contents
Introduction
Building a Product Is a Team Sport
No Developer Is Perfect And That's Okay
No Project Manager Is Perf...
For further actions, you may consider blocking this person and/or reporting abuse
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.