I noticed that AI evangelists really love to use word "fun" to describe anything they do with AI.
Claw people particularly seem really love to use that word when answering what practical or useful they do with AI agents. It's always something absurdly trivial followed by "and it's just fun!"
Don't really have any conclusion to this - just thought to share this observation.
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.
Overall the rise of business types in tech company leadership has led to a drop in engineering quality, a rise in short term metrics, and fiascos like the COVID overhiring into multiple rounds of layoffs.
We're solving this with two different tracks for Vibed stuff and Actual Code.
Vibed stuff can do whatever it wants, with some basic CI checks and Agent instructions
BUT if any of that crosses specific thresholds (writes to dangerous APIs, reads from unvetted sources, is deployed on the public internet), an actual developer MUST review the code - with the associated costs billed to the creator's BU.
Works fine, zero projects have been made public yet, but we have a bunch of Vibed internal tools in use that can't be accessed outside our internal network (or VPN) that are actually helping people do their work more efficiently.
I don’t think this is a spicy take at all. A PM’s job is to prioritise, and the most important/high priority projects will naturally be handled by Engineers enabled with AI-coding workflows. The high priority/impact work should be allocated to the folks with the highest level of skill.
I feel like PMs coding unlocks a whole new category of work, mainly addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressed. Time will tell how valuable these items are in the long term.
>PMs coding unlocks a whole new category of work, mainly addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressed
So you get to cowboy code, but I don't. I see how it is.
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.
PMs in Meta-scale companies vs. startups has always been different, and they are diverging even more as AI gets better.
In startups anything goes. PMs and engs do whatever it takes to ship and scale the business. No one cares who's using AI in what way, as long as they're getting shit done.
In a place like Meta or Amazon, people also get more shit done with AI, but because these teams are huge, well-oiled machines, sudden productivity bumps or norm changes can drop overall productivity.
Totally agree with this post as long as it's limited to large, mature teams
Hot take: only PMs need to code now. With Claude 4.6 Opus, the engineer skill set is no longer useful. Why are we hiring people with code writing ability when code writing ability has no value anymore?
In my job I struggle to find time for the coding I need to get done, in between all the other stuff I also need to do. If the coding part goes that much quicker with AI, then I can do the rest of my job better.
So AI is merely letting me focus more on the other parts. Some developers don't like this. I kind of do.
I remember this post. But I'm not sure what the future really entails and I suspect it'll be very company/culture dependent. In some companies, the engineers are very savvy and understand the business well. In others, it's the designers. Or sales. Ops. And of course Product Managers. You get the picture.
Whoever gets the business best (and in detail) will likely be the best builders. It's "intuition as evals" that really matters in the end. You think Software Engineers or Product Managers are replacing Quants at trading shops anytime soon? Nope.
I generally agree with the take. At the moment the models and agents aren’t good enough for someone who isn’t trained to build and maintain a production system. So as long as Eng isn’t significantly more bandwidth starved than PM, PM’s writing production code is not a high leverage activity.
The key issue right now is that the models falter in the last mile, and the last mile is where you need the training and experience to make sure the thing that lands is production quality.
At some point in the next few years I believe the roles will merge. I suspect that PMs will be forced to specialize towards a discipline (design, data science, engineering, etc.) while engineers will also start to see more of their responsibilities covering former PM territory. Most engineers will probably become closer to “product engineers”.
Our job is done for. We will be shown the door, and everyone will rejoice. Everyone will live in a happy world where you'll doddle a house and Claude will build you a next generation SaaS that makes you millions. Managers will do the job of engineers, by just telling LLMs to make an app or to make money or something. C-suites will have agents doing the jobs of managers, and CEOs will run entire companies with a Claude $200 subscription alone. It is truly the next thing, and the future, probably happening in the next 2 years, or in 2 years in 2 years.
Yesterday I had an interview, but I got rejected. They decided to go for a manager with a Claude subscription who vibe-coded a weather app.
I cannot tell if this is a genuine sentiment or parody; in this space, the two coincide with one another so frequently these days that it's hard to tell.
Please don't give up. This too shall pass. The bill for the worst excesses in this great experiment will come due. I can imagine the need to reckon with the growing technical and cognitive debt in a responsible way will be an existential issue for some enterprises. Somebody will need to step in and be the adults in the room.
I think it depends on the company. In large companies, the role of PM probably won’t change that much. However, PMs who are technical and hands-on can bring significantly more value by leveraging AI tools.
There’s another path for PMs that the article and most of the comments don’t seem to mention.
Technical PMs are now in a great position to start their own companies. In the past, many were blocked or handicapped by the inability to code. With AI-assisted development, that barrier is much lower, which gives them a lot more leverage to build products themselves.
A friend at Meta -- long before the age of LLMs -- got paged at 3am for a site issue. When he found the PR that caused the bug, the testing section for the change simply said:
YOLO!
This was well into the "Move fast with stable infra" era of Meta, but clearly that still encouraged "Move fast and break things" for everything beyond infra.
PMs landing Prod diffs sounds like even more moving fast shall ensue.
As much as I recognize that a truly talented product manager is worth their weight in gold, I'd say the average engineer would be much more capable of learning to be an average PM than vice versa.
PM vibe coding a prototype for demonstration purposes? Might be a better use of a designer or engineers time, but okay I could see it being valuable. PM vibe coding something to ship to production? Your title is now engineer and you are responsible for your change, otherwise this is a direct path to destroying the quality of your product and the integrity of its data.
I imagine you’re saying that as a software engineer :). As a manager of both software engineers and product managers, I think this view is a bit of a stretch.
Some software engineers would make good product managers, some product managers would make good software engineers, and the majority of both are best suited to their current job.
You're correct I've spent most time as a software engineer or a engineering manager. I actually started my career as a web designer though. I've also been effectively an active PM in roles where there was no formal product management funtion. I've also been a co-founder of a two person operation where I did all the product and tech, and my co-founder did all the biz and operations. Another startup I co-founded I was "CTO" but was effectively the number 2 in a 100 person company and had veto power over our first PM hire. I've also been part of a larger scaleup that was acquired in a scenario that left a number of folks orphaned, so for a while I was also managing a handful of designers, program managers, and an IT manager.
So yeah, I understand your point, and if I ran a cross-functional team like that I would hopefully hire well enough that I felt the same. So maybe to restate my thinking in a way that may be slightly less controversial: AI is eating a lot of the low-level mechanistic work that used to define being a software engineer, however I never believed that was where the value was for engineers anyway. While some PMs are incredible and would no doubt be able to get good at vibe coding, the majority in my 25 years experience do not have the patience to get to a precision of requirements which is absolutely still a requirement to get anything out of AI.
"Programmers are the ultimate detail managers. All the tiny little details that nobody else wants to deal with wind up in our laps." - Robert C. Martin
PMs writing software seems like a terrible idea. Vibecoding still requires to be quite knowledge about the software engineering to actually get good results.
I am glad this essay was on the right side of the fence, otherwise I would have written it myself in response..
Our company is currently one of countless, where we just had a "get with the program" meeting with our PMs, where they showcased stuff they had added to our enterprise system in hours and days, and told us that they expected us to start delivering with the same tools techniques and speed..
Meanwhile, my team had spent that same working day before that meeting, trying to figure out why our production databases were suddenly getting hammered; it turned out some system was suddenly calling an expensive query endpoint 10k (10.000) times each hour, during business hours.
Guess 3 times whose vibe-coding adventures were responsible for those 10k calls :-/.
Other than that, I noticed during the meeting, that their vibe-coded demo added module to our enterprise system only dealt with happy-path of the data updates,
but would leave debris in our database for all the edge cases. Happy times. But heck yeah, let's just ram it straight into production. I wonder who will take care of adding support/clean up for the edge cases.
I agree - we should use the tools. But we should be mindful about how humans actually learn.
Some improvement ideas:
A prototype can help in the “Better communicate the idea/feature” part but it is even better if you let engineers do this as learning by doing is better than just being shown the result.
Vibe coding doesn’t help in “Understand the systems” - on the contrary, this is already a well known fact that vibecoding has negative effect in understanding the underlying system. It should be hardboiled documentation reading, trial and error which helps, otherwise you get only the illusion of competence.
With AI coding agents, reverse-engineering a codebase into a spec doc has become much more feasible, including details below the usual spec level. That gives PMs a practical way to understand systems more deeply than before, without having to land production diffs themselves. So to "Why should PMs code?" my take is: sometimes they should, but now there are multiple levels of involvement depending on what understanding is needed.
50 comments
[ 2.2 ms ] story [ 63.6 ms ] threadI think this is the main takeaway, but I'm curious how bad the PM must have been at communicating to begin with if this is necessary.
I noticed that AI evangelists really love to use word "fun" to describe anything they do with AI.
Claw people particularly seem really love to use that word when answering what practical or useful they do with AI agents. It's always something absurdly trivial followed by "and it's just fun!"
Don't really have any conclusion to this - just thought to share this observation.
Overall the rise of business types in tech company leadership has led to a drop in engineering quality, a rise in short term metrics, and fiascos like the COVID overhiring into multiple rounds of layoffs.
Vibed stuff can do whatever it wants, with some basic CI checks and Agent instructions
BUT if any of that crosses specific thresholds (writes to dangerous APIs, reads from unvetted sources, is deployed on the public internet), an actual developer MUST review the code - with the associated costs billed to the creator's BU.
Works fine, zero projects have been made public yet, but we have a bunch of Vibed internal tools in use that can't be accessed outside our internal network (or VPN) that are actually helping people do their work more efficiently.
I feel like PMs coding unlocks a whole new category of work, mainly addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressed. Time will tell how valuable these items are in the long term.
And I say this as a PM.
So you get to cowboy code, but I don't. I see how it is.
In startups anything goes. PMs and engs do whatever it takes to ship and scale the business. No one cares who's using AI in what way, as long as they're getting shit done.
In a place like Meta or Amazon, people also get more shit done with AI, but because these teams are huge, well-oiled machines, sudden productivity bumps or norm changes can drop overall productivity.
Totally agree with this post as long as it's limited to large, mature teams
So AI is merely letting me focus more on the other parts. Some developers don't like this. I kind of do.
Whoever gets the business best (and in detail) will likely be the best builders. It's "intuition as evals" that really matters in the end. You think Software Engineers or Product Managers are replacing Quants at trading shops anytime soon? Nope.
The key issue right now is that the models falter in the last mile, and the last mile is where you need the training and experience to make sure the thing that lands is production quality.
At some point in the next few years I believe the roles will merge. I suspect that PMs will be forced to specialize towards a discipline (design, data science, engineering, etc.) while engineers will also start to see more of their responsibilities covering former PM territory. Most engineers will probably become closer to “product engineers”.
Yesterday I had an interview, but I got rejected. They decided to go for a manager with a Claude subscription who vibe-coded a weather app.
This is the end of software engineering.
Please don't give up. This too shall pass. The bill for the worst excesses in this great experiment will come due. I can imagine the need to reckon with the growing technical and cognitive debt in a responsible way will be an existential issue for some enterprises. Somebody will need to step in and be the adults in the room.
There’s another path for PMs that the article and most of the comments don’t seem to mention.
Technical PMs are now in a great position to start their own companies. In the past, many were blocked or handicapped by the inability to code. With AI-assisted development, that barrier is much lower, which gives them a lot more leverage to build products themselves.
YOLO!
This was well into the "Move fast with stable infra" era of Meta, but clearly that still encouraged "Move fast and break things" for everything beyond infra.
PMs landing Prod diffs sounds like even more moving fast shall ensue.
PM vibe coding a prototype for demonstration purposes? Might be a better use of a designer or engineers time, but okay I could see it being valuable. PM vibe coding something to ship to production? Your title is now engineer and you are responsible for your change, otherwise this is a direct path to destroying the quality of your product and the integrity of its data.
Some software engineers would make good product managers, some product managers would make good software engineers, and the majority of both are best suited to their current job.
So yeah, I understand your point, and if I ran a cross-functional team like that I would hopefully hire well enough that I felt the same. So maybe to restate my thinking in a way that may be slightly less controversial: AI is eating a lot of the low-level mechanistic work that used to define being a software engineer, however I never believed that was where the value was for engineers anyway. While some PMs are incredible and would no doubt be able to get good at vibe coding, the majority in my 25 years experience do not have the patience to get to a precision of requirements which is absolutely still a requirement to get anything out of AI.
software engineers love to imagine that they have the only job you can't train yourself to do quickly, all evidence to the contrary.
Let's see if AI makes PMs care for details.
Other than that, I noticed during the meeting, that their vibe-coded demo added module to our enterprise system only dealt with happy-path of the data updates, but would leave debris in our database for all the edge cases. Happy times. But heck yeah, let's just ram it straight into production. I wonder who will take care of adding support/clean up for the edge cases.
Some improvement ideas:
A prototype can help in the “Better communicate the idea/feature” part but it is even better if you let engineers do this as learning by doing is better than just being shown the result.
Vibe coding doesn’t help in “Understand the systems” - on the contrary, this is already a well known fact that vibecoding has negative effect in understanding the underlying system. It should be hardboiled documentation reading, trial and error which helps, otherwise you get only the illusion of competence.