You were hired to take a PRD (Product Requirements Document) and turn it into working code. Now your product manager walks in with the working code and a list of edge cases they already caught.
Picture a product meeting from eighteen months ago. The product manager (PM) slides a doc across the table. Ten pages of requirements, user stories, acceptance criteria. The engineer reads it, asks a few clarifying questions, disappears for two weeks, and reappears with a working feature.
Clean handoff. Clean roles. Everyone knew which half of the job was theirs.
Now picture the same meeting today. The PM opens their laptop. They spent the weekend vibe coding. There's already a working prototype running. Then they mention three edge cases they hit while building it: the model hallucinates on empty inputs, latency spikes past two seconds on long documents, the rate limiter misfires on parallel requests.
If you're a software engineer who grew up inside that old division of labor, this is the moment the floor shifts under you. The PM's half of the job came in finished. Your half came in already half-done. And the hardest parts of your half came in pre-solved.
(Find out your specific situation by taking the free How Safe Is Your Engineering Role? quiz at the bottom of this page. You can also access this quiz on its dedicated page, where you'll find more details about it and its results.)
Handoffs Existed for a Reason
Engineering and product used to be two separate jobs because very few could do both well. Product understood the user and the business. Engineering understood systems and code. The PRD was the contract that let two incompatible brains ship the same thing.
Good PMs pushed against that line for years. They'd pick up some code. They'd prototype in Figma. They'd learn enough to push back when engineering said something was impossible. But the prototypes were always mocks. The engineer still had to build the actual thing.
That line just dissolved.
Vibe Coding's Natural Winners Aren't Engineers
Everyone has been absorbing one version of the story. AI got good at code, so engineering gets commoditized from below. Junior tasks first. Then maybe the whole role.
The more interesting version is the one nobody has been watching. The natural winners of AI coding tools aren't average engineers. They're good product managers.
A good PM already had the context AI was missing. The user. The business. The why. The specific shape of the thing that should exist. The only thing stopping them from shipping was their hands. AI gave them hands. Now they can cross the bridge from taste to running artifact in the time it used to take to write the spec that asked an engineer to do it for them.
And the prototype does something the PRD never could. It hits the real walls during construction, the kind that don't show up in a doc until somebody has tried to ship past them. The PM doesn't have to imagine edge cases. They collect them as they go. By the time the engineering meeting happens, the list is already in a notebook, next to a few more the engineer wouldn't have thought to check.
Edge cases used to be an engineer's moat. The thing they brought to the meeting that the PRD didn't have. "I'll build it, and by the way, here are six things you didn't think about." Now the PM has a running demo and their own six things (that might not even overlap the engineer's).
Squeezed From the Side
Most of the worry about engineers getting replaced has focused on the wrong direction. Everyone is watching the floor: will AI get good enough at junior tasks to make entry-level engineering obsolete?
I find the squeeze from the side as interesting as the squeeze from the bottom.
The PM has hands now. A working product manager vibe coding with Cursor, Codex, or Claude Code is basically a strong engineer wrapped inside someone who already knows what the product should do. That's a brutal combination if the thing you were bringing to the table was the ability to turn a spec into code.
A sound engineer in the early 2000s ran into something similar. Their job was getting a clean recording in a professional studio with real equipment and real acoustic treatment. Then a guitarist showed up with a laptop, a decent audio interface, and a bedroom demo that was already mixed. The craft was still real. It just stopped being scarce where it used to be scarce.
[[embed:squeeze-map]]
Four Things the Prototype Still Can't Touch
Good news. The PM-with-AI combo has a ceiling. And the ceiling is above where most engineers spend their week right now.
Four things the prototype still can't touch:
- Architecture that survives growth the demo has never seen. The prototype handles ten users on localhost. What happens at ten thousand? At a million? The decisions that determine whether the system bends or breaks under that load are invisible inside a running demo. They're invisible right up until the moment they aren't.
- Failure modes that only show up in production weather. Production is a climate. Network partitions. Clock skew. Partial failures. Retries that amplify load during an incident. The prototype that runs beautifully on a laptop has never seen a real storm. Knowing what breaks, when, and how to keep it from breaking comes from having been on call the night it did.
- Second-order consequences baked into the prototype. The PM's demo made a database choice, a caching choice, a state management choice. Each one looked reasonable in isolation. Each one locks the system into a direction you'll regret in six months if you're the one still on the hook. AI is a single-move thinker. A senior engineer is thinking five moves ahead.
- The second mind in the room. The PM with AI builds fast because nobody in the loop is disagreeing with them. No spec review, no engineer asking "wait, why?", no other brain looking at the same problem with a different set of reflexes. That speed is also where it breaks. A prototype that catches six edge cases is still a prototype with no disagreement inside it. I've shipped enough things as a solo operator to know the most dangerous bugs come from the questions nobody in the room was assigned to ask. The PM-with-AI inherits that exact blind spot.
None of these are bootcamp skills. None of them show up in job listings as "React developer, 3+ years." They come from shipping real systems, watching them break in embarrassing ways, and building an internal model of what never to do again.
If you're wondering where to aim, aim there. Not at writing more code. At understanding what happens when the code meets the world.
There's an uncomfortable thing sitting inside this. The climb I'm pointing at requires the kind of bruising that used to come from the middle rungs of the ladder.
The tickets that taught you what you now know were the tickets most likely to get absorbed by the PM-with-AI. Newer engineers will have to find a different on-ramp to the scar tissue, and nobody has mapped that route yet.
The climb is real. The ladder is getting kicked.
One direction worth watching: if the prototype is now the starting line, the junior engineer's new apprenticeship might be learning to stress-test what someone else built rather than building it from scratch. Break the demo. Find the failure mode the solo operator couldn't see. That's a version of the second-mind role that doesn't require ten years of scar tissue to start.
There's a name forming around this convergence. Some companies call it the "product engineer" — someone who holds both the product context and the systems thinking. Not an engineer who learned to write PRDs. Not a PM who learned to vibe code. Someone who can look at the prototype and the production system and see the gap between them as a solvable problem.
That role didn't exist when the handoff was clean. It's emerging because the handoff dissolved.
One Honest Question Worth Sitting With
A question worth sitting with, not defensively:
If a product manager you respect took your next ticket and built a prototype of it with AI tools over a weekend, would they catch the edge cases you'd catch? Would they find ones you wouldn't?
If the answer is "yes" to the first and "maybe" to the second, the pressure you're feeling has a name. The job you were hired to do is becoming something the other side of the handoff can now do on their own.
Don't resent the PM eating your lunch. They're doing what anyone would do when the tools made it possible.
Climb instead. Climb to the part of the job that lives underneath the prototype, the part where the running demo is just the starting line. Then become the second mind the solo operator can't have inside their own head.
The old game was simple. The PM writes the spec. The engineer builds the thing. The new game is harder. The PM brings the thing. Your job starts where theirs stops.
That's a harder job. It's also the one worth having.
Rabbit Hole
If this landed, these might too:
- The Uber-Engineer Doesn't Write Code - why the engineer's new role looks more like a film director than a coder
- Your Job Already Changed. You Just Didn't Notice. - how the definition of "good" in your role quietly moved while you were still doing the old version
- The New Bottleneck - what actually becomes the hard part when building gets easy