There is a lot of writing about AI and design. Most of it is written from the outside: predictions about what designers will do, arguments about whether the role survives, and demonstrations of what a tool can make in an afternoon. To my knowledge, very little of it comes from people doing this work inside large enterprise software companies, at the scale of a platform, with the problems that scale produces. This post is what the situation looks like from there, based on the work we have done over the past year. It is written for the people who lead design inside those companies, and for the executives they report to.
Three things have become true at the same time
Teams have been working with AI at speed long enough for the problems to show. Two years ago the question was whether teams would adopt the tools, and they did. Capabilities that used to take months now take days, and inside a platform they can be built by an internal team, a partner, or a customer. Platforms are filling up faster than anyone can say what is in them.
Infrastructure spending has reached the point where the organization is asking for results. Companies have bought the models, built the internal tools, and run the enablement programs. The people who approved that spending are asking what changed. Enablement leads are being asked for impact rather than activity, and design leaders are being asked to justify each project instead of drawing on a standing budget.
The problems that have appeared are design problems. Two years ago design was widely described as a function AI would make unnecessary. What has shown up instead is a set of problems design has always been responsible for, now at a scale and speed the old ways of working cannot handle: what the parts of a product are, how they relate, how a rule gets applied by people and systems that never met the person who wrote it, and how people actually change the way they work.
What the problems look like
The problems fall into three kinds.
The old sources of product rules have stopped working. At most platform companies, the org chart supplied the rules of the product for years without anyone writing them down. A product was whatever a business unit owned, and a capability lived wherever its team sat. Platforms and agent-built extensions remove those boundaries, and nothing replaces them until someone writes down a model of what the kinds of things are and how they relate. When agents are participants in the product rather than features of it, the model also has to say what an agent is, and nobody has answered that question by default.
Until that model exists, the same word means different things on different screens, and every argument about where a feature belongs is won by whoever is most senior in the room. Once it exists, most placement decisions follow from it. The model has to come before the guidelines, which is the reverse of how design guidelines usually get written.
Design judgment has to travel without the designer. In every large product organization, the questions about what a thing is and where it belongs end up with one or two people. They cannot be in every room, and increasingly the room contains a coding agent rather than a person. Guidelines written for people are read at review time, if at all, while guidelines an agent can apply are used at the moment something is created. A design system covers components and patterns, and that is still necessary, but it does not cover what an app is or how an agent should behave. Those rules have to be written in a form that both a person and a machine can apply.
Encoding the rules is only half of the work. A written guideline has never had a feedback loop; nobody measured whether a document changed what got built. A guideline that agents apply can be measured. You can see how often output conforms, where it fails, and which rule the failure traces to, and then change the rule. Guidelines stop being a document that is published and become something maintained by evidence about how it performs. Deciding what a rule should have said after watching it fail is judgment work, and it belongs with the people who own the judgment.
The way of working has to change, and the tool is the smallest part of it. In enablement work we completed this year, with more than a hundred product managers and designers across a dozen teams, the teams already had the tools. The teams that got value were the ones with shared, governed context an agent could work from: the product's vocabulary, its patterns, its current state, its constraints. The people who did not adopt were not opposed; they were short on time and unconvinced the tools would help them personally, and what moved them was watching a peer do real work with the tools and having a week in which experimenting was the job. The designer's day shifted toward specifying the goal, the context, and the expected output, and then evaluating what came back.
Why this is design's job
None of these problems is solved by a better model or a bigger budget. They are the questions the practice of design has always been organized around.
Design makes models of things before they exist. A product definition, an information architecture, and a mental model are all that, and a model is the missing piece when a platform has outgrown its org chart.
Design writes rules that other people apply, and design systems are the precedent: a way to encode judgment so that hundreds of people who never met the author produce consistent results. Guidelines that agents apply, and that are tuned by watching how they perform, are the next version of the same practice.
Design finds out what is true by studying how people actually work. Adoption is a behavior problem, and behavior is what design research is for.
There is also a reason this work is often done with help from outside. A model of what a platform is has to cover every business unit, and no internal team owns the whole. An outside team can hold the whole picture, ask the questions no single team is positioned to ask, and work on the model full time while the product teams keep shipping. Firms that have done this inside more than one large company carry the patterns from one to the next.
What to do with this
If you lead design at a large platform company, four questions will tell you whether you are at the point this post describes.
- Do arguments about where a new capability belongs get settled by whoever is most senior in the room, rather than by a rule anyone could point to?
- Does the same word mean different things on different screens of your product?
- Are your guidelines read at review time, if at all, while agents and internal builders create things that never reach a review?
- Has your executive started asking what the AI spending changed, and do you have an answer that is about the product rather than about activity?
If most of the answers are yes, the job of deciding what things are and where they belong, which I have been calling the framing layer, is open in your organization, and someone will take it. If design does not, engineering convenience will: a capability becomes a standalone app because that is the easiest thing to build, the product accumulates apps, and the next capability has even less to attach to. Nobody chooses that outcome; it is what happens when nobody owns the model.
The case to make upward is a case for coherence rather than for design, because coherence is what your executive is now paying for and not getting. Ask for ownership of the model of what the product is, before the next round of building rather than after it. Commit to a first result inside a quarter: the model, the first set of rules that follow from it, and one place where those rules are applied automatically and their performance is visible. Name the measure in the executive's terms, which is usually fewer things built twice, fewer things that have to be moved, and less time between a decision and a shipped result. Define done as something your executive can see without you in the room, because the work will be judged by what is visible from two levels up.
If this describes where you are, I would like to hear how it looks from inside your organization. Message me on LinkedIn.