In a span of couple of years, 3 new job titles in AI space have appears. Not all survived.
At first, the hot new role in AI was the prompt engineer. For a few months, LinkedIn was filled with people who had appended it to their headline. Then prompt engineering was declared dead (read this think-piece). The indispensable skill become context engineering. While prompt engineering was about “one-off tasks, content generation, format-specific outputs”, context engineering was about “conversational AI, document analysis tools, coding assistants”. The new job title is the product engineer: the person who, armed with an AI coding agent, turns intent straight into shipped software, no engineer required. The premise underneath the label is that building has been democratized. Anyone can build an app now. The product manager, freed from waiting on a sprint, is finally empowered to become the engineer – engineering skill not required.
The democratization pitch is half-right, and I want to give it its due before I take it apart. Because the half it gets right is the half people are about to over-learn. Anyone can “vibe code” (another phrase that’ll die soon) and get it into production the first time. The key is the other half that’s missing – engineering skills to sustain continuous improvement and feature development.
A force multiplier is a real thing. But multiplication has a precondition everyone races past in the excitement: it needs something to multiply. AI multiplies whatever capability you bring to the keyboard. The capability that just got cheap, the one any product manager can now rent by the token, is the ability to describe a feature and watch a model emit plausible code for it. That part is solved; case closed. The capability that did not get cheap, the scarce input the multiplier actually acts on, is the eye to tell a working product from a working demo. Multiply that eye and you get leverage. Multiply its absence and you get the same house of cards you’d have built by hand; except now it goes up in an afternoon and looks finished from across the room. But, we all know zero times anything is zero.
And here I have to say the awkward part out loud, before you notice it and stop trusting me: I’m an engineer, and I’m about to argue that engineers are better positioned for this role than the product managers they’re supposedly replacing. That is the single most self-serving prediction I could make, and you should treat it the way you’d treat a barber who tells you it’s time for a haircut. Hold the suspicion. Just hear me out.
What AI actually made cheap
Start with what actually got cheap, because it’s the thing everyone agrees on for about a sentence and then quietly forgets. AI made execution cheap. The function that used to cost a software engineer an afternoon now costs a prompt and a code review. The integration that ate a sprint takes a nudge. I’m not going to soften this, because softening it is exactly how engineers walk into the trap. The specific skill of writing code (the craft a lot of us spent a decade sharpening, the thing that felt like the moat) is the depreciating asset. Saying otherwise is whistling past the graveyard.
I made a version of this argument already, in it’s a good time to be a generalist: when AI drives the cost of execution toward zero, it drives up the value of knowing what to execute on. The person who won there wasn’t the deepest specialist with the sharpest single tool. It was the one with range; breadth, plus the one capability AI still can’t fake. The product engineer is that same argument with its work clothes on, showing up to standup. The role does not go to the best coder. It goes to the combination: product sense, welded to the technical depth to verify. Verify is the key word. The rest of this post is just the consequences of taking it seriously.
Which missing half is cheaper to acquire
Both candidates show up to this role wearing exactly one shoe. The engineer arrives with the technical half and, very often, no product sense to speak of. The product manager arrives with the product sense and no way to tell whether the code under the demo is sound or scaffolding. So the honest question was never which tribe is superior. It’s which missing half is cheaper to grow. And the answer doesn’t turn on speed, or talent, or who interviews better. It turns on floors.
Product sense has a soft floor. You can wander up to it. Ship a feature and watch the funnel flatline; sit in on the support call where a real human explains, slowly, why your obvious flow was not obvious; notice the button nobody ever clicks. None of that requires a credential or a prerequisite or anyone’s permission. It accrues to whoever is paying attention, in the background, for free. The floor is low and the ceiling is high, and you can start climbing from wherever you happen to be standing.
Verification has a hard floor, and the floor does not negotiate. You cannot stress-test code you cannot read. There is no intuition that substitutes for it, no quantity of product taste that lets you back into spotting a race condition, an N+1 query quietly firing ten thousand database calls behind a smooth-looking screen, an injection sitting patiently in an unsanitized field, a state machine that is flawless for the length of a demo and wrong on the seventh click. You either have the depth to see those things or you don’t, and below that line the agent’s output stops being code you’re reviewing and becomes confident text you’re hoping about. The product manager’s missing half starts at zero and demands you clear a wall before it returns anything at all. The engineer’s missing half starts above the floor and compounds, quietly, with every release. That is the shorter walk: not because engineers are better people, but because they begin the journey already past the stretch that has no shortcut.
From Anthropic employee’s 2-sentence quote crystallizes the state of AI confusion at work, Business Insider, “‘On days where everything works well, I can’t help but think nothing I do matters, everything is automated and better and faster than I ever will be,’ they said. ‘But then there are days where everything breaks and I don’t understand why and I realize I have no idea what I’ve been up to anymore,’ the employee added.’
I am not claiming engineers have product sense. A great many of them famously do not; the field is rich with beautifully engineered answers to questions no user ever asked. I’m claiming something narrower: the gap between where an engineer stands and where this role needs them is shorter than the gap the product manager has to close. This is true today but may not be for long. When the tooling gets good enough that verifying AI output no longer requires the ability to read the code, the hard floor drops, the walk evens out.
Why you should believe me, an engineer
You should distrust an engineer who reassures you that engineers will be fine, and the distrust has a pedigree. In deja-vu, I made the case that the boldest predictions about whose job is doomed almost always issue from people whose own jobs are conspicuously safe: the executive forecasting the obsolescence of the workers two levels beneath him, the VC delivering a eulogy for labor he has never personally performed. The only honest test is whether you’d make the same call if it were your name on the list. Fine. Apply it to me.
My thesis doesn’t tell me what I’d like to hear; it tells me the opposite. It says the thing I am best at, writing code, is the asset losing value. A prediction that is merely tribal flattery does not, as a rule, open by conceding that your signature skill is depreciating and then volunteer the exact conditions under which it’s wrong. That isn’t how comfort talks. That’s the difference between an argument and a pep rally.
The house of cards cuts both ways
None of which means engineers can’t assemble a house of cards of their own. Of course they can. It simply falls down along a different fault line. A demo is a proxy for a product, and as I argued at length in Goodhart’s Law, the instant a proxy gets promoted to a target, you begin manufacturing the proxy and quietly abandoning the thing it was standing in for. AI is spectacularly good at manufacturing this particular proxy: code that runs, screens that photograph well, a flow that holds together for precisely the path the demo walks and not one step to either side. And when it fails, it tends to fail plausibly. The failure dressed as success, the one that surfaces three steps downstream wearing somebody else’s stack trace.
So both houses of cards are real; they just collapse in different directions. The product manager’s is structural. It stands on stage, takes its applause, and folds in production the first time reality declines to follow the script. The engineer’s is commercial. Flawlessly built, exquisitely tested, solving a problem no customer actually has; or never shipping at all, because there is always one more abstraction worth polishing. Both are failures. But they are not symmetric in the one way that settles this argument. The product manager’s failure traces back to the missing half with the hard floor: the expensive one. The engineer’s failure traces back to the missing half with the soft floor: the one that mere exposure quietly repairs. Both sides fall down. One side’s repair is cheaper. That’s the asymmetry one more time, read from the wreckage instead of the blueprint.
For now
So far I’ve only admitted the claim could be wrong if the tools change. Let me go further and admit something worse: the claim is going to expire even if it’s right, and I’d rather say so now than get caught later pretending I’d found a moat where there was only ever a head start. The speed is very different this time around.
Agents are getting better at checking their own work: writing their own tests, type-checking themselves, running adversarial passes where one instance critiques another, folding static analysis into the loop. Every one of those advances files the hard floor down a little. The morning an agent can reliably catch its own race condition is the morning the product manager’s expensive missing half goes on sale, and the engineer’s head start begins compressing toward nothing. This is not a permanent ranking of two professions carved into stone. It’s a photograph of a moving thing, taken in 2026, and the thing is moving. Moving very fast.
The floor did rise. It rose for everyone. A product manager who can now stand up a working prototype instead of a deck of rectangles is genuinely more powerful than the one who could only file a ticket and wait, and that is good. Democratization isn’t wrong. I think it’s oversold. It looked at a floor that had risen and announced that the ceiling was gone but the ceiling is exactly where it always was. The combination this role actually demands, product sense welded to the technical depth to verify, is rare measured from either starting line. That’s the line item the pitch leaves off the invoice.
If you’re a product owner/manager want to learn more on building working prototype, watch this YouTube. They prototyped 5 features in 84 minus (Bolt, Cursor, Lovable, Replit, V0).
But if the question on the table is who’s better positioned to clear that ceiling right now, at this moment, with these tools; the honest answer refuses to split down the middle. Today, the on-ramp runs from engineering, and it’s the shorter one. That isn’t a prophecy, and it isn’t forever. It’s just the bet I’d make with my own money, this morning, before the tools get another release closer to making me wrong.
