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.

lrakster: We are a much smaller team than Meta and all-in with agentic-coding. But even we are seeing value in specialization of roles. There is so much to be done. Why have PMs work with coding agents to code the product when they aren't going to do as good a job as an Dev will? Have the PMs do research, competitive analysis, mockups, prioritization, etc

array_key_first: The SaaS comes with a complimentary blow job.In the future, prostitutes no longer work the street corner and you no longer roll up. No no, prostitutes vibe code apps nobody asks for with subtle hints in it that they're offering their services. Then, clients buy it as a proxy.Law enforcement isn't prepared for this!

aurareturn: I think technical PMs or product oriented developers are the future most valuable people.

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

array_key_first: The entire evolution of software engineering has been focused on how to plan a product. Because 99% of the time the problem IS NOT writing code. It's writing the wrong code. The wrong requirements, for the wrong people, for use cases nobody cares about.

akshay2603: I am one of those PMs at a big tech that just shipped a PR in prod:My take: 1. Doing this moves my team faster. I now use sourcegraph MCP all the time to file much better bugs. And when the actual bug fixing TAT is larger than bug filing TAT, I rather just do it myself. My engineers appreciate it, truly. 2. This not only helps me do bug filing but just get comfortable with code. And this improves my PRDs, my MVPs and my overall thinking. There is no way that I can do this in isolation. I have to get comfortable with code and that involves shipping the occasional PR. 3. This improves my craft. I am obsessively shipping on the side. The codebase for my personal side projects is manageable. I would love to ship at work as well but that's not doable because of codebase complexity and the inability to read code. However, traditional product management is collapsing and this is the new normal.

array_key_first: Code is extremely evil because you can accidently write ++a instead of a++ and create a bug so severe and so hidden you bring down the whole company.I work at a company that does payroll software. Its not atypical for me to spend an entire week to write one singular line of code. Because in order to write that line and be confident it's correct, will always be correct, and cannot have any side effects, I have to read and understand so much other code.The older the codebase is, the worse it gets. The larger the codebase is, the worse it gets. The more valuable your customers are, the worse it gets. That's why free consumer software is riddled with bugs and nobody cares.

noah-cavoli: Hard disagree. Software engineering was never about writing code. It's not a completely different beast, not really. It's just way cheaper to write code now. And anyone who has been doing this for a long time already knows, more code usually = more problems

jmull: Don't ignore the context here. These are people hired to develop software for a company. They have an obligation to do so efficiently, with sufficient quality, and while balancing the company's short term and longer term business needs.I think it's great that software development has been opened up by LLMs. Everyone should at least try it, IMO.But your company's source isn't your personal playground and you shouldn't treat it as such.

jwilliams: I agree that a company’s codebase isn’t a playground and I know+feel those obligations.My reaction is more to the broader tone of some of these discussions. In my experience engineering cultures can become quite dogmatic or obstructive, and that can block improvements just as much as the opposite problem.At our definitely-non-Meta-scale, we’ve been experimenting with letting more of the team get their own PRs up with LLM help. Overall it’s been pretty transformative. Interestingly, people tend to work on QoL and polish improvements that many SWE workflows often don’t prioritise or have time for.There are outliers of course, but we learn, revert, and move on. If the outcome somewhere like Meta is PMs building nonsense, that feels more like a deeper systemic issue than something inherent to opening up the codebase.

noah-cavoli: There's a reason engineers tend to be dogmatic about things. It doesn't just come from nowhere. Is it misguided sometimes? Yes. But far more often than not, there are very good reasons why those with experience seem "dogmatic and obstructive".

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

purrcat259: 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

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

snypher: I think they meant to say that if the person isn't on the A-team call list, they aren't entitled to contribute without scrutiny.

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

AlexandrB: Scrum is management consulting companies trying to keep their job by turning something that would make them irrelevant (the agile manifesto) into something that requires tons of billable hours and useless qualifications like "scrum master". Seems to be working great for them.

SAI_Peregrinus: The agile manifesto is about how to run a consulting company. "Customer collaboration over contract negotiation" is not something non-contracting software teams have to worry about, customer collaboration is important but there's no contract negotiation to prioritize it over.

malnourish: I've worked at three very different companies where at least one member of the software team had to essentially negotiate for their project's budget and scope (and tacitly their jobs in some cases).

jpfromlondon: You're right, but you're going to be inundated with"but real scrum has never been tried" types.

p_v_doom: > "but real scrum has never been tried" types.Im one of these people. I do think for real that what most companies do is basically project management that wears the skin of scrum, and in most organizations beyond a certain size having that type of agile work and flexibility is basically impossible.

gray_-_wolf: > unpaid overtimeThrough European lenses this part seems insane. It is work, so pay me for it :) Every oncall rotation I was part of ever was paid, is the "unpaid" part a US thing, or was I just lucky?

titanomachy: Working as a SWE at Meta in the US pays 3-5x more than a European tech job (outside of Switzerland). They are paid for it.Paid oncall in US big tech is the exception rather than the norm (notably, Google has paid oncall)

gzread: How does it work out with cost of living?

titanomachy: This is of course a complicated question. The US has many tax jurisdictions and widely variable cost of living, and jobs vary a lot. But I could compare, say, a Google engineer in Paris vs Seattle.A Google senior software engineer in Paris earns €168k per year (according to levels.fyi) and takes home €96k after a 43% effective tax rate. A Google senior engineer in Seattle earns €336k and takes home €239k after 29% taxes, a 2.5x increase in take-home pay. According to Numbeo, cost of living in Seattle is 15-25% higher.Of course, in America you have to fund your own retirement. As long as the pensions plans remain solvent, "savings" are a lot less important in Europe.Anecdotally, I know people who were able to opt out of working altogether after 10-15 years in a large tech company in the US. I don't think this is common in Europe.

sensanaty: What use is earning all that extra cash if you're working yourself to death with no way to enjoy the money? I work in a large international org and despite the people in the US earning a lot more than their EU counterparts, they also pretty much universally seem more miserable, are working all sorts of odd hours, have basically no holidays (the amount of times I've gotten a "Vacation again!?" questions from people in the US is insane to me), have to stress more about doctors visits and stuff like that.I've had a lot of opportunities to be earning a lot more than I do now by moving to the US, but seeing the state of the US I'm more than happy with my 32 hour contract and 5 weeks of vacations that I get to actually enjoy.

titanomachy: It's a reasonable question, and one that I've debated at length with friends, but which cannot be addressed satisfactorily in a brief exchange of internet comments :)During the golden years of big tech in the states, when employee retention was king and it was pretty much impossible to fire someone who wasn't completely useless, I think it was a pretty good deal. Although East Coast work culture has always been pretty intense as you describe, a lot of West Coast people I know had good balance between work and everything else. Some people chose to work very hard and chase promotions, and others chose to go home early and spend their time with family or doing hobbies, and both ways were considered acceptable. The better companies offered 5 weeks of vacation, and people would go completely offline during that time, although some people would have to be cajoled by their managers to actually take the time off.Recently it feels like things in the US have gotten much more intense and stressful, although the pay is as high as ever it does feel less worth it. People compete with their coworkers not just for promotion but for survival. There are still pockets where you can have both high pay and some sense of job security, but they are much scarcer than before.

theshrike79: [delayed]

adampunk: >I'd say the average engineer would be much more capable of learning to be an average PM than vice versa.software engineers love to imagine that they have the only job you can't train yourself to do quickly, all evidence to the contrary.

dasil003: I don't know how that relates to what I said, and it's certainly not something I believe. Personally I don't think any form of knowledge work can be learned quickly in 21st century, otherwise it would have been automated away already (well before the current wave of AI that further accelerates the trend). That goes for product management, design, operations, strategy equally to software engineering, data science any other technical disciplines.

adampunk: It relates directly to what you said. You said you thought that it would be pretty easy to teach an engineer to be a project manager and pretty hard to teach a project manager to be an engineer. That is just exactly the kind of directionality I pointed out.

dasil003: You're putting words in my mouth. Also, I was talking about Product Managers, there's a word of different between that role and Project Manager (or Program Manager).

brumar: I get that "landing a prod diff" means "get stuff in production"? I never read this before. Is this slang unique to meta?

bthrn: Diff is Phabricator terminology. A diff is roughly equivalent to a Pull Request in GitHub.

maplethorpe: 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?

robotswantdata: 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

maplethorpe: A PM's job isn't the same as coding. It's a lot more than just writing words.

nachocoll: The PM vibe coding scenario described here cuts to the heart of a real accountability problem: when the person shipping code doesn't understand it, can't debug it, and won't be around when it breaks in production, who's responsible?This isn't just a PM problem — it's the same dynamic playing out at every seniority level with AI-assisted coding. The speed feels real, but the ownership gets blurry.A few of us have been working on formalizing exactly this challenge: the Agile Vibe Coding Manifesto (https://agilevibecoding.org). It builds on the original Agile Manifesto to address environments where AI is generating significant amounts of code, and its second principle is simply "Humans remain accountable for software systems — regardless of how code is produced."The manifesto doesn't argue against AI-assisted development. It argues that speed of generation has to be matched by clarity of intent, traceability of decisions, and genuine human accountability for what gets deployed. Whether you're a PM shipping a quick tool or a senior engineer steering an agent, the accountability question doesn't go away.