All skill, no knowledge.

Anyone can bring an idea to life now. Type a sentence into any of the prompt-to-product tools and a plausible UI comes back before your coffee does. That promise has already been cashed, for everyone, on every product.

Which is exactly the problem. A screen that looks right is worth nothing if it cannot survive contact with your product: your patterns, your constraints, what your research says your users actually do, where the roadmap is going. The interesting promise is smaller and much harder. Colleagues who can produce work that lands close to the truth of the product, and an agent that knows enough to challenge them when it does not.

Making things is no longer the hard part. Making decisions worth shipping still is.

If it were a person

Look at what we hand the AI: the tokens, the components, the styleguide. Everything the product is made of. Now hand exactly that to a person. Someone joins tomorrow, gets the library and nothing else, and is asked for a checkout flow. You would not expect anything remotely shippable, and not because they lack skill. They know nothing about the product yet: what it is for, who uses it, what was tried and thrown away, what support keeps hearing. That is what a flow is made of. The parts are the ink it is drawn with.

And yet we are surprised when what comes back from the AI is generic and fragile. Fundamentals make work consistent. Good never came from the fundamentals; it came from what people knew.

The knowledge that makes work good does not live in the system. It lives in whoever is in the room. Tokens, components, documentation: that is what gets called a design system, and it holds everything that has a shape. People carry the rest, so smoothly that nobody notices how much of the system lives in them. A design system, as it gets built, is only half of one.

An agent is never in the room. It arrives with your tokens and components, and for everything else it falls back on what it learned before it met you: patterns from a million other products, none of them yours. So it will look like your product, down to the last token, and behave like everyone else's. The flows, the principles, the way your product talks: it cannot know any of that. Sometimes it will get it right anyway, and it will not know why. Teams patch this by hand: somebody pastes the right context into every prompt, and the results improve. For that prompt. Nothing is kept, so the next one starts from zero, and the knowledge still lives in a person, who now has a copy-paste job on top. The fix is not better prompting. It is a system that already holds what the prompt would have carried.

The other half

None of this lands on a crooked foundation. If design and code disagree about what a button even is, an agent adds noise before it adds value. The parts come first.

That is also where the industry stops. Semantic tokens, documented components, a library machines can read, and it gets called AI-ready. If consistent screens are all you want from AI, fair enough, that is the finish line. If you want work that holds up against your product, it is the starting line.

What is missing comes in three kinds. Almost none of it is in the system today.

Most teams that get this far jump straight to intent, because brand and strategy are the glamorous half. Evidence is the one nobody mentions, and it makes the biggest difference to what comes out. Your design system knows what your checkout looks like. It does not know that a third of the people who start it leave at the address step.

A system that holds only parts can tell you what a button looks like. One that also holds intent, evidence and rationale can tell you what a flow should do, and back it up.

This is where people start hearing a two year knowledge project. It is not one. Nothing moves in; every pattern simply carries its own evidence, what it is for, what the rules are, what happened when you used it, pointing back at the source. One pattern at a time, the most used first. Your parts stop being a catalogue and start having a track record.

From idea to proposal

Once the knowledge is in the system, the first thing that changes is where an idea can start. Good ideas were never scarce in a product team. Support hears the same complaint every week and knows what would fix it. A product manager can describe the feature. Neither could show it, so the idea went into a ticket, or died in the hallway, and a designer got a paragraph to translate.

Now that idea can arrive as a first draft in your product's own language, drawn from patterns that already work and from what the people who built them knew. It is not finished design and it does not try to be. It is close enough to true to react to. The designer's work does not go away; it starts later and goes deeper. Instead of turning a paragraph into a first screen, they judge whether this is the best the idea can become, and take it there at the depth of their craft. And there is the quiet catch: for the draft to be any good, their knowledge has to be in the system too. Every discipline that works from it ends up feeding it.

Whenever I say this to designers, the answer comes back in capitals: judgment is my job. Correct. Nobody is suggesting otherwise. But right now your AI knows only the outer layer, so the outer layer is all it can argue about. Give it the rest and it can push back on something that matters. Anyone who has sat in a good critique knows the difference between a reviewer who read the brief and one who is reacting to the screen.

You are not handing over the judgment. You are getting a second one worth arguing with.

None of this gives AI better ideas. That is not the deal, and anyone selling it is guessing. It shows the AI the choices your brand, your strategy or last year's user test already threw out, and lets it say what it followed. And it hands you first drafts you can react to.

Something bigger happens on the way. Once the knowledge lives in the system instead of in individuals, everyone works from the same source. Design does. Development does. Product does. AI does. That is what adoption should mean now: not how many teams use the components, but how many disciplines can ask the system something and act on the answer. Small teams get that almost for free, because everyone sits close to the product. At scale you have to build it on purpose. And what your product knows stops depending on who happens to be in the room.

That is half of it. Because a person who knows everything can still ship the wrong thing, and so can the agent. What used to stop them was never in the system either.