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.

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.

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

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.

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.

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.

Let's see if AI makes PMs care for details.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.