What changes when AI agents join the product team?

Key idea 1 of 6

The newest builder on the team can’t ask what you meant

Picture the people who build a product: a designer, an engineer, a product manager. Now add one more. It writes code, assembles screens from the design system, runs the tests and opens a pull request for review, in minutes rather than days.

That builder is a coding agent, and it’s already on a lot of teams. It’s fast and it doesn’t tire. It also can’t do the one thing every new person does in their first month: ask what you meant.

Someone new to a team learns the system two ways: from what’s written down, and from asking the people nearby about everything that isn’t. Why is this button secondary here? When do we confirm, and when do we offer an undo? Over a few months the reasons rub off. An agent only gets the first way. Whatever isn’t written down, it decides on its own.

A new person on the team

• Reads the documentation
• Asks the person at the next desk about the gaps
• Picks up the reasons over months

A coding agent

• Reads the documentation, the tokens and the code
• Can’t ask, so it guesses or stops
• Starts every task from what’s written down

The teams that run the largest design systems have noticed who their new readers are. Netflix’s Ben Lister and Szymon Chudy titled a talk on their enterprise system “Hawkins: Evolving a Design System for Humans and Agents” (opens in a new tab). Its abstract describes guardrails that keep agents inside the system’s rules, and a shared source of truth that both code and design tools read.

Figma’s MCP server (opens in a new tab) exists for the same reason. It gives an agent the system’s exact context: its variables, and the code behind each component.

Whatever the system doesn’t write down, the agent decides. And every check still passes, because the checks only know what was written down too.

Key idea 2 of 6

A paved road works better than a fence

There are two ways to keep a fast builder inside a system. One is a fence: lock the components down and refuse anything off the pattern. The other is a road: make the system’s way the easiest way to go, and leave exits for the cases nobody foresaw.

A fence prevents mistakes. It also prevents the new thing the product needed, and people learn to route around it. No fence at all is worse. An unguided agent will happily build a fourth data table beside the three the team already has, and each one will look fine.

Chudy calls Netflix’s answer a paved road (opens in a new tab). A September podcast episode with Chudy covers shipping codemods and AI skills with every breaking change. It also covers shipping skills, MCP servers and context so agents can use the system. By the episode’s notes, more than two thousand apps depend on Hawkins. That’s too many to fence one at a time.

Other teams are paving the same way:

• Atlassian’s design system team (opens in a new tab) calls its version a context engine, made of an MCP server, context files and skills. The team reports 52% better accuracy on design system tasks, done 34% faster.
• GitHub’s Primer (opens in a new tab) gives agents its guidance on usage and accessibility, plus tools that lint tokens and review alt text, so the guardrails come with the road.
• Figma (opens in a new tab) draws the loop that makes the work pay off: a more robust design system gives better AI output, which improves how the two support each other.

A road also needs exits, and the exit is where design judgment shows. The experiment behind Agent Review, my prototype for supervising coding agents, had a written rule for this. An agent could change a shared component, but only with a reason in writing. After review, the rule spells out what counts as a reason: what was measured, where, before and after. The exit is marked, and taking it leaves a record someone can read.

A fence

• Blocks anything off the pattern
• Every exception is a ticket and a wait
• Builders learn to route around it

A paved road

• The system’s way is the easiest way
• The context ships with the system
• An exit with a reason, and a record of it

Make the right way the easy way, and mark the exits.

Key idea 3 of 6

Write down what things mean, not only how they look

Take a confirmation dialog. Most design systems specify how it looks: the button colors, the sizes, the type, the spacing. A builder that can’t ask needs everything around the look as well.

1. 01Looksthe colors and sizes most systems already specify
2. 02Whenwhich actions need one, and which take an undo instead
3. 03Wordswhat the warning says, in plain terms
4. 04Accesswhere focus goes, and what a screen reader hears
5. 05Unclear intentstop and ask, with the evidence

That’s product judgment, written down where a builder can use it. Molly Misek’s team at Justworks (opens in a new tab) did the same for everything the product says to a customer. Every message became either a task, something to do, or a notice, something to know. Each type then carries its own trigger, priority, expiration and persistence.

Here’s why that matters once an agent is involved. This is an illustration, not a Justworks feature: a workplace assistant notices that an employee’s benefits enrollment is incomplete. It could:

• Remind the employee
• Interrupt their employer with an urgent alert
• Quietly prepare the paperwork
• Do nothing, because the deadline is weeks away

A language model can write a persuasive message for any of the four. Choosing among them takes exactly what Misek’s taxonomy writes down: whether this is a task or a notice, what triggers it, how urgent it is, and when it stops mattering.

Agent Review has an example in color. One red marks a failed payment on one screen and a replaced plan on another, and every check passes whichever token the agent picks. Whether those two should mean the same thing isn’t in the code. I wrote that one up in What a design system needs to explain to an agent.

The meaning is the part a builder who can’t ask will get wrong.

Key idea 4 of 6

Drafting an interpretation isn’t the same as owning it

Agents don’t only build screens. More and more, they write the analysis, the summary and the recommendation a person acts on. That puts a new state in the product: written by the system, not yet owned by anyone.

Tushar Roy’s case study (opens in a new tab) of measuring security work at Apple shows that state handled well. An agent investigates any metric that breaks its control limits and writes up what it found, reasoning and confidence included. The write-up stays marked as a draft until the person accountable for the metric checks it and signs off. The case study reports BI coverage going from 30% to 75% in three months, and onboarding from two months to five days on average.

The decision underneath is a balance. The AI doesn’t wait for a person before it starts, and the person doesn’t do every first pass by hand. The system only has to keep two things apart: an interpretation, and someone taking responsibility for it.

1. 01Draftedwritten by the system, and labeled as a draft
2. 02Reviewedthe accountable person checks the evidence
3. 03Ownedsigned off, and now the official answer

That’s a design system problem, not only a screen problem. If the system has no look, no words and no rules for “the AI wrote this and nobody has checked it,” every builder invents their own, or leaves it out. What else a system needs once AI hands it claims instead of facts is in What does a design system need once AI is in the product?

Agent Review keeps the same line for its own rules. A reviewer’s answer becomes a standing rule only if a person opts in, and the rule records where it applies and why.

A draft is a state, and the system has to be able to say so.

Key idea 5 of 6

One rule now repeats across a hundred screens, for better or worse

A component built wrong used to hurt the handful of screens where somebody placed it. A rule written wrong now spreads to every screen an agent builds from it, as fast as the agent builds.

The two reds show how quietly that happens. Today they share one red, so nothing looks wrong. Make the danger red louder someday, and every replaced plan that borrowed it gets louder too. A routine plan change would start to look like an error, on every screen at once. That’s one decision about one token, made by a builder who couldn’t ask.

It works the other way too, and that’s the opportunity. On the SAP program I led, more than forty apps were built by different teams at different times. A style guide reached the people who read it. A UX and accessibility check written into the release process reached every team that shipped, including the ones that never opened the guide. While the program ran, UI defects in production fell by roughly half.

A component, before

• Reached the screens someone placed it on
• Was reviewed one screen at a time
• A mistake cost a screen

A rule, now

• Reaches every screen an agent builds
• Is reviewed once, where it’s written
• A mistake repeats everywhere, and so does a fix

So review moves upstream with everything else. The rule an agent reads before every run deserves the scrutiny a screen used to get, because it will produce hundreds of them. Review the rule as carefully as you once reviewed the screen.

Key idea 6 of 6

A system is only as good as the judgment written into it

None of this makes the system the point. A well-governed design system full of mediocre decisions produces mediocre work, consistently and at scale. The rules are only as good as what the team knew when it wrote them.

So the judgment has to come from somewhere real. On the SAP program it came from sitting with people during their workday and putting feedback inside the apps, so the teams building them heard from the people using them. In Agent Review it hasn’t come yet. It’s a working prototype that plays simulated runs, and I haven’t tested it with anyone. Its rules are my best guess until people supervising real agents tell me otherwise.

That’s where the designer’s job is moving: less drawing every screen, more deciding what every builder reads.

• Which decisions the system makes on its own, which need a review, and which are never handed over without someone’s explicit say-so
• What each part means, written where an agent will find it
• Where the system admits what it doesn’t know, instead of hiding it
• When following a rule would produce the wrong outcome

A system can carry a team’s judgment to every screen. It can’t supply the judgment.