The AI Expectations Gap Is Real, and It’s Splitting Tech in Two

The disconnect starts at the top. Anthropic’s research on the AI expectations gap reveals something fascinating: 91% of Anthropic staff expect AI to make a Nobel-level discovery by 2030, while only 39% of US adults agree. And when it comes to their own jobs, over half of Anthropic staff expect AI to handle at least 80% of their current work by 2030, compared to just 5% of US workers.

But here’s what’s actually spicy: that expectations gap isn’t just between AI labs and the general public. It’s opening up inside organizations, between PMs who see AI coding tools as their ticket to technical independence and the engineers (and policies) standing in their way.

The PM at that bank wasn’t asking for permission to replace engineers. They were using Copilot to validate requirements, explore data contracts, and build prototypes — activities that arguably make them a better PM. The response was a firm “hard no” due to org policy. Not because of security concerns or code quality issues. Because of a line on an org chart.

Everyone’s an Engineer Until Something Burns

There’s a brutal reality check embedded in how the engineering community views this trend. As one Reddit thread on r/ProductManagement put it: everyone’s an engineer until the first sev1 brings down prod and the person who made the last commit has no idea why.

This isn’t just snobbery. It’s a legitimate concern about what happens when AI makes code production look easy. The tools have gotten dramatically better at generation, but the hard parts — architecture, security, testing, understanding failure modes — haven’t gotten easier. AI coding assistants deliver productivity gains of 26% to 55% on common tasks, but those gains come with an asterisk: someone still needs to understand what the code actually does.

The Chernobyl quote floating around engineering circles captures it perfectly: every slop code PR incurs a debt to production. Sooner or later, that debt is paid. And tech debt that used to grow at 10 mph with human developers? AI accelerates it to 200 mph.

The “Just One Person Doing Two Jobs” Problem

Here’s where the conversation gets genuinely uncomfortable. When companies ask PMs if they’d be comfortable “owning the entire cycle,” from product decisions to writing the code, is this a legitimate evolution of the role, or is it a way to get two headcounts for the price of one?

The job market doesn’t provide clear answers. After hundreds of interviews, one job seeker’s conclusion was stark: nobody knows what they want from Product. The role has become a catch-all, with some PMs updating spreadsheets full-time while others ship code.

This ambiguity is creating real career confusion. PMs who’ve adapted to AI coding tools and built technical workflows are finding themselves in a weird limbo. They’re not engineers, so they don’t get engineering tooling. But they’re expected to understand technical tradeoffs deeply enough to make product decisions that engineers can execute. The technical PM trap is real, and AI is pouring gasoline on it.

What Engineers Actually Want from Technical PMs

The irony is that engineers aren’t asking for PMs who can code. They’re asking for PMs who understand the constraints of building software. What engineers actually want from technical product managers isn’t someone who can submit a PR; it’s someone who understands why the PR takes three days instead of three hours, who can reason about system design tradeoffs, and who doesn’t need every edge case explained from first principles.

This is a crucial distinction. In the age of AI, the ability to read and understand code is becoming a core PM competency. The ability to write and ship code is still an engineer’s job. The problem is that AI tools are making it terrifyingly easy for PMs to cross that line, and organizations haven’t figured out whether that’s a feature or a bug.

With Copilot’s agent mode now capable of fixing errors, suggesting commands, and iterating based on feedback, the barrier to shipping prototype code has collapsed. PMs can now explore solutions that would have required weeks of engineering time just a few years ago. The AI slop trap warns us what happens when this capability falls into the wrong hands: code that looks plausible but has no business being in production.

The PRD Is Dead. Long Live the Prototype

Here’s where the PM role is actually transforming, and it’s more interesting than “PMs must code.” The traditional Product Requirements Document assumed a clear separation: PMs specified, engineers built. AI coding agents are blowing up that assumption because they require specifications that function more like programming interfaces.

As product leaders exploring AI-native workflows have noted, agentic coding tools demand a level of precision in requirements that traditional PRDs never needed. An AI agent can’t infer your intent from prose the way a senior engineer can. It needs explicit definitions of edge cases, acceptance criteria, and failure modes.

This is shifting the PM’s job from writing narrative documents to writing executable specifications. The PRD is dead, long live the prototype captures this shift perfectly — PMs who can think in terms of what an AI agent can actually execute are becoming dramatically more effective.

The Productivity Paradox PMs Must Navigate

There’s a darker side to this productivity story that rarely gets discussed. The UC Berkeley research on AI burnout suggests that tools promising to give us time back are actually eating it. When PMs can spin up prototypes quickly, the expectation becomes that they should. When they have Copilot access, the question becomes why they’re not shipping validation code themselves.

This is the AI productivity loan with predatory interest rates: the short-term gains feel transformative, but the long-term cost is expertise erosion. If PMs stop developing the judgment that comes from working through technical constraints, they become dependent on tools they don’t fully understand.

And the data backs up the concern. South Korea’s central bank found a disconnect between AI adoption and actual productivity gains — an uncomfortable reminder that tool adoption doesn’t automatically translate to better outcomes.

What Actually Breaks When PMs Code

The deeper question isn’t whether PMs can code; it’s what happens to the system when they do. An engineering team that operates without PMs? We’ve seen that experiment, and the results are illuminating. When engineers gain access to powerful AI coding tools and suddenly believe they don’t need product guidance, the immediate gains in velocity mask the long-term damage to product coherence.

The reverse problem is just as real. PMs who become “engineer-lite” risk falling into the trap of AI productivity gains eroding long-term expertise. The cognitive resilience that comes from struggling through technical problems, the deep understanding that only emerges from repeated failure — these can’t be delegated to an AI tool.

The Tools Are Ready. The Policies Aren’t.

The technology has moved faster than organizational governance, and that’s where the real friction lives. When the PM at that bank lost Copilot access, the issue wasn’t capability. It was a policy built for a world where “engineering” was a hardened boundary. That boundary is dissolving, and org charts haven’t caught up.

The pragmatic advice from someone who’s navigated this at a Fortune-level retailer: policy yields to controls. Don’t fight the “no” directly; find the control owner, propose modified controls, and give the policy owner a reason to say yes. If you’re a PM who’s genuinely using AI coding tools to validate requirements and build data pipelines, you shouldn’t have to hide that work. You should be making the case that this capability belongs in the PM toolkit.

The Real Question Isn’t “Can PMs Code?”

Let’s reframe the entire debate. The question isn’t whether product managers are now expected to write code. The question is what “technical ownership” means when AI can generate the syntax but can’t make the judgment calls.

Sam Altman’s observation about software demand keeps looking prescient: the world wants vastly more software than it can currently build. AI is making code cheaper while coding demand explodes, and someone has to decide what gets built, for whom, and why. That’s still the PM’s job.

The best PMs in the AI era aren’t the ones who can write the most code. They’re the ones who understand the system deeply enough to know what an AI agent should build, when it should build it, and what could break if the agent gets it wrong. They’re the ones who can translate between the messy world of user needs and the precise, executable world of agentic coding. They’re the ones who see the difference between using AI as a tool and becoming reliant on it.

The org charts will catch up. The policies will adjust. But the fundamental value of product management — the judgment, the context, the accountability for outcomes — that’s not getting automated away. It’s getting more valuable.

And if your organization revokes your Copilot access because of an org chart line? Maybe that’s the signal you needed that your organization hasn’t understood what AI actually changes about the PM role. The tools aren’t the revolution. The expectations gap between what AI can do and what organizations will let it do — that’s where the real transformation is happening. And it’s happening in the space between PMs and engineers, whether your org chart acknowledges it or not.