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.
Those not on rota can either join or have their PR receive heavy scrutiny
> the rise of business types in tech company leadership
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.
> 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.
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.
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.
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.
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.
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.
"but real scrum has never been tried" types.
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.
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.
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."
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!
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)
> It is truly the next thing, and the future, probably happening in the next 2 years, or in 2 years in 2 years.
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.
>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.
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.
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!
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.
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.
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...
So you get to cowboy code, but I don't. I see how it is.
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.
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.
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.
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.
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.
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.
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.
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.
software engineers love to imagine that they have the only job you can't train yourself to do quickly, all evidence to the contrary.
Let's see if AI makes PMs care for details.
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.
This isn't just a PM problem — it's the same dynamic playing out at every seniority level with AI-assisted coding. The speed feels real, but the ownership gets blurry.
A few of us have been working on formalizing exactly this challenge: the Agile Vibe Coding Manifesto (https://agilevibecoding.org). It builds on the original Agile Manifesto to address environments where AI is generating significant amounts of code, and its second principle is simply "Humans remain accountable for software systems — regardless of how code is produced."
The manifesto doesn't argue against AI-assisted development. It argues that speed of generation has to be matched by clarity of intent, traceability of decisions, and genuine human accountability for what gets deployed. Whether you're a PM shipping a quick tool or a senior engineer steering an agent, the accountability question doesn't go away.
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'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.
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.
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 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.
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.
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
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.
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.
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.
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.
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.
* 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
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.
One thing LLMs don't have is taste. That's on me.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
So AI is merely letting me focus more on the other parts. Some developers don't like this. I kind of do.
Agents would research and identify requirements on their own, observe customer interactions and monitor for trends. Taste.md downloaded via LoveFrom
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
Is this sarcasm? You don't think there is any utility to understanding code?
Edit: you got me haha.
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.
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.
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.
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.
