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.
If 24/7 availability is required, the company should simply hire someone to work those hours, perhaps in a different timezone if needed. Many mistakes are going to be the result of management pressures to "ship" too quickly, incentivizing cutting corners, which someone will have to deal with at some point, even if it's during their regular working hours.
Nah, the rota is large enough that it will likely be somebody else’s problem anyway and the chances are even if it does land on them they just won’t answer the phone.
Punishing mistakes with unpaid overtime has never been a good approach to quality. It just teaches management that they can get away with low quality because the engineers will pick up the pieces in their own time.
Funny story: I work at Meta and posted a version of this internally in response the bizarre pressure and support for PMs landing prod diffs (the response was very positive FWIW).
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.
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 got laid off at a job where this applied, then at another company got rejected because they cancelled the position altogether to use Agentic Coding by Microsoft instead.
Then I joined a small consultancy that just lets me build however I want. There's no reviews, no sprint reviews, no evaluation. They trust that you work on what is important.
While this is a very messy and unmaintained workflow, it is a lot nicer and I am honestly wondering if Scrum is even necessary when you're only with 4-5 devs. Maybe it is to streamline newcomers? Because it took a bit of time to gather all the project info, but after that it was pretty relaxing.
I don't know, the market has shifted so much that I feel like I should probably be contempt with what I have.
> it is a lot nicer and I am honestly wondering if Scrum is even necessary when you're only with 4-5 devs.
Scrum is so woefully misunderstood.
It makes sense for small teams (yes, those 4-5 devs), if — and that's a big if — they work together on a single product. It is intended for developers to coordinate with each other, and also provides feedback loops for reality checks and for improvement of collaboration.
If those 4-5 developers work independently from one another, don't have to coordinate, don't need business to tell them what, out of various options, is the most important thing to work on right now, and don't need feedback from users to correct them along the way, then of course they don't need scrum.
Yeah, it's basically just formalized rules for communication, and I've been on teams where it worked great
I think it's awful when people follow it slavishly -- you chuck out anything that doesn't fit your team. And yeah, in the example you gave, it's a terrible fit lol
I have some stakeholders that do not know what they want and can't define it, so in desperation I dragged them thorough making fucking user stories -- user stories --and oh my god they loved it lol
They immediately started trying to apply it to everything too. I have regrets.
In my view, Scrum is a way to force dysfunctional teams to have some process, it is not useful for a team that is already delivering and working in a samll-a agile manner.
Using just one $200 Claude subscription? What is that? 2024? Managers? Get on my level, son. It’ll be one man unicorns, new breed of CEOs running army of openclaws. I’ll have you fucking know that I’ve just launched “build me a next unicorn” prompt and 1000 agents have been running nonstop for a week. See me at the top of the AngelList, chump. Though I’ve probably won’t see you while you collect your unemployment check and food stamps.
"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
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'd say the average engineer would be much more capable of learning to be an average PM than vice versa.
It's a completely different skillset. Practice shows, that most Engineers simply do not want to be PMs or find out about that after making the change and regretting it.
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.
same, it sounds more like common sense than spicyness? i vibecode prototypes and visualizations but pushing any more than that would just add chaos to the chaos we're trying to avoid
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.
Nor do I know what an "eval" is, or which of the no less than three different deacronymings of "PM" (that I know of, thus far) FB uses or what that role would mean to them.
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 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”.
Which would be pretty much full circle at that point. When I started out, it was common for developers to do "product management", there wasn't a specialised role for it yet. You had developers and maybe project managers (generally also developers) and testers, and that was about it. Management would talk to developers about their strategy and problems, and they'd figure out what to build based on that.
I'm pretty weirded out by some "modern" teams where you have product managers spoon feed specifications to developers, and developers focusing on nothing but the code they need to write to do exactly as they've been told.
Product managers are in a weird place. They wear a ton of hats and do entirely different jobs based on where they work. They're often really valuable, but I have some trouble putting my finger on what makes a good one. If they're good at whatever it is they end up doing, that's good.
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.
So… I can do it all. Product manage, code, lead a team, even be my own designer in a pinch.
But that’s far too much work and context switching for one person. Someone will try, but the reason you tend to build teams of specialists is to let people focus even when they can do lots of different things.
From what i've read, tech is over represented by folks on the spectrum who struggle with focus and multitasking. I see this new trend where you are being asked to increasingly do more and more to be an especially difficult burden to bear for those who self select for careers in programming.
I've worked without a product manager before and it was not a pleasant experience.
Without a PM: I conducted customer interviews, wrote up product requirement docs (PRD), and iterated with design on the mocks. On top of that, I had to implement the whole feature (while tweaking things with a designer), and also juggling another track of technical work.
This would be fine if I was a founding engineer, but I'm not and wasn't being compensated enough for the extra workload. And sure, now with LLMs the coding portion would be smaller, but there would still a lot of context switching and one might not able to do technical deep dives into things with all the meetings. All those meetings.
I hear you, a lot of engineers have been there. Things are changing though, roles are evolving and the org chart is starting to flatten.
A couple of things worth separating: strategic direction in most orgs is already handed down from the VP or exec level, the PM is usually executing on that mandate.
Now that coding agents exist, both the PM and the engineer end up prompting a coding agent. So, over time, the roles converge and product ownership just becomes part of building.
My hotter take: All 3 of the engineer, PM and designer will all assume the other 2 are optional, in reality all 3 and the entire company they work for will be optional in most cases.
I think that all PMs will need to get onto the engineering, design, or research ladder. We are already seeing companies eliminate the function here and there and I expect the trend to continue.
This seems crazy to me. I am a PM and I am busier than ever. People are waking up to the idea that code is cheap and things can change faster now, so deciding _what_ to make and prioritise in the deluge of ideas coming to prod is becoming completely essential.
As a developer, I don't see the PM as a boss or planner. It's the guy that handles the communication with all the people that don't understand what I say and ensures that they don't annoy me.
A PM is not optional when you want to have developers that have time to code and don't get distracted by thirty people that all want something else and all ASAP.
That sounds more like a project or engineering manager role. Work environments obviously vary, and sometimes roles are assumed to counter dysfunction. But the PM here is the product manager, which owns the product direction. The argument is that their role can now venture into building. My comment extends it further that they can actually become the builders, absorbed into engineering and design.
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.
You make a better product if you plan it out first. That’s part of a PM’s job so it’s natural fit when the ai does the coding. The code may not be ideal but it’ll have the structure you can improve on.
> You make a better product if you plan it out first.
Maybe. Maybe not. Sometimes you have to see it to understand what's wrong / how can it be improved. It's one of the actual benefits of pre-religious agile - have something in front of your sponsor ASAP, adapt to their feedback. This loop can be made faster, but you'll still need some expertise at every level. Just not so many bodies.
Entire product or a feature for a product? Sometimes you just want to test an idea and vibe coding works well for that in the very short amount of time it takes now. Product market fit, user testing, engineering, those can come after the hunch.
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.
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
100%. PMs at startups already wear many hats and AI helps them do that even better.
But to this sister comment's point, I do think that the dedicated PM role will vanish and the classic BigCo PM will need to look a lot more like the startup one.
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.
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?
The general point is that separating PM and eng doesn't make sense any longer. Which subsumes which is an interesting debate.
Your argument that 4.6 Opus makes the engineering skill set useless is totally false and maybe shows you haven't built anything complicated, but it is possible that Opus 5.2 will get there.
Opposing Hot take (possibly missing the joke....):
Coding was never the most valuable skill a software engineer contributed. Socially-capable engineers are going to be far more likely than PMs to 'shine' when agents can write code and engineers are afforded more time to engage with busines/customers/stakeholder/domain experts.
If my experience is any reflection of the norm, the avg PMs greatest value has never come from effectively determining the value or requirement of a product or translating requests/feedback to meaningful deliverables. It's been in providing cover (time) for engineers that could do the same job better, but are irreplaceable in the development process and so are more rare/valuable spending time doing development. When engineers no longer need to write code, they are a more direct line to effectively solving "Product-Led" business needs with technical solutions than a typical PM will be.
Just wait what you pay for the tokens when the enshittification has started and the bubble bursted. In some years you will see that no new engineers are coming along and your products are dying on edge cases that the AI can't handle all together.
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.
An easy correction is to only merge PRs from folks who are on the on call rota.
Those not on rota can either join or have their PR receive heavy scrutiny
If 24/7 availability is required, the company should simply hire someone to work those hours, perhaps in a different timezone if needed. Many mistakes are going to be the result of management pressures to "ship" too quickly, incentivizing cutting corners, which someone will have to deal with at some point, even if it's during their regular working hours.
Nah, the rota is large enough that it will likely be somebody else’s problem anyway and the chances are even if it does land on them they just won’t answer the phone.
Punishing mistakes with unpaid overtime has never been a good approach to quality. It just teaches management that they can get away with low quality because the engineers will pick up the pieces in their own time.
Funny story: I work at Meta and posted a version of this internally in response the bizarre pressure and support for PMs landing prod diffs (the response was very positive FWIW).
which workplace group did you post it to?
I don't remember the exact name, but the one about AI productivity. It should be trivial to find my name from my handle, so just look at my profile.
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.
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.
This is the end of software engineering.
I got laid off at a job where this applied, then at another company got rejected because they cancelled the position altogether to use Agentic Coding by Microsoft instead.
Then I joined a small consultancy that just lets me build however I want. There's no reviews, no sprint reviews, no evaluation. They trust that you work on what is important.
While this is a very messy and unmaintained workflow, it is a lot nicer and I am honestly wondering if Scrum is even necessary when you're only with 4-5 devs. Maybe it is to streamline newcomers? Because it took a bit of time to gather all the project info, but after that it was pretty relaxing.
I don't know, the market has shifted so much that I feel like I should probably be contempt with what I have.
> it is a lot nicer and I am honestly wondering if Scrum is even necessary when you're only with 4-5 devs.
Scrum is so woefully misunderstood.
It makes sense for small teams (yes, those 4-5 devs), if — and that's a big if — they work together on a single product. It is intended for developers to coordinate with each other, and also provides feedback loops for reality checks and for improvement of collaboration.
If those 4-5 developers work independently from one another, don't have to coordinate, don't need business to tell them what, out of various options, is the most important thing to work on right now, and don't need feedback from users to correct them along the way, then of course they don't need scrum.
Yeah, it's basically just formalized rules for communication, and I've been on teams where it worked great
I think it's awful when people follow it slavishly -- you chuck out anything that doesn't fit your team. And yeah, in the example you gave, it's a terrible fit lol
I have some stakeholders that do not know what they want and can't define it, so in desperation I dragged them thorough making fucking user stories -- user stories --and oh my god they loved it lol
They immediately started trying to apply it to everything too. I have regrets.
In my view, Scrum is a way to force dysfunctional teams to have some process, it is not useful for a team that is already delivering and working in a samll-a agile manner.
Scrum is just one of the early signs for me to start looking for a new job
Using just one $200 Claude subscription? What is that? 2024? Managers? Get on my level, son. It’ll be one man unicorns, new breed of CEOs running army of openclaws. I’ll have you fucking know that I’ve just launched “build me a next unicorn” prompt and 1000 agents have been running nonstop for a week. See me at the top of the AngelList, chump. Though I’ve probably won’t see you while you collect your unemployment check and food stamps.
can't tell if you are serious or not.
It should be obvious, particularly from this line:
> It is truly the next thing, and the future, probably happening in the next 2 years, or in 2 years in 2 years.
> by just telling LLMs to make an app or to make money or something.
Again, that is literally OpenAI's business model: burn money building ChatGPT until it's smart enough to tell them how to be profitable.
"That's a bold strategy, Cotton, let's see if it pays off for 'em."
HAHAHAHA. Dodged a bullet. Do you really want to work in a enterprice where HR is so dumb to buy this shit? Just think, they hire all your colleagues.
"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
Let's see if AI makes PMs care for details.
A lot of details are already beginning to fall through to the AI’s lap anyways.
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'd say the average engineer would be much more capable of learning to be an average PM than vice versa.
It's a completely different skillset. Practice shows, that most Engineers simply do not want to be PMs or find out about that after making the change and regretting it.
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.
And I say this as a PM.
same, it sounds more like common sense than spicyness? i vibecode prototypes and visualizations but pushing any more than that would just add chaos to the chaos we're trying to avoid
You'd be surprised. See this sister comment: https://news.ycombinator.com/item?id=47242372
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.
I get that "landing a prod diff" means "get stuff in production"? I never read this before. Is this slang unique to meta?
Nor do I know what an "eval" is, or which of the no less than three different deacronymings of "PM" (that I know of, thus far) FB uses or what that role would mean to them.
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 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”.
Which would be pretty much full circle at that point. When I started out, it was common for developers to do "product management", there wasn't a specialised role for it yet. You had developers and maybe project managers (generally also developers) and testers, and that was about it. Management would talk to developers about their strategy and problems, and they'd figure out what to build based on that.
I'm pretty weirded out by some "modern" teams where you have product managers spoon feed specifications to developers, and developers focusing on nothing but the code they need to write to do exactly as they've been told.
Product managers are in a weird place. They wear a ton of hats and do entirely different jobs based on where they work. They're often really valuable, but I have some trouble putting my finger on what makes a good one. If they're good at whatever it is they end up doing, that's good.
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.
So… I can do it all. Product manage, code, lead a team, even be my own designer in a pinch.
But that’s far too much work and context switching for one person. Someone will try, but the reason you tend to build teams of specialists is to let people focus even when they can do lots of different things.
Hey you forget sales and marketing. Just do that also.
Luckily I suck at that!
From what i've read, tech is over represented by folks on the spectrum who struggle with focus and multitasking. I see this new trend where you are being asked to increasingly do more and more to be an especially difficult burden to bear for those who self select for careers in programming.
I've worked without a product manager before and it was not a pleasant experience.
Without a PM: I conducted customer interviews, wrote up product requirement docs (PRD), and iterated with design on the mocks. On top of that, I had to implement the whole feature (while tweaking things with a designer), and also juggling another track of technical work.
This would be fine if I was a founding engineer, but I'm not and wasn't being compensated enough for the extra workload. And sure, now with LLMs the coding portion would be smaller, but there would still a lot of context switching and one might not able to do technical deep dives into things with all the meetings. All those meetings.
So don't overlook your PM.
I hear you, a lot of engineers have been there. Things are changing though, roles are evolving and the org chart is starting to flatten.
A couple of things worth separating: strategic direction in most orgs is already handed down from the VP or exec level, the PM is usually executing on that mandate.
Now that coding agents exist, both the PM and the engineer end up prompting a coding agent. So, over time, the roles converge and product ownership just becomes part of building.
My hotter take: All 3 of the engineer, PM and designer will all assume the other 2 are optional, in reality all 3 and the entire company they work for will be optional in most cases.
Good PMs are not optional. Most PMs are.
How are you defining optional?
Companies without any product managers, much less good ones, are putting out profitable products all the time.
You just need one of them. It's probably the engineer.
I totally agree (as a PM of ~10 years).
I think that all PMs will need to get onto the engineering, design, or research ladder. We are already seeing companies eliminate the function here and there and I expect the trend to continue.
This seems crazy to me. I am a PM and I am busier than ever. People are waking up to the idea that code is cheap and things can change faster now, so deciding _what_ to make and prioritise in the deluge of ideas coming to prod is becoming completely essential.
One thing LLMs don't have is taste. That's on me.
They don't seem to have taste when it comes to engineering either, but tbh 'taste' is a computable function, and will eventually be learned.
As a developer, I don't see the PM as a boss or planner. It's the guy that handles the communication with all the people that don't understand what I say and ensures that they don't annoy me.
A PM is not optional when you want to have developers that have time to code and don't get distracted by thirty people that all want something else and all ASAP.
That sounds more like a project or engineering manager role. Work environments obviously vary, and sometimes roles are assumed to counter dysfunction. But the PM here is the product manager, which owns the product direction. The argument is that their role can now venture into building. My comment extends it further that they can actually become the builders, absorbed into engineering and design.
exactly - a PM's job is to sail the high seas of wherever you sit in the org chart and general corporate political landscape.
True, but I think corporate internal politics is changing.
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.
The linked article on evals is even more interesting.
Thanks! I posted that one almost a year ago and it blew up on LinkedIn of all places but was totally ignored on HN.
I think technical PMs or product oriented developers are the future most valuable people.
You make a better product if you plan it out first. That’s part of a PM’s job so it’s natural fit when the ai does the coding. The code may not be ideal but it’ll have the structure you can improve on.
> You make a better product if you plan it out first.
Maybe. Maybe not. Sometimes you have to see it to understand what's wrong / how can it be improved. It's one of the actual benefits of pre-religious agile - have something in front of your sponsor ASAP, adapt to their feedback. This loop can be made faster, but you'll still need some expertise at every level. Just not so many bodies.
Entire product or a feature for a product? Sometimes you just want to test an idea and vibe coding works well for that in the very short amount of time it takes now. Product market fit, user testing, engineering, those can come after the hunch.
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.
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
100%. PMs at startups already wear many hats and AI helps them do that even better.
But to this sister comment's point, I do think that the dedicated PM role will vanish and the classic BigCo PM will need to look a lot more like the startup one.
https://news.ycombinator.com/item?id=47242699
> Why should PMs code? Better communicate the idea/feature
I 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.
Communicating a feature with a doc or mock can be really hard. A prototype can make things much clearer to a broad audience.
> Fun!!!!!
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.
Whenever someone says “Fun!!!!” when it comes to LLMs/Claws I can only imagine the author having that obnoxious face: https://knowyourmeme.com/memes/soy-boy-face-soyjak
It's probably on the script they've been given
Weird take. Coding is fun (and has been since before AI). And vibe coding is fun in an entirely different way.
What's weird about it? I'm not disputing that it might be fun for vibe coders. Just that they seem to really like using that particular word.
I love coding and it is fun for me. Vibe coding on the other hand - not fun at all. It feels to me like playing slots.
But then again, I never liked gambling.
When your only defense is “I’m just having fun!!!!” after dumping your toxic waste in the net, it’s not a weird take.
Not weird at all. It's a common motte & bailey tactic, when your defence of the utility of something fails you can just say you do it for fun!!!!!!!.
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?
Most seniors are hired for their code readability and real-life experiences with real products and problems. Not for code writing ability.
> With Claude 4.6 Opus, the engineer skill set is no longer useful.
The most recent models have spooked me into believing this is a thing that is likely to be true at some point, but it ain't true yet.
This is kind of like the reverse of the sister comment, which I agree with: https://news.ycombinator.com/item?id=47242699
The general point is that separating PM and eng doesn't make sense any longer. Which subsumes which is an interesting debate.
Your argument that 4.6 Opus makes the engineering skill set useless is totally false and maybe shows you haven't built anything complicated, but it is possible that Opus 5.2 will get there.
Hotter take: why even hire someone at all? Just dial up FOMO and threats, and pile up more work on peons that you own already.
If that were true, why would they need a PM ether?
Agents would research and identify requirements on their own, observe customer interactions and monitor for trends. Taste.md downloaded via LoveFrom
Opposing Hot take (possibly missing the joke....):
Coding was never the most valuable skill a software engineer contributed. Socially-capable engineers are going to be far more likely than PMs to 'shine' when agents can write code and engineers are afforded more time to engage with busines/customers/stakeholder/domain experts.
If my experience is any reflection of the norm, the avg PMs greatest value has never come from effectively determining the value or requirement of a product or translating requests/feedback to meaningful deliverables. It's been in providing cover (time) for engineers that could do the same job better, but are irreplaceable in the development process and so are more rare/valuable spending time doing development. When engineers no longer need to write code, they are a more direct line to effectively solving "Product-Led" business needs with technical solutions than a typical PM will be.
Buddy, when the engineering skill set is "no longer useful" you'll be living in a cardboard box at least a couple of years before that ever happens.
> Why are we hiring people with code writing ability when code writing ability has no value anymore?
Is this sarcasm? You don't think there is any utility to understanding code?
Edit: you got me haha.
LOL....thats more a cold one.
Just wait what you pay for the tokens when the enshittification has started and the bubble bursted. In some years you will see that no new engineers are coming along and your products are dying on edge cases that the AI can't handle all together.
Edit: Ok, don't got the sarcasm :D