Teach engineers to sense, or product folks to vibe code?

Two skilling bets are on the table in almost every tech organization right now.

Skill the product managers to vibe code — prompt an AI, get a working prototype, stop waiting for engineering. Or skill the engineers to sense — customer understanding, product thinking, discovery. Stop waiting for the spec.

Both respond to something real: AI collapsed the translation cost between deciding what and building how. The old assembly line — PM writes the spec, design draws it, engineering builds it, QA checks it — was a line of hand-offs, and the roles were defined by those hand-offs. The hand-offs are dissolving. The roles are bleeding into each other.

So companies are evaluating the instinctive move: pick which individuals learn whose skill. And both versions of the bet get it wrong, for the same reason.

The barrier was never the skill

Play the bet forward. The skilling program runs; here's the day after.

The product manager can now vibe-code a prototype in an afternoon. Can they ship it? No — and not because the code isn't good enough. Because shipping needs engineering judgment (what breaks at scale, what's maintainable, what's safe) and it needs authority the PM doesn't hold. The prototype joins the backlog like everything else.

The engineer has done the sensing module. Will they meet a customer next week? Nothing in their week changed — so no. Sensing isn't a framework you learn. It's an exposure you get. If the org doesn't change the exposure, it's just bought a course.

One of these is commoditizing. The other compounds.

Look at what each bet is actually buying.

Vibe coding is a skill — a floor anyone can be taught to stand on. And it's commoditizing by the quarter: the models do more of it, better, every release. Its value is real and falling.

Judgment — engineering judgment, customer judgment — is a capacity. It's built through repeated, varied, real exposure with something at stake. It can't be taught in a room, and it appreciates: the more decisions it makes, the better it gets.

That's investing backwards. The scarce thing was never "can this person produce code" or "can this person recite discovery questions." It's: can this person carry a decision well — and that is built by carrying decisions, not by attending sessions about them.

The question assumes the individual is the unit. It isn't anymore.

"Which individuals should we skill, on what?" — the question only makes sense if capability lives in individuals.

But the thing AI actually made possible is a smaller complete unit: a few associates — product and engineering together — plus agents, sharing one live context, holding real authority over one outcome. Inside that unit, the PM's vibe-coded prototype isn't a hand-off; it's a conversation that starts at lunch and ships by Friday. The engineer doesn't need a customer-empathy course; the customer's voice is in the room, because the unit owns the outcome, not the ticket queue.

In that unit, the skills take care of themselves — people pick up in weeks what programs fail to install in quarters, because the structure demands it daily. Without that unit, the new skill dies in a month, quietly, in the backlog.

So the honest answer to "which skilling bet?" is: neither, first. Redesign one unit. One outcome, shared context, real decision authority, product and engineering and agents inside the same loop. Then watch which skills people pull toward themselves — and spend your training money there.