Discussion

Daniel D. McKinnon

raviisoccupied: 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.

foolserrandboy: Isn’t this the type of work interns used to do? Prototype hackathon type things?

boondongle: In a real, large company, no. Interns generally still get the work that is prioritized but often too simplistic to spend Senior Dev time on to simplify Dev's job. For better or worse, Development represents what the executive level prioritizes often defined by Product Management/Program Management.There's a whole other level of requests which for political or cultural reasons don't get touched even if there's a great internal rate of return to them or they reflect real bottlenecks elsewhere in the company.Ideally any/every company would prioritize by actual internal rate of return but that's just not what most of us observe.

dasil003: 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.

neonstatic: > 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.

dasil003: I agree but my point stands, even if they don’t want to, an engineer at least has the precision of thought to specify how a product could work. Many PMs simply don’t have this, so asking them to become vibe coders is a hopeless waste of time.

Bridged7756: 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.

intelVISA: I appreciate this is satire, or marketing, but I'll engage: in this scenario how is the SaaS generating millions if anyone can just prompt their own?

zombot: Apparently it never occurs to the Believers to ask this exact question. They will pay an expensive subscription to vibe-earn money without working.

gedy: One of my LinkedIn connections is at a place where the leadership brags about how easy it is to prompt their features. I'm like: are you f-ing stupid?

gedy: Maybe, but why have (frankly not that intelligent/logical) PMs doing dev work vs the dev/eng types being the PMs with AI help?

ef2k: 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.

veggieroll: > With clear quarterly goalsThis requires a quality of product/program management and upper management buy-in that is rare in my experience.The dynamic I've experienced is upper management giving the same incompetent teams projects over and over, having month after month of meetings with no deliveries and no real progress on the deliverable, and then eventually having to scramble and find someone else who can actually accomplish their goals.Either that or so many things are broken that there's no possible way to prioritize beyond a few weeks because you can't let attention dip from any one spinning plate for too long or it'll fall.

munchbunny: 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”.

fhd2: 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.

munchbunny: > If they're good at whatever it is they end up doing, that's good.As a former PM (now an engineer), I think that's pretty much it. Teams and companies will vary a lot in terms of what they want the PM's to do, with some common patterns emerging, but as long as the PM's do the work well then the team is much better off. The key issue is how much you can trust the PM to hold up their end of the project.A common theme I've noticed among good PM's: good judgement. When the team can trust the PM's judgement, the whole team flows better. When the team can't trust the PM's judgement, the PM is worth negative bandwidth.

dogleash: >addressing the long tail of cool ideas/small optimisations that ordinarily would not be addressedSo you get to cowboy code, but I don't. I see how it is.

keeda: 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.

polotics: The quip "move things and break fast" is from which year btw, do you remember?

keeda: Hah, not sure of the origin, but I do recall seeing it at some point and I think it was this HN comment: https://news.ycombinator.com/item?id=41581370

jwilliams: I read takes like this and I feel like it's gatekeeping.I love writing software. I love that others are now getting to share this.I think the issues here are valid. Equally there is lots of hard engineering work to reduce these issues. That's where I'm putting more energy.My scale is decidedly non-Meta, but we're investing to make the whole team able to get their own PRs up. It's not been without it's bumps, but on the whole I think it's been transformative for everyone.

bluefirebrand: > I read takes like this and I feel like it's gatekeepingYeah man, insisting on good engineering practices instead of "vibes" has always been gatekeepingThat's the actual point of engineering credentialsWhat are we even doing here

DiscourseFan: This was before the bot could competently code things. Software development is now a very different beast, and yes while there have been some very stupid and irresponsible uses of this new technology, many others are integrating it effectively into their workflows.

bluefirebrand: > This was before the bot could competently code thingsAgree to disagreeGetting something working is the absolute bare minimum, it's not "competent"

DiscourseFan: The fact that it can, and often does, get things working, sometimes even well, is evidence enough. It can't do some things, it can easily do others, and knowing which is which is very important nowadays.

bluefirebrand: > The fact that it can, and often does, get things working, sometimes even well, is evidence enoughSo can my 12 year old nephew, but we aren't racing to put him in charge of software development in professional settings

donkers: Way to dunk on a whole group of people there. As an engineer turned PM, some of us are intelligent and logical and don’t want to do this stupid shit. And some engineers should never be PMs, I’ve seen some real disasters where engineering tried to play that role.

sdevonoes: Simply put in your resume that you are a manager? And learn how to vibe code a weather app?Wouldn’t be the first time I “lie” in my CV about my skills (“lie” in quotes because I can learn pretty fast; I know the fundamentals)

BoneShard: Don't do that if you're in the US. I was laid off and finally got two offers, both places ran a background check and had all the information - my previous title, precise start - end time, etc. I've talked to one hiring manager and he told me that they had a lot of offers revoked due to failing these background checks recently.

shubhamintech: The best point in this thread: "intuition as evals." That's actually the crux. PMs have context about what the product should do that engineers often don't, and that intuition IS an eval. The problem is it doesn't scale once the system has millions of conversations no one is reading. The empathy from vibe coding is real, the prototype-as-spec culture is where it breaks down for AI products specifically.