A few years ago, when I was working on IBM Carbon, one of the business-unit teams came to us with a request.
They wanted to copy the Carbon website.
The whole thing.
They wanted to replicate all the docs, components, guidance. All put into their own business-unit specific site, where they could add some of the things Carbon didn’t provide.
The argument was pretty weak, I thought.
Nobody will check two websites to understand one design system.
My instinct was no. For two reasons, one of which was bad and one of which was good. One design system. One centralized, controlled source of truth. And if they copied the site, their version would start drifting from ours almost immediately.
Their solution to a made-up problem of clicking on two sites was to create two versions of the truth.
That seemed obviously bad.
The website wasn’t the problem
There was an underlying usability problem. All of the business units had it. But it was an organizational one.
They all needed to do things that the core system, and the core Carbon team, didn’t - and couldn’t - support.
Some were things genuinely specific to their products. Others were patterns that the central team didn’t have any reason to own. And in many cases, the business unit teams were simply closer to the problem.
But all these deviations were really about answering one question.
Who gets to decide?
If Carbon was the IBM standard, could a business unit add to it? Could they override it? Could they create something completely new? Did they need our permission every time?
The request for another website was really a request for some kind of infrastructure to support these decisions.
Matt Rosno, Carbon’s product manager at the time, understood it faster than I did. Don’t treat the these business unit libraries like competing design systems. We didn’t need to stamp them out. We needed a way to lean into them.
Carbon became the hub. Business units could build spokes around it.
We put some boundaries around what belonged in core. What was local. That everything needed to be shared. And how useful work might flow back upstream.
I wrote about that model on this site back in 2022.
It wasn’t really about architecture or tools. The important decision was whether - and to what extent - local teams had authority to extend the system.
Everything else followed.
Tools make authority visible
Organizations know how to make tooling decisions.
Security review. Procurement. Architecture review. Budget approval. Vendor assessment. Seats and/or consumption.
That doesn’t mean the process isn’t painful - we all know it can be excruciating. But everyone understands the basic question.
Can we use this thing?
Except that some seemingly basic technical requests have another question underneath.
Am I allowed to do this with it?
Can a team create an exception? Can someone publish without central approval? Can the engineering team change this part of the platform without waiting for another group? Can a product leader make a decision that contradicts the default?
Can an AI agent?
That’s not a tooling question.
That’s an authority question.
Organizations are much less comfortable answering those.
So authority will default to whoever controls the infrastructure.
The central team has to approve everything...because they own the repo. Design exercises final judgment...because they own the Figma library. Engineering is the real arbiter...because it controls deployment. And so on.
Nobody decided if those groups should have the authority. Or whether they even want it. The tooling made the decision for them.
But that’s rigid. And when structures don’t match the reality of how they work, people will find a way around it.
Fork the repo. Build another site. Make a spreadsheet with the data. Install a new extension. Start a new Slack channel.
If the official system doesn’t answer the request hidden underneath the request, some unofficial solution will likely appear.
AI makes this even weirder
I increasingly think of AI as a medium rather than a tool.
A medium is the form of something. A tool is something you use inside that form.
Figma is a tool. Digital design is the medium.
A camera is a tool. Photography is the medium.
A word processor is a tool. Prose is a medium.
But AI is stranger than that, because it can act as a medium across mediums.
ChatGPT is a tool. AI is the medium.
But I can use ChatGPT to make AI produce prose - another medium. Same for image generation, code, music, video.
AI can sit underneath multiple forms, generating material inside them and changing how we work with them.
Treating AI adoption as a software procurement exercise is really incomplete. But most enterprises are approaching it as a tooling program.
Approve a model. Choose a vendor. Buy some Copilot seats. Restrict the data and set the token limits. Decide which MCP servers are allowed.
Good questions. But also questions that we have existing infrastructure for.
The next questions get much more consequential.
If an engineer can describe a change and have an agent make it. Who has authority over that implementation?
A product manager connects customer conversations to roadmap data and account context. An agent continually interprets new evidence. Who has authority to change priorities?
More generally, AI is reducing the need to create the intermediary artifacts and abstractions. And those handoffs are part of what our organizations have been built around. So who owns what decision when those handoffs start disappearing?
And then there is a different question again.
If the medium is changing, what does expertise even look like?
Buying someone a camera doesn’t make them a good photographer. Equally, I can give someone access to an AI coding agent. That doesn’t mean they’ll be good at agentic software development.
But it also doesn’t mean they won’t be. Prior expertise doesn’t necessarily map cleanly.
The novice photographer may prove a natural. The best agentic developer might not be the person who was best at writing code by hand. Someone who couldn’t build software at all might be the best person to direct systems that can.
Craft changes. Judgment, and the definition of success and failure changes. Yes, the shape of the work does change.
Which is why a lot of enterprise AI discussions seem like they’re missing the bigger picture. They’re spending enormous amounts of time and energy deciding on the tools people might use. And they’re treating the organization around those tools as fairly fixed.
It isn’t.
Capability is only one layer
We have at least three decisions now.
Tooling: Can someone do the thing?
Authority: Is someone allowed to do a particular thing?
Medium: Has the thing itself actually changed?
If we give someone capability but not authority, then we run into bottlenecks. If we give them authority without the capability to exercise it, the authority itself is a fiction. They still depend on someone else to be able to act.
And now, if we treat a change in medium as another tool rollout, we’re optimizing workflows where the assumptions might be disappearing.
The Carbon example above was a small version of this. A team asked us for another website.
Whether we said yes or said no wouldn’t have itself resolved the problem.
The decision was whether they had authority, and whether they had the tools to exercise it.
Before approving the tool, ask what decision it allows someone to make.
Before designing the workflow, ask who has authority to make that decision.
And before deciding to preserve a workflow, ask whether the medium just made it obsolete.
The tooling is the easiest part.
Further reading:
The hub and spoke design system model - on how these decisions structured the Carbon Design System.
Actually, the shape of the work does change - on building faster horses or choosing to invent the car.
Norouzi, M. & Prinz, J. Is AI a Medium? The Journal of Aesthetics and Art Criticism, Spring 2026.
Phelan, L. The Procurement Intelligence Gap: Why Most Organizations Aren’t Ready to Scale AI. Supply & Demand Chain Executive, Aug 2026.