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

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

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).

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.

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.

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.

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?

"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.

The end game is Zuckerberg sitting alone in his bunker and vibe-ceo'ing all of facebook.

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)

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

can't tell if you are serious or not.

> by just telling LLMs to make an app or to make money or something.

Again, that is literally OpenAI's business model: burn money building ChatGPT until it's smart enough to tell them how to be profitable.

"That's a bold strategy, Cotton, let's see if it pays off for 'em."

HAHAHAHA. Dodged a bullet. Do you really want to work in a enterprice where HR is so dumb to buy this shit? Just think, they hire all your colleagues.

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.

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.

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

same, it sounds more like common sense than spicyness? i vibecode prototypes and visualizations but pushing any more than that would just add chaos to the chaos we're trying to avoid

You'd be surprised. See this sister comment: https://news.ycombinator.com/item?id=47242372

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.

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.

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

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.

A lot of details are already beginning to fall through to the AI’s lap anyways.

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

Is a hiring bar gatekeeping then? Do you just hire the first person that applies because having them do a technical test gatekeeping?

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'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.

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.

Shipping vibe code to prod is like the dumbest and least useful thing LLMs can do.

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.

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.

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.

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.

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.

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.

Thanks! I posted that one almost a year ago and it blew up on LinkedIn of all places but was totally ignored on HN.

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.

Communicating a feature with a doc or mock can be really hard. A prototype can make things much clearer to a broad audience.

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

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.

> With Claude 4.6 Opus, the engineer skill set is no longer useful.

The most recent models have spooked me into believing this is a thing that is likely to be true at some point, but it ain't true yet.

This is kind of like the reverse of the sister comment, which I agree with: https://news.ycombinator.com/item?id=47242699

The general point is that separating PM and eng doesn't make sense any longer. Which subsumes which is an interesting debate.

Your argument that 4.6 Opus makes the engineering skill set useless is totally false and maybe shows you haven't built anything complicated, but it is possible that Opus 5.2 will get there.

Pretty sure Claude Opus can do a PMs job too.

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.

Most seniors are hired for their code readability and real-life experiences with real products and problems. Not for code writing ability.

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.

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

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.

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.

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.