Sorry Dan, PMs Should Absolutely Vibe Code
AI is making product people the MVPs of any business
A few hours ago, this post from Dan McKinnon hit the front page of HN:
PMs shouldn’t waste time landing prod diffs at Meta scale
If the feature is actually important, fix the system for prioritization (your real job) rather than circumventing it.
You probably code like a slow E3 but cost the company an IC7 salary.
It is very easy to accumulate tech debt with random PM pet features. Remember that even diffs to intern tools can break prod!
Dan gives the other side a fair shake, carving out a few examples for when a PM should in fact vibe code. But in general the tone is that this is a waste of the PMs (and everyone else’s) time. The HN commentariat went further, arguing that PMs were themselves obsolete and most everything could be done by an engineer.
Meta, and other large companies have been encouraging PMs to code, while I’ve seen many negative responses from engineers having to code review, debug, deal with production issues, etc. stemming from crappy code they don’t understand. Metrics and KPIs are being gamed into stupid incentives like lines of code, commits, and tickets closed. Leadership claims they are aware of Goodhart’s Law, but their actions show otherwise.
My hot take: the dedicated PM role is becoming optional. Engineers already understand feasibility and tradeoffs, and they often end up informing the PM anyway, which usually comes at the cost of meetings and slow decisions. With clear quarterly goals, engineering and design can own product together. They would shape scope, ship in increments, measure, and iterate. So the “product” function still exists, but its not a separate PM attached to it.
Sorry, I disagree.1
The future we are barreling towards is one where the PM is the most important role in a company. This is already true in many startups. It is a matter of time before it is true at Meta scale.
Let me try and explain what I see through the lens of my company.
Nori is still small — only four (extremely talented2) people. We build infrastructure for AI dev. We’re still early, so we don’t have requirements for nine 9s of uptime or millions of DAU. One day, soon, but just not yet.
At our stage, there is essentially 0 barrier for building products. We build and ship new products on a ~2w cycle. We have a constant pipeline of ideas going from prototype → iteration → maturity. We write product specs that define user behavior and let Claude Code run in the nori terminal on a loop over night, and we wake up in the morning to a nearly finished usable product. Not an MVP, but an actual honest-to-god product.
The only thing that matters is how good the product spec is. And ‘good’ here means something very specific: how much do our end clients like our tools? Does it solve the problems they have? Is it aesthetically pleasing? Is it a joy to use? PMs exist to answer these questions.
And even though it pains me to admit it, engineers often struggle to answer those questions, because they are engineer brained. There is nothing wrong with being engineer brained, I am also engineer brained, but it makes empathy for the user very difficult. Cf the (in)famous ‘just run your own ftp server’ HN comment.
Merely possessing technical knowledge makes empathy for non-technical users really hard. We often underestimate just how scary opening a chrome dev console can be.
From where I sit, we are clearly moving to a world where technical knowledge can be much lower resolution. Knowing how to provision a database is less important than knowing which database to provision, which in turn is less important than simply knowing that databases exist, there are different ones that serve different purposes, and sometimes you want one over the other. If you have that last bit of information, you can rely on the agents for a lot of the rest.
Is Nori as big as Meta? No, of course not. But even Meta has many needs that are not ‘meta-scale’. For any application or service that needs to serve < 100k people in a somewhat non-bursty way, technical moats are just gone. And it turns out that a lot of things that Meta does — from internal tools to experimental projects — fall into this category. In these spaces, a good PM won’t be increasing tech debt, because the features they are adding are important for the end user to begin with. And any tech debt that may accrue is, in my experience, extremely worth the faster iteration and shipping cycles.
A year ago, I wrote:
If you were a clarinetist back before the phonogram really took off, there were a lot of jobs and they paid well. Any bar, restaurant, theater, or dance hall needed live musicians to have any music at all. Now, it's a desert. No one wants clarinetists, because no one needs live orchestra when they can ask the genie in their pocket for whatever music whenever they want. I'd wager that you have way more people able to make music today than you did at basically any point in the early 1900s. But the ability to make a career in that space has plummeted. The barriers to entry have dropped, taste is way more important, and there are only like 3 clarinetists who matter enough to make anything close to a middle class living on taste alone. Sure, every now and then you'll get an Elton John, but, like, you can't exactly plan for that!
…
On a semi-related note: earlier we talked about how AI destroyed the graphic design sector. One thing that I didn’t mention is that the ‘true’ artists, the senior types who have been in the industry for a while, are thriving — those guys were primarily valued for their taste anyway, and now that is even more valuable. There’s an important pattern there: generally seniority and taste are highly correlated, so we should expect AI to disproportionately hit junior, freelance, and entry level positions. The more senior you are, the more insulated you are, the more you’ll benefit.
And just a few days ago, I wrote:
In markets with low barriers to entry, small improvements in taste and aesthetic and userfeel generate outsized returns. Linear and Jira are basically the same product — they do task tracking for engineering teams. It’s just not that hard to build. But Linear has a fantastic aesthetic that will drive adoption long after Jira falls by the wayside. Look for the tools that people love to share and only have good things to say about. Those are the ones that will define what SaaS means.
Guess what? Barriers to entry are on the floor, which means the winners in various product categories are going to be judged primarily on taste and joyfulness. We’ve seen this over and over again in other industries, from fashion to video games to books. Now software. Linear over Jira, Figma vs Sketch, Slack vs Teams. It’s the product people who matter. And as the barrier to entry continues to drop, it will be the product people taking over the role of the engineer, because it is the product people who understand what needs to be built.
Maybe product folks should not be pushing to Meta’s internal databases or highly distributed serving systems. The AI models are bad in that environment, and besides, those things are mostly implementation detail. But the product folks should absolutely be pushing to:
Any and all internal tools
Basically all UI/UX, internal or otherwise
Any and all marketing material, including most ‘static’ sites that are not meant to be SPAs.
In other words: anything user facing.
If you’re a tech team feeling the FOMO and struggling to build your AI capabilities, reach out. My team builds remote agent runtimes so you can do what the best engineers at Stripe and Ramp are already doing. Or join our public slack to keep up to date on what’s happening in AI in real time.
I mostly disagree. Dan wisely carves out “at Meta scale” when objecting to PM vibe coders, and he probably is sorta right there. But that speaks more to the limitations of current models than it does to the sanctity of the engineering / pm role distinction.
well, 3.5 extremely talented people. Everyone else punches way above their weight, I’m just a guy.