AI won't replace engineers, it will replace project managers

TL;DR: AI coding agents collapse the translation layer between users and code - the exact thing PMs exist to provide. Engineers who move into that space are positioned to own the full product loop. The ones who don’t risk being squeezed out, not by AI, but by engineers who did.

The dominant narrative for the past two years is: AI will replace software engineers. Coding becomes obsolete. The job disappears.

That’s wrong. And I think the people saying it loudest don’t actually work in software.

What AI coding agents do is eliminate the cost of producing code. Not the cost of understanding systems, not the cost of knowing what to build - just the mechanical act of turning requirements into syntax. If your primary contribution was that mechanical act, yeah, you’re exposed. But that framing misidentifies where engineering value actually lives.

What a PM actually does

Project managers - also called product managers depending on the company and politics - exist for a specific reason: there’s a communication gap between users and engineers. Users know what pain they have. Engineers know what’s technically possible. The PM sits in the middle and translates.

That’s the job. Everything else - roadmaps, prioritization frameworks, sprint planning, requirements docs - is scaffolding around that core translation function.

The role got formalized because engineers historically didn’t want to talk to users. They wanted to build. Talking to customers was “someone else’s problem.” So a role emerged to own that interface. Over decades it grew into its own organizational function, career ladders, certifications, the whole thing. It was always a workaround for a cost problem - code was expensive, so you needed someone to carefully pre-process what got built. Now code is cheap. The workaround doesn’t hold.

What AI agents actually shift

AI coding agents don’t just make engineers faster. They compress the cost of building to near zero for anyone who understands the problem space.

And here’s the thing: understanding the problem space is exactly what engineers are supposed to be good at. Systems thinking, decomposing complex requirements, knowing what’s technically feasible and at what cost - that’s the actual hard part. It was always the hard part. Code was just the expression of it.

When code becomes cheap, the translation layer becomes unnecessary. An engineer can talk to a user directly, understand the pain, and ship a fix the same afternoon. No requirements doc. No sprint. No PM review.

I’ve done this. Sit on a call with a user, they describe a problem, you understand it technically in real time, ask the right questions, and start building before the call is over. That’s not possible when code takes weeks. When it takes an afternoon, a PM in the middle is just friction.

Engineers who will thrive

The engineers who come out ahead are the ones who were already doing both jobs imperfectly.

They were the ones who pushed back on product specs because “this is technically wrong,” who went directly to users to understand something before building it. They always had some product instinct - they just couldn’t fully act on it because writing code was the bottleneck.

That bottleneck is gone.

Now they can run discovery conversations, synthesize feedback, prioritize, and ship - without a PM in the loop. The engineer who does this well becomes a one-person product team. Not because they’re superhuman, but because the cost structure changed and they moved naturally into the space that opened up.

The concrete path is uncomfortable but simple: start taking the customer calls you’ve been avoiding, ask to sit in on user interviews, read the support tickets directly instead of getting a summary. The bottleneck was always time, not capability. Most engineers have the raw material for product instinct - they just never exercised it because there was no pressure to.

The engineers who will struggle are the ones who are there purely for the code. The algorithms, the elegance, the systems - but not the users, not the product, definitely not the “why.” That’s a real archetype. And I think it’s at risk, not from AI directly, but from becoming irrelevant to how companies actually function. If coding is cheap and you have no interest in understanding what to build or for whom, then a product-aware engineer with AI does your job cheaper.

That’s not comfortable to say. But most engineers in that position saw this coming and chose not to look.

Technical PMs are in a rare position

There’s one PM archetype that genuinely thrives here: the deeply technical one.

The PM who can read code, who understands system constraints, who knows when an engineer is bullshitting about complexity - that person becomes extremely valuable. They can collaborate with engineers as peers, challenge technical decisions with substance, and prioritize with real understanding of what’s cheap vs expensive to build.

In my opinion, this is the golden age for engineers who moved into product. They understand both sides natively. They don’t need to translate - they just make decisions.

But the non-technical PM? The one whose entire job is gathering requirements, writing user stories, running standups, and managing stakeholder expectations without technical grounding? That role is evaporating. Not eventually. Now. Because engineers with AI can do the requirements gathering, the roadmap thinking, the stakeholder communication - and also build it. You don’t need a separate role for the translation layer when the engineers can own the whole thing.

The org structure change nobody talks about

The signal is already visible in early-stage startups, where hiring norms move faster than enterprise org charts. Companies that raised in 2023–2024 are regularly running 6–8 person engineering teams with zero dedicated PMs. Not because they’re cutting corners - because the founders, often engineers themselves, just stayed in the user loop and never hired someone to sit between them and it.

That model is now reaching mid-size companies. The PM role doesn’t disappear overnight in a 500-person org - there’s too much inertia around titles and headcount. But the hiring bar is shifting. Junior PM and associate PM roles are getting quietly defunded. The ones that survive are either deeply technical or operating at a strategy level that’s effectively a different job entirely.

What this means in practice

If I had to point at one skill that differentiates engineers who grow from engineers who stagnate right now, it’s this: can you sit on a call with someone who has a problem and understand it well enough to know what to build?

Not formal user research. Not a structured interview. Just: do you have the instinct to ask the right questions, hear what the user actually needs vs what they say they need, and translate that into a technical decision on your own?

That’s the function the PM layer was providing. It’s the gap that opens up when PMs get reduced. Engineers who can fill it become irreplaceable. Engineers who can’t get dependent on someone else filling it - and that someone else is getting harder to justify hiring.

I think the “engineers will be replaced” story is a useful distraction for people who don’t want to engage with the more uncomfortable version: a specific, large, non-technical function inside software companies is losing its reason to exist. Engineers who move up into the product layer - who own the full loop from user problem to shipped solution - become more valuable. Engineers who don’t, get squeezed. And the non-technical PM layer is what gets eliminated in between.