For years, big companies loved clean role definitions.
Designers designed.
Engineers engineered.
PMs prioritized.
Researchers researched.
Everyone had their lane. Everyone had their process. Everyone had their artifact.
And everyone also had a favorite way to say, "That’s not really my job."
Then AI showed up and quietly started wrecking that neat arrangement.
Not because roles disappear overnight.
Not because everyone suddenly becomes a full-stack polymath with suspiciously good taste.
But because AI changes the economics of turning ideas into product.
And once that happens, the highest-leverage people in the room are no longer the ones with the cleanest job title.
They’re the ones who can move fastest across the boundary between idea and reality.
At a big company, that often means one thing:
The most dangerous designer is the one who can ship
The old model was built around handoff.
A designer produced flows, mocks, prototypes, and specs. Then engineering took over and translated intent into production reality.
That model was never perfect, but it worked well enough when the cost of building was high and the cost of iteration was slow.
AI changes that.
It lowers the cost of exploration.
It lowers the cost of implementation.
It lowers the cost of trying multiple directions before committing.
So the bottleneck moves.
The bottleneck is no longer just, "Can we make this?"
It becomes:
- Can we ideate fast enough?
- Can we test fast enough?
- Can we get the right thing into production before momentum dies?
- Can we preserve quality while speeding everything up?
That first question matters more than people think.
A lot of life and work advantage now lies in the ability to ideate quickly.
Not just to have ideas.
To make them tangible while they are still alive.
That is the real leverage.
At big companies, plenty of people can talk about an idea in a meeting.
Far fewer can turn a half-formed intuition into a believable interaction, pressure-test it, and ship a version before the org metabolizes it into a calendar invite.
That is where role boundaries start to blur.
In B2B products, the speed of turning insight into production matters more than people admit
This is especially true in B2B.
Consumer products get celebrated for delight. B2B products live or die on workflow.
A slightly better onboarding flow can improve activation.
A cleaner approval experience can reduce operational error.
A smarter default can save hundreds of hours across teams.
A better AI-assisted workflow can be the difference between adoption and shelfware.
A lot of these improvements die in the handoff gap.
The designer sees the problem.
The mockup captures the idea.
The team agrees it is promising.
Then it enters the queue, competes with everything else, gets translated imperfectly, and loses half its sharpness before it reaches production.
If a designer can code well enough to close some of that gap, the equation changes.
Now they can:
- prototype at higher fidelity
- test interaction details static mocks cannot capture
- validate whether a workflow actually feels better
- preserve the original product intuition
- ship improvements faster and learn faster
In B2B, that matters a lot.
Because product quality in B2B is often not about visual polish alone. It is about whether the workflow actually works under pressure.
When a designer can move quickly from insight to code to production, the company learns faster.
And in B2B, learning faster often matters more than presenting prettier slides about learning faster.
The same thing is happening in consumer products, just with different stakes
In consumer, the stakes look different, but the pattern is the same.
The value is not only in shipping features faster. It is in ideating on experience faster.
Imagine a team working on a music app, shopping app, or social product. The winning idea is often not a giant feature. It is a tiny behavior:
- how recommendations enter the screen
- how a creation flow nudges you forward
- how an AI assistant feels helpful without feeling clingy
- how a moment of surprise becomes delight instead of interruption
Those things are incredibly hard to evaluate in static mocks.
A static design might tell you what the screen looks like.
It usually does not tell you whether the experience has any life in it.
If a designer can code, they can prototype these moments much closer to reality.
They can test timing, animation, responsiveness, and behavioral nuance before the team burns weeks aligning on something that only looked convincing in Figma at 2x zoom.
That matters because consumer advantage increasingly lives in the speed of ideation.
The teams that win are often the ones that can try five experience directions while everyone else is still debating which one deserves a ticket.
In B2B, fast ideation improves workflows.
In consumer, fast ideation improves feel.
In both cases, the leverage comes from shrinking the distance between taste and reality.
Code is becoming a design material
This is the shift many people still underestimate.
Code is no longer just an implementation medium. It is increasingly a design material.
Not for every designer. Not in every situation. But especially in AI products, code unlocks forms of prototyping that are much closer to real product behavior.
A static mock will not tell you:
- whether the suggestion arrives at the right moment
- whether the user trusts the output
- whether the transition feels assistive or intrusive
- whether confidence levels are legible
- whether the interaction feels magical or just noisy
If you want to design delightful AI experiences, you often need to prototype behavior, not just layout.
And behavior lives much closer to code than to Figma.
A coded prototype lets you explore timing, motion, responsiveness, uncertainty, progressive disclosure, and how human input and machine output actually dance together.
That is where delight starts to become real.
Not in the mock.
In the interaction.
This is starting to look less like product design and more like architecture
The closest analogy I keep coming back to is architecture.
Architects are not expected to personally pour the concrete, run every project meeting, calculate every structural load, and fabricate every material.
But they are expected to understand the whole building.
They are expected to know enough across structure, systems, constraints, sequencing, and experience to be responsible for the design end to end.
They work with partners: project managers, structural engineers, contractors, specialists.
But nobody says, "Well, the architect only chose the wallpaper, the rest is someone else’s problem."
That would be insane.
And yet in product, we somehow accepted a version of that for years.
We created a world where a designer could be seen as responsible for screens but not behavior, responsible for intent but not implementation, responsible for the mock but not whether the thing actually survives contact with production.
That model is getting weaker.
The new expectation is not that designers must do every job.
It is that the strongest ones increasingly understand enough of the full system to move ideas through it.
That is a very architectural kind of responsibility.
The role is changing faster than the org chart
I do not think we are heading toward a future where everyone has one stable, perfectly defined role.
I think we are heading into a messier period where product work becomes an array of skills rather than a set of rigid titles.
Some designers will become stronger at prototyping.
Some engineers will become stronger at product thinking.
Some PMs will get better at making things.
Some researchers will become more embedded in faster iteration loops.
In the short term, this feels chaotic.
It can feel threatening because the old map stops working.
But this kind of fragmentation is not new. It is what happens before a new order forms.
There is a line from Romance of the Three Kingdoms that captures this well:
What has long been divided must unite; what has long been united must divide.
That is what this moment feels like in product building.
For a long time, product roles split into increasingly specialized functions. Now AI is pushing them back together in certain places.
Design and code are converging.
Prototyping and production are getting closer.
Strategy and execution are collapsing into faster loops.
Later, new patterns will emerge. New specializations will form. New titles will probably appear.
But right now, we are in the messy middle.
And in the messy middle, people with range win.
What big companies should pay attention to
The companies that benefit most from this shift will not be the ones that merely adopt AI tools.
They will be the ones that recognize a deeper organizational change: the distance between thinking and shipping is shrinking.
If that is true, then the highest-leverage people are the ones who can compress that distance.
That means big companies should pay more attention to people who can:
- move from concept to prototype to production with minimal loss of intent
- use code to explore experience, not just implement requirements
- ideate quickly and make ideas testable before they go stale
- combine taste, product judgment, and technical fluency
These people may not fit the old boxes cleanly.
That is fine.
The old boxes are part of the problem.
My bet
My bet is that the next generation of standout product people in large companies will not be defined by title first.
They will be defined by leverage.
Not designer.
Not engineer.
Not PM.
But something closer to this:
- Can they see the opportunity?
- Can they make it tangible?
- Can they test it in reality?
- Can they get it into production?
- Can they create something users actually feel?
The org chart will take time to catch up.
But the work is already changing.
And in this new environment, the people who can design, code, prototype, and ship are not breaking the system.
They are showing us what the next system looks like.
About Me
I’m Ling Zhou, a Staff Product Designer at Uber, passionate about delivering magical user experiences. Based in Chicago, I’m a former creative and indie filmmaker turned designer. I’m also a proud mom to a curious 5-year-old boy and a goofy 6-year-old Bernese mountain dog. Excellent on a bike, less so behind the wheel. Lover of books, aspiring fiction writer, and endlessly interested in how AI, design, and product building collide in real life.
- LinkedIn: linkedin.com/in/lingzhou
- More: linktr.ee/lingzhou