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.
The fact that they are PMs is a tragedy of circumstance, not a moral failing. If they are willing to go on-call for their work they will lose that childlike innocence and become engineers very quickly.
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.
Through 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?
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.
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.
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.
>Of course, in America you have to fund your own retirement.
Isn't social security a thing? Plus employer funded 401K also?
>As long as the pensions plans remain solvent, "savings" are a lot less important in Europe.
"As long as" is doing a lot of lifting here, and that's enough if you're lucky enough to own your own property and not have to pay market rate rent at your old age.
Social Security alone will, at best, slightly mitigate poverty. 401Ks are generally employee-funded, with some firms providing matching funds, especially during good economic times and where the firm is in a field where the main area of labor relied on relatively scarce so that there is competition for talent.
EDIT: The line about social security is a little inaccurate in the extreme case; its actually technically possible to reach a moderate income ($62k/year) on Social Security, if you have a long enough working career (35 years or more) earning at the maximum taxed wages for Social Security (currently $185k+) and claim at or beyond the age that maximizes the benefit calculation (70 years).
In the US it's common to either negotiate 'differential' pay for the responsibility, or as one might see in this thread, get suckered into it for free.
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.
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).
Quick everyone, create decoy repos for them to vibe in. When the feature doesn't appear "oh feature gate system has an incident try tomorrow". Even better make the decoy repo have an insufferable pipeline that always breaks and get them in a loop trying to fix it. An adveserial "red team" LLM can keep it broken! But tantalizingly with different problems so progress is felt.
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.
> Leadership claims they are aware of Goodhart's Law, but their actions show otherwise.
Leadership will cherry pick metrics that are easy to game so they can make the next promo, and do say at the expense of company resources. This is a problem in every big corp not just tech.
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.
Move fast and break things. If it works well for a startup with 3 users and 1 developer, why not do the same for our critical infrastructure company? Openclaw, fire my engineering team and bring me more alcohol.
Everybody and their mom loves to believe they're the hot young stuff on the block.
Even with a company like, say, Meta, they have more freedom to make mistakes than 100% of enterprise companies. Nobody cares too much if Facebook goes down or is slow or something.
But if you're selling to another business, they're gonna have your ass for breakfast for even the tiniest mistakes. As they should, they're paying you a lot of money!
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.
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.
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.
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.
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).
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.
> 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.
Woah, what is that 2026? Emulating the economy using human flesh is obsolete. Just emulate the entire C-suite with the fleet of agents in the latent space of LLMs running on the orbital datacenters, powered by the same solar energy that used to keep humans warm.
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.
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.
I don't see this happening. Even today, I can place a bet on a prediction market that nobody women will give me a blow job tonight, a lady of the night then places a counter bet wagering that I will, and shows up at my house.
Services in individual apps are a thing of the past.
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.
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.
>I have my wife vibe coding programs for her medical company. Its great. Saved her $200/mo so far from ADP
>I have tried encouraging others to vibe code, and they don't even know basic things like how to save files as .html... At best I've taught them to disagree with the AI and tell the AI "Make me a file I can click on".
>Being precise on the steps to solve a problem can be the difference between 1 shot success and floundering.
>Maybe do something that involves physical space and programming.
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.
Agree. Also as a PM, one of the most important things you can do, once you've decided or understood "this is the most important thing we can be working on," is to sell that vision internally so you have high alignment and thus can move fast with shipping (i.e. Sales, Marketing, Legal et al are all on board and ready to help you get to market).
SHOWING internal folks something is always more compelling than words on a slide. So if you have good alignment with your Engineering team that the thing is possible, you can go off on your own and vibe-code something to garner internal alignment... and then throw it away and let your Engineers build the real thing. And they won't have to spend extra time on a PoC that's only meant to show off internally.
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
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.
>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.
Maybe your cool ideas/small optimisations were not addressed because of how they would impact the system as a whole. It's the job of the engineer to keep things running and there are a lot of places that can wreck (slowly of quickly) the product if modified wrong.
One thing missing from this discussion is the blast radius of the product or repo in question.
Let PMs land new widgets on internal dashboards or CSS changes in internal tooling. The same way we should be aspiring to build tools for devs to merge these same changes with minimal test plans. You wouldn't call a mechanic to help you turn on your windshield wipers.
Changes in high-risk environments should be gated for people who actually know what they're doing. That high bar should remain high.
100% agreed. I'm a Program Manager and have been writing tooling for my own internal workflows for years (like Monte Carlo-based forecasting tools), or program-adjacent low-stakes stuff (like an API to generate a WSJF score based on a fields inputted into Asana, since it couldn't do that itself).
But I'm not about to send a PR for fixing production bugs even if I have decent high level context. Nobody has better context than the devs working on it every day.
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.
Hype will come down once scalability problems start to show up. It's the same with every new technology: people get excited from the results of their PoC not realising that a PoC is smaller in scope and therefore has better chances of working. Then you try to translate that to a proper project and it all falls apart.
Agentic coding will accelerate things, but you'll still need the engineers.
Power tools didn't get rid of the tradespeople, they just made the ones that knew how to use the more efficient.
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.
> 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 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.
I agree, the thought of some PMs building an actual system is absurd. They do not understand the details necessary.
But quite a few developers I know would also be absolutely hopeless as PMs. No people skills, no interest in strategy or the long term view, do not want to hear about end users.
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.
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.
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).
"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
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.
> 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.
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.
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.
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.
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.
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
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.
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.
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".
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.
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.
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.
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.
This 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.
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.
It will be interesting as orgs flatten to see what will keep all the remaining "superhuman AI-powered all-in-one" employees from just making their own shop.
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.
Text to code is clearly valuable but the code to text capability of LLMs is seriously underrated IMO. I would argue orgs should prioritise giving PMs Claude Code licenses over devs. So much efficiency unlock without the worry about whether vibe code can be shipped to prod.
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.
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
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.
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.
PMs writing software seems like a terrible idea. Vibecoding still requires to be quite knowledge about the software engineering to actually get good results.
Agree with this take for the most part. Vibe coding is bad enough with an engineer in charge. Without a computer science background or engineering experience it's way too easy to go off the rails.
The exception would obviously be all the skilled coders who got turned into PM's over the years due to bad salary/title structures or poor organization structure.
I am a bit confused with the consistency of this community in speaking about MBA’s running their orgs or PM’s making bad decisions… it feels like more resistance by engineers to learn business than the business side not learning code. What I mean is that what a company values seems to be widely understood and the reaction from HN is “they’re wrong.” If anything, this is the green light for engineers to step into the business side and fix all the complaints they’ve had for decades.
They always have been, long before AI. Some sales engineers can be in the club as well IMHO.
It's pretty normal for integration projects with big corps to have problems, but if the project has executive interest and the A-team gets called in, it's a joy to work with those people. The lines between the roles are blurred, it's just smart and dynamic people making things work. They don't give a shit about following scrum or pedantic coding standards, only project success, but not in a superficial way. I don't know if they truly care about what they're doing, but they're so far above the baseline that it doesn't really matter.
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.
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.
I didn't know what to expect when clicking an URL to "My _spicy_ take on vibe coding for PMs". I'm a little disapointed of the lack of risque content though.
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 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 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.
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.
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.
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.
If you can't read code and don't understand the codebase, you have no business anywhere near a text editor.
I work with a PM that's also learning to program. I assume just like you, they probably feel they'll otherwise will be pushed out. While it's far from the most productive thing I could be doing, I'm always happy to answer questions from a beginner programmer, or walk them through how something works, or how it should work but doesn't, help them debug it, etc.
Even though they're more or less ripping off the company, and are being paid a six-digit salary to be an intern programmer, I have infinitely more respect for them, as they're actually putting a good effort into learning the craft, and they're honest about what they're doing.
You can argue all you want that throwing vibe-coded PRs at your team improves your MVPs, PDRs, AVBs, DRTs, SVGs, BMPs or whatever un-measurable metrics you come up with, the reality is you're creating more work for everybody.
It takes a great amount of hubris to believe that although you may be unable to read code, surely your understanding for the product will lead to a diff that's an overall net positive. Your team will pat you on the back and then quietly clean up your mess.
If you want to program; great; learn the craft like the rest of us did. I'm sure you'll find many people happy to share knowledge and help you along if you put in an earnest effort.
Spicy response but nevertheless, thank you for taking the time.
You are right that I can't understand code. But what I can do is identify the right problem, and identify the right solution to solve that problem. Coding agents are GREAT enough now to complete the last leg of solution -> code implementation.
It helps that my PRs are small, typically frontend heavy, I can test all I want, and almost all of them get merged without any major comments. If this is happening , then surely we can agree that no one is cleaning up my mess or I am not generating something that is not net positive.
I have zero worries about being pushed out - all of this is barely 5% of my work time ++ weekends, happening out of interest (and the other reasons I mentioned) and not because I have to.
And sure, I could invest in learning the craft. But this is exactly that from my pov. I am sitting in terminal, I am asking Claude to explain what changes it is making, thoroughly testing everything to ensure nothing breaks. Just because I am not typing the actual code doesn't mean I am not putting an earnest effort.
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.
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
There are various technical corrections, with arguable pros and cons. However, they do not match the underlying problem stated above:
> the rise of business types in tech company leadership
The fact that they are PMs is a tragedy of circumstance, not a moral failing. If they are willing to go on-call for their work they will lose that childlike innocence and become engineers very quickly.
> they will lose that childlike innocence and become engineers very quickly.
I don't think so. Not everyone has an engineer mindset (or a PM mindset, for that matter). There's a reason these people ended up where they ended up.
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.
> unpaid overtime
Through 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?
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)
How does it work out with cost of living?
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.
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.
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.
>Of course, in America you have to fund your own retirement.
Isn't social security a thing? Plus employer funded 401K also?
>As long as the pensions plans remain solvent, "savings" are a lot less important in Europe.
"As long as" is doing a lot of lifting here, and that's enough if you're lucky enough to own your own property and not have to pay market rate rent at your old age.
> Isn't social security a thing?
Social Security alone will, at best, slightly mitigate poverty. 401Ks are generally employee-funded, with some firms providing matching funds, especially during good economic times and where the firm is in a field where the main area of labor relied on relatively scarce so that there is competition for talent.
EDIT: The line about social security is a little inaccurate in the extreme case; its actually technically possible to reach a moderate income ($62k/year) on Social Security, if you have a long enough working career (35 years or more) earning at the maximum taxed wages for Social Security (currently $185k+) and claim at or beyond the age that maximizes the benefit calculation (70 years).
>Social Security alone will, at best, slightly mitigate poverty.
It's the same in Europe
In the US it's common to either negotiate 'differential' pay for the responsibility, or as one might see in this thread, get suckered into it for free.
Unpaid overtime is common across the continent for salaried positions. There's only a handful of jurisdictions where it's not the norm.
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.
This "receive heavy scrutiny" is part of the problem that is raised in the article though:
> You are friends with all the senior TLs, so can get them to review your code, but this is not a high-leverage use of time.
And then, tying back to ops comment, the engineer gets pinged for their bad metric, because of this additional review.
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.
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).
Quick everyone, create decoy repos for them to vibe in. When the feature doesn't appear "oh feature gate system has an incident try tomorrow". Even better make the decoy repo have an insufferable pipeline that always breaks and get them in a loop trying to fix it. An adveserial "red team" LLM can keep it broken! But tantalizingly with different problems so progress is felt.
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.
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.
> Leadership claims they are aware of Goodhart's Law, but their actions show otherwise.
Leadership will cherry pick metrics that are easy to game so they can make the next promo, and do say at the expense of company resources. This is a problem in every big corp not just tech.
Good business types can massively improve a tech company. The issue is there aren’t many good ones
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.
Move fast and break things. If it works well for a startup with 3 users and 1 developer, why not do the same for our critical infrastructure company? Openclaw, fire my engineering team and bring me more alcohol.
Everybody and their mom loves to believe they're the hot young stuff on the block.
Even with a company like, say, Meta, they have more freedom to make mistakes than 100% of enterprise companies. Nobody cares too much if Facebook goes down or is slow or something.
But if you're selling to another business, they're gonna have your ass for breakfast for even the tiniest mistakes. As they should, they're paying you a lot of money!
[dead]
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.
If you were to write down a guide on how to avoid team dysfunction, it would get a name or maybe an acronym.
If it worked someone would say, hey let's use this in more places.
If it worked really well others would say these aren't guidelines they're dogma.
Now we have scrum 2.0.
A wise person once said "scrum turns dysfunctional teams into average teams. It also turns highly-motivated teams into average teams".
You're right, but you're going to be inundated with
"but real scrum has never been tried" types.
> "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.
Scrum is just one of the early signs for me to start looking for a new job
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.
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.
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).
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.
> 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.
Woah, what is that 2026? Emulating the economy using human flesh is obsolete. Just emulate the entire C-suite with the fleet of agents in the latent space of LLMs running on the orbital datacenters, powered by the same solar energy that used to keep humans warm.
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.
> 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."
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?
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!
I don't see this happening. Even today, I can place a bet on a prediction market that nobody women will give me a blow job tonight, a lady of the night then places a counter bet wagering that I will, and shows up at my house.
Services in individual apps are a thing of the past.
Apparently it never occurs to the Believers to ask this exact question. They will pay an expensive subscription to vibe-earn money without working.
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?
The end game is Zuckerberg sitting alone in his bunker and vibe-ceo'ing all of facebook.
He'll also have to be vibe-eating because nobody is vibe-growing food any more. Everybody's too busy vibe-vacationing.
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)
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.
Fake It ‘Till You Make It.
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.
"This is the end of software engineering."
Likely. The models have to improve, but the trend has been strong.
I have the misfortune to be required to use Gemini at Google, so I am not seeing it as clearly as others, but indeed the trend seems real.
Maybe, but why have (frankly not that intelligent/logical) PMs doing dev work vs the dev/eng types being the PMs with AI help?
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.
Well, I mean if we’re talking about "we don’t need engineers anymore" why not do that?
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.
A few points to add:
>I have my wife vibe coding programs for her medical company. Its great. Saved her $200/mo so far from ADP
>I have tried encouraging others to vibe code, and they don't even know basic things like how to save files as .html... At best I've taught them to disagree with the AI and tell the AI "Make me a file I can click on".
>Being precise on the steps to solve a problem can be the difference between 1 shot success and floundering.
>Maybe do something that involves physical space and programming.
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.
Agree. Also as a PM, one of the most important things you can do, once you've decided or understood "this is the most important thing we can be working on," is to sell that vision internally so you have high alignment and thus can move fast with shipping (i.e. Sales, Marketing, Legal et al are all on board and ready to help you get to market).
SHOWING internal folks something is always more compelling than words on a slide. So if you have good alignment with your Engineering team that the thing is possible, you can go off on your own and vibe-code something to garner internal alignment... and then throw it away and let your Engineers build the real thing. And they won't have to spend extra time on a PoC that's only meant to show off internally.
> then throw it away and let your Engineers build the real thing
Aaah, but the pull of "it's already built, 90% is done, let the eng polish it and that's it!" productivity siren song is strong...
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
Isn’t this the type of work interns used to do? Prototype hackathon type things?
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.
You'd be surprised. See this sister comment: https://news.ycombinator.com/item?id=47242372
>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.
Maybe your cool ideas/small optimisations were not addressed because of how they would impact the system as a whole. It's the job of the engineer to keep things running and there are a lot of places that can wreck (slowly of quickly) the product if modified wrong.
One thing missing from this discussion is the blast radius of the product or repo in question.
Let PMs land new widgets on internal dashboards or CSS changes in internal tooling. The same way we should be aspiring to build tools for devs to merge these same changes with minimal test plans. You wouldn't call a mechanic to help you turn on your windshield wipers.
Changes in high-risk environments should be gated for people who actually know what they're doing. That high bar should remain high.
100% agreed. I'm a Program Manager and have been writing tooling for my own internal workflows for years (like Monte Carlo-based forecasting tools), or program-adjacent low-stakes stuff (like an API to generate a WSJF score based on a fields inputted into Asana, since it couldn't do that itself).
But I'm not about to send a PR for fixing production bugs even if I have decent high level context. Nobody has better context than the devs working on it every day.
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.
The quip "move things and break fast" is from which year btw, do you remember?
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
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.
Yes. “Landing a diff” is very meta-specific.
Hype will come down once scalability problems start to show up. It's the same with every new technology: people get excited from the results of their PoC not realising that a PoC is smaller in scope and therefore has better chances of working. Then you try to translate that to a proper project and it all falls apart.
Agentic coding will accelerate things, but you'll still need the engineers.
Power tools didn't get rid of the tradespeople, they just made the ones that knew how to use the more efficient.
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.
> 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 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.
I agree, the thought of some PMs building an actual system is absurd. They do not understand the details necessary.
But quite a few developers I know would also be absolutely hopeless as PMs. No people skills, no interest in strategy or the long term view, do not want to hear about end users.
PM = project manager in my world
>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.
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.
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.
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).
"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.
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.
> 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.
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.
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.
> I read takes like this and I feel like it's gatekeeping
Yeah man, insisting on good engineering practices instead of "vibes" has always been gatekeeping
That's the actual point of engineering credentials
What are we even doing here
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.
> This was before the bot could competently code things
Agree to disagree
Getting something working is the absolute bare minimum, it's not "competent"
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.
> The fact that it can, and often does, get things working, sometimes even well, is evidence enough
So can my 12 year old nephew, but we aren't racing to put him in charge of software development in professional settings
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
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.
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.
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".
Is a hiring bar gatekeeping then? Do you just hire the first person that applies because having them do a technical test gatekeeping?
> 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.
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.
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.
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.
Hey you forget sales and marketing. Just do that also.
Luckily I suck at that!
Yeah that's why we're replacing you with someone who generated a claude skill which does that! /s
Ah yes, but now with AI it's going to be easy*
* Not easy at all, but too bad. We worship at the altar of productivity and either you're our blood sacrifice or you're unemployed
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.
You just need one of them. It's probably the engineer.
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.
> With clear quarterly goals
This 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.
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.
Agreed though I'm biased.
It will be interesting as orgs flatten to see what will keep all the remaining "superhuman AI-powered all-in-one" employees from just making their own shop.
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.
Text to code is clearly valuable but the code to text capability of LLMs is seriously underrated IMO. I would argue orgs should prioritise giving PMs Claude Code licenses over devs. So much efficiency unlock without the worry about whether vibe code can be shipped to prod.
Shipping vibe code to prod is like the dumbest and least useful thing LLMs can do.
exactly.
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.
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.
What's an eval?
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
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.
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.
PMs writing software seems like a terrible idea. Vibecoding still requires to be quite knowledge about the software engineering to actually get good results.
Agree with this take for the most part. Vibe coding is bad enough with an engineer in charge. Without a computer science background or engineering experience it's way too easy to go off the rails.
The exception would obviously be all the skilled coders who got turned into PM's over the years due to bad salary/title structures or poor organization structure.
I am a bit confused with the consistency of this community in speaking about MBA’s running their orgs or PM’s making bad decisions… it feels like more resistance by engineers to learn business than the business side not learning code. What I mean is that what a company values seems to be widely understood and the reaction from HN is “they’re wrong.” If anything, this is the green light for engineers to step into the business side and fix all the complaints they’ve had for decades.
I think technical PMs or product oriented developers are the future most valuable people.
They always have been, long before AI. Some sales engineers can be in the club as well IMHO.
It's pretty normal for integration projects with big corps to have problems, but if the project has executive interest and the A-team gets called in, it's a joy to work with those people. The lines between the roles are blurred, it's just smart and dynamic people making things work. They don't give a shit about following scrum or pedantic coding standards, only project success, but not in a superficial way. I don't know if they truly care about what they're doing, but they're so far above the baseline that it doesn't really matter.
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.
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.
I didn't know what to expect when clicking an URL to "My _spicy_ take on vibe coding for PMs". I'm a little disapointed of the lack of risque content though.
My company does not have PM for a while now. Even before AI
I think orgs would get better traction with PMs taking on product complaint or bug issues and using AI to diagnose detailed root cause.
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
Let engineers do Vibe-accounting because, AI.
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.
The brutal truth is that no one likes dealing with developers - now they don't have to.
> 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.
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!!!!!!!.
When your only defense is “I’m just having fun!!!!” after dumping your toxic waste in the net, it’s not a weird take.
[flagged]
Begone, bot.
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?
> 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.
Pretty sure Claude Opus can do a PMs job too.
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.
Most seniors are hired for their code readability and real-life experiences with real products and problems. Not for code writing ability.
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.
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.
This sums up my experience/opinion well.
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
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
> 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.
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.
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.
If you can't read code and don't understand the codebase, you have no business anywhere near a text editor.
I work with a PM that's also learning to program. I assume just like you, they probably feel they'll otherwise will be pushed out. While it's far from the most productive thing I could be doing, I'm always happy to answer questions from a beginner programmer, or walk them through how something works, or how it should work but doesn't, help them debug it, etc.
Even though they're more or less ripping off the company, and are being paid a six-digit salary to be an intern programmer, I have infinitely more respect for them, as they're actually putting a good effort into learning the craft, and they're honest about what they're doing.
You can argue all you want that throwing vibe-coded PRs at your team improves your MVPs, PDRs, AVBs, DRTs, SVGs, BMPs or whatever un-measurable metrics you come up with, the reality is you're creating more work for everybody.
It takes a great amount of hubris to believe that although you may be unable to read code, surely your understanding for the product will lead to a diff that's an overall net positive. Your team will pat you on the back and then quietly clean up your mess.
If you want to program; great; learn the craft like the rest of us did. I'm sure you'll find many people happy to share knowledge and help you along if you put in an earnest effort.
Spicy response but nevertheless, thank you for taking the time.
You are right that I can't understand code. But what I can do is identify the right problem, and identify the right solution to solve that problem. Coding agents are GREAT enough now to complete the last leg of solution -> code implementation.
It helps that my PRs are small, typically frontend heavy, I can test all I want, and almost all of them get merged without any major comments. If this is happening , then surely we can agree that no one is cleaning up my mess or I am not generating something that is not net positive.
I have zero worries about being pushed out - all of this is barely 5% of my work time ++ weekends, happening out of interest (and the other reasons I mentioned) and not because I have to.
And sure, I could invest in learning the craft. But this is exactly that from my pov. I am sitting in terminal, I am asking Claude to explain what changes it is making, thoroughly testing everything to ensure nothing breaks. Just because I am not typing the actual code doesn't mean I am not putting an earnest effort.
[dead]
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.