Most of the AI-era role debate sounds like this: can product managers code now? Can designers build features? Can marketers make their own tools? Those are fair questions. They're also too coarse to explain what's actually happening.
I've spent a good part of the last two years running prototyping workshops for people whose titles have nothing to do with building software, and the thing that surprised me wasn't how much they could produce. It was how quickly the interesting question stopped being "can you build this" and became "should you be the one who ships it."
That second question is the one titles are bad at answering. A title is a compressed guess about what someone can do. We accepted the compression because tracking real capability was expensive. AI is making capability cheaper to learn and cheaper to see, so the guess gets worse and the alternative becomes affordable.
Roles are bundles of capabilities, and AI is starting to unbundle them. The unbundling is happening in the work first: in who can do what, at what level, and with whose review. The org chart will take longer, and in most places it should.
Titles are a compressed guess
Roles exist for good reasons. Companies need them for hiring, compensation, and career development, and nobody wants to run a large organization by treating every person as a completely bespoke snowflake. That way lies chaos, and probably a very sad HR business partner. Some capabilities are also worth more together. A person who holds the customer, the strategy, and the priority call in one head saves everyone a lot of handoffs.
Titles are still shortcuts, though.
A title tells you where someone sits in the organization. It does not tell you, with much precision, what that person can actually do, at what depth, based on what evidence, in what context, and with what level of autonomy.
Think about two product managers on the same team. One is excellent at strategy and executive narrative and can also build a rough prototype when it saves a week of back-and-forth. The other has no interest in implementation and is every bit as valuable. Same title, same level, genuinely different shapes. People are spiky and roles flatten them. That was true long before AI.
It's also why "can PMs code?" goes nowhere. It mixes several questions into one: capability, context, evidence, review, and who owns the outcome. Reading a technical tradeoff, shipping to a low-risk surface, and approving a security-sensitive change are wildly different capability levels wearing the same word. The title collapses all of it into a single proxy.
What AI changes: the cost of learning and the cost of seeing
The first change is the obvious one. AI makes the activities inside product development easier to learn. Product managers can prototype. Engineers can explore product tradeoffs without a translation layer. Teams in research, support, and operations can build workflows that used to need long chains of handoffs. The movement runs in every direction at once, which is why framing it as one function borrowing from another misses it.
The second change gets less attention, and I think it matters more. Roles won in the first place because fine-grained capability data was expensive. Nobody could track what every person could actually do, so we compressed it into a title and took the loss. That side of the ledger is changing too. When the work happens in prototypes, review threads, and shipped artifacts, evidence of capability is exhaust from the work itself rather than a form somebody fills out.
I got a sharp view of this when a few of us rebuilt part of our PM interview loop earlier this year. We replaced an hour of candidates describing past work, which mostly measures how well someone narrates, with an hour of live building. It showed us things about prompting, iteration, and judgment that the old format never had, and I'd assumed for years that it did.
A capability profile shouldn't be a database anyone maintains. It should be something you could reconstruct from what a person has built and how it held up once someone else looked at it. If your version needs a quarterly self-assessment cycle, you've rebuilt the performance review and given it a badge. And if it turns into scoring everyone's output, people will learn to produce whatever the score counts. Evidence stays useful only while it's a byproduct of the work rather than the point of it.
Plan around the work, not the titles
Put those two changes together and a different planning model becomes practical.
Individuals have capability profiles, and workstreams have capability needs.
A capability profile describes what someone can do, at what level, and on what evidence. A workstream map describes what the work requires, given its scope and risk. Put the two next to each other and the planning conversation changes. It doesn't take a transformation program to start. In planning, ask:
- What outcome is this workstream accountable for, and who owns it?
- What capabilities does the work require, at what level, given the scope and risk?
- Who has evidence of those capabilities, or the capacity and appetite to grow into them with review?
- What still needs a second set of eyes, and whose?
That's a sharper conversation than "do we have a PM, designer, and engineer assigned?" Sometimes the answer is still yes, you need all of them. Great. Nothing here argues otherwise. It just makes the reasoning explicit.
It also makes growth more deliberate. Someone can work at a lower level of a capability, with review, without pretending to be an expert, or go deep on something outside their title without needing a role change to justify it. A manager can see where the team overlaps and where it's genuinely thin.
Autonomy follows evidence, risk, and review
The word doing the work in all of this is "evidenced." Capability shouldn't rest on self-description, vibes, or enthusiasm.
Evidence can come from demonstrated work, manager assessment, peer attestation, senior expert review, artifact review, structured exercises, or formal certification for high-risk capabilities.
Most capabilities don't need a certification path, and I'd resist building one. If every level of every capability requires a formal process, you've just built bureaucracy with a better vocabulary. Some work does need stronger validation before anyone acts alone: customer data handling, accessibility signoff, production-critical review. "The AI seemed confident" shouldn't get anyone across those lines.
Validation is about trust, and the badge is just bookkeeping. When someone's validated at the right level, it should shape what they can do alone, what still needs review, who's allowed to review others, and eventually what permissions they hold in the systems where the work happens.
A product manager can be perfectly capable of building a prototype and still need engineering review before it goes to production. A support leader can spot a workflow worth automating and still need a privacy review before it touches customer data. Neither of those is a demotion. That's what the work looks like when capability and review are tracked separately.
Someone still has to be accountable for the result, and the model only holds together if that accountability gets sharper as contribution gets more flexible. AI raises the ceiling on how much one capable person can touch. It raises the importance of knowing exactly where their work needs another set of eyes by the same amount.
This is not everyone doing everything
This idea can be misused, and I'd rather say so plainly. It can become "AI means everyone can do more, so we need fewer people," or a permission slip to push people into work they aren't good at and don't want to own. The most seductive version is the polished-output one, where a leader waves off craft expertise because what the model produced looked good enough in a meeting.
I'm not pointing at somebody else here. I've written the org-design argument myself: flatter structures, fewer overlapping roles, wider spans. I still think most of it holds up. I've also learned that an argument like that gets picked up as a headcount exercise almost immediately, because that's the fastest thing anyone can do with it. If you're going to make the case, you own where it lands.
The test has to be organizational rather than personal: did the whole system get better, or did one person just get faster? If unbundling capability creates more low-quality work for everyone else to inspect and redo, then congratulations, you didn't improve anything. You moved the bottleneck and made it more annoying.
That's also why functions don't go away. Engineering still needs architecture judgment and operational discipline. Design still needs critique and accessibility expertise. What changes is what a function is mainly for. It stops being the gate that decides who's allowed to do the work and becomes something closer to a guild: the people who define what good looks like, review the work, and validate the higher-risk levels, for a community that's now wider than the function itself.
The goal is not to have everyone do everything. The goal is to match work to evidenced capability, with the right review and ownership model.
The reward system decides whether it sticks
Ladders, promo packets, and comp bands are all indexed to roles, and people are very good at doing what the packet rewards. If the capability someone stretched into never shows up where their promotion gets decided, they'll stop stretching, and the model quietly reverts to planning by title with extra steps.
You don't have to rebuild compensation to start. You do have to make sure promo criteria can see evidenced capability outside a role's home turf, and that managers actually write it down.
The next bundles
Unbundling rarely stays unbundled. Music came apart into tracks and recombined into playlists, and capabilities that come apart will recombine too, around new seams. You can already see one in the product engineer, a title that has spread quickly over the last few years, where one person carries product judgment and implementation together. That's a new bundle rather than the absence of one, and it points the opposite way from what "unbundling" suggests: when learning gets cheaper, one person can hold more, so some of the new bundles will be broader than the old ones.
I don't expect large organizations to follow that curve quickly, and most of them shouldn't try. My guess is that in established organizations roles stay roughly where they are, and the gap between those roles and real capabilities gets harder to ignore every year. Today's bundles stop being the only defaults, and the organizations that read capability well will be the first to notice which new ones actually hold.
Asking whether PMs can code turns a system-level shift into a title fight. Keep planning by title alone and you'll misread both the work and the people you have to do it.
The future of product development may not be fewer roles. It may just be fewer excuses to hide behind them.