Someone asked me a question I keep coming back to. AI now lets designers and product managers ship working code to production, not just describe it. The question is whether they should. Is blurred roles the new normal, or should people stay in their lane and let AI make their existing role faster?
There is a real case for both, and the debate usually goes wrong when one side gets reduced to a strawman. So before I give my answer, I want to give each side its best version.
The case for shipping
The strongest argument for letting people ship is that the handoff is where truth gets lost. A product manager explains an idea to an engineer. An engineer interprets it. A designer sees the result and it has drifted from the intent. Each translation shrinks the idea a little. AI mostly removes that cost. A PM who can build a working prototype tests the actual idea instead of a description of it. A designer who can ship a front end shows intent instead of annotating it.
The second argument is velocity. A small team that can ship directly runs more experiments per week. That matters when the constraint is feedback. You learn faster from real users than from a spec review, and the teams that can turn an idea into something real in an afternoon are the ones that get more chances to be wrong quickly and cheaply.
The third is ownership. The person who understands the customer keeps their hands on the work instead of filing a ticket and waiting. Momentum stays warm. Nothing gets parked in a queue where it cools off.
That case is real. I have watched it work in small teams and early stage companies, and I am not going to pretend the speed is not valuable.
The case for staying in the lane
The other side is just as real, and it starts with a word people forget: production.
Production is not a sandbox. Shipping to production means you are now responsible for security, reliability, access controls, compliance, error handling, incident response, and often the customer’s data. Those are not vibes. They are professions. The fact that a tool lets you produce code does not mean you can operate it at 2am when it breaks and a customer is on the line.
The second argument is the distinction Zack’s question was already pointing at. “Can” is not “should.” The technical gate that used to sit between an idea and production did not exist only to slow people down. It existed to attach review, standards, and accountability to a change. AI removed the gate but it did not remove the reasons the gate was there.
The third is that judgment and execution are different jobs, and they can be in tension. A strong product manager makes a call about what matters. A strong engineer holds the line on how it gets built so it does not collapse later. Blur those into one person too far and you risk someone cutting corners on the thing they are not measured on, or confusing their opinion about the product with the discipline of shipping it.
That case is real too. I have watched unshipped prototypes and unaudited deploys cause exactly the kind of quiet damage that no one notices until a quarter later.
Neither side is the real question
Here is the thing I actually keep coming back to.
Whether a designer ships code is not a universal yes or no. It goes back to the business. A two person startup and a regulated bank answer that question differently, and both can be right. The startup needs the blur to survive. The bank needs the lane to stay solvent and compliant.
So I do not spend much time arguing about whether the roles should blur. I spend my time on the problem that shows up no matter which way you answer.
How are those changes being communicated?
AI removed the bottleneck on building. It did nothing for the bottleneck on understanding.
That speed the first camp wants is exactly what makes the second camp nervous, and both of them are only half right. The person shipping is not the problem, and the person refusing to ship is not the problem. The problem is that the organization’s ability to understand what changed has not kept up with its ability to change things.
The question nobody can answer
Here is a simple test. Ask someone in Support, Sales, or Customer Success what changed in the product this week, how it works, and why we did it.
In most companies the honest answer is a shrug followed by a search through Slack.
That was already true before AI. Shipping velocity makes it worse. When three teams can each ship meaningful changes in a week, the shared picture of the product starts to lag behind the product itself.
The people closest to the customer find out about changes from the customer. A support agent learns about a new flow because a ticket describes it. A salesperson promises a capability that got quietly removed. A customer success manager demos a screen that no longer exists.
None of those people failed. The system for carrying knowledge failed.
Speed without shared knowledge is just faster confusion
Companies tend to treat this as a communication problem, so they reach for communication tools. More announcements. More release notes. A bigger newsletter.
Announcements do not scale either. They arrive out of context, compete with everything else in the channel, and describe what shipped rather than what it means for someone’s work.
The support agent does not need to know that a change shipped. They need to know what to say when a customer hits it. The salesperson needs to know whether it changes the pitch. The account manager needs to know whether it affects the renewal conversation next week.
Same change, different meaning. A broadcast cannot carry that.
AI scales the mess
Let me be precise here, because the framing is what matters most.
The problem is not that more people are shipping. The problem is that communication was already siloed, and shipping faster through the same silos does not fix them. It feeds them.
Look at how a change reaches the company today. Support keeps its own picture of the product. Sales keeps another. Customer success keeps a third. Each team maintains what it needs to do its job, and none of them fully trusts the others, because each has been burned by a source that turned out to be stale.
Now layer AI on top. AI is a multiplier, not a fix. It multiplies whatever structure you already have. The company does not get one shared understanding. It gets three faster, more confident versions of the same divided picture. Each team’s AI summarizes the product from each team’s stale record, and the summaries disagree without anyone noticing.
I have written before that automating a messy process gives you the mess at scale. Communication is no different. Automating the way a siloed organization shares knowledge does not unify it. It produces the silos at scale.
That is why the “should they ship” debate is the wrong focus. The question is not how many people ship. It is whether the organization has one shared picture of what shipped, or many partial ones.
If you do not solve for communication in parallel with the AI adoption, you do not get clarity faster. You get the same silos, the same gaps, the same customer finding out from support what the product already does, now multiplied across every team and every change.
What actually scales
The companies that handle this well treat knowledge about a change as part of the change itself.
A decision record that captures why, not just what. A changelog written for the people who have to explain the product, not for the people who built it. Demos as a standing ritual, so the organization sees the work instead of reading about it. A shared source of truth people trust because it is maintained as an operating agreement, not a document that was accurate once and then drifted.
Notice what all of those have in common. They assume the change is not finished when the code merges. The change is finished when the people who have to act on it understand what it means for their work.
That is the same context problem that shows up everywhere else in AI transformation. The information exists. It just does not reach the person who needs it, in the form they need it, at the moment they need it.
AI can help, once the knowledge exists
AI is part of the answer here, in a way that is easy to get backwards.
A system that knows what shipped, why, and who it affects can answer “what changed for my accounts this week” far better than a newsletter can. It can turn a firehose of merge logs into a short, role specific brief. That is genuinely useful.
But it only works if the underlying knowledge was captured in the first place. Feed an AI a mess of commits and closed tickets and you get a plausible summary, not a reliable one. The model reflects the record. If no one wrote down why a change happened, the system will confidently make one up.
So AI does not replace the hard part. It rewards it. The organizations that write down the “why” actually benefit from these tools. The ones that skip it get a faster way to be wrong.
The new constraint
For years the constraint on product organizations was how fast they could build. Communication habits formed around that pace. A weekly update was enough when meaningful changes arrived weekly.
When everyone can ship, the constraint moves. The limiting factor becomes how fast the organization can absorb what it just did.
A company that builds faster than it understands itself is not moving faster. It is generating more confusion per week.
Which brings me back to the original question. Should designers and product managers ship code? My answer is that it depends on the business, and it matters a lot less than people think. The thing that will decide whether it works or backfires is not who ships. It is whether the rest of the company can keep up with what you shipped.
The fix is not to slow down building. It is to treat shared knowledge as infrastructure, with the same seriousness as the systems that ship the code.