I went first, and got audited hardest.

In 2026 our stakeholders moved design implementation in-house to the design team. Agentic tooling had matured enough that a designer could carry a Figma file through to the frontend themselves, and the company decided we should. That is the part that gets announced. What follows the announcement is the actual job.

The failure mode is well worn by now. The tools get bought, a session gets run, three people try it, two quietly go back to what they were doing, and six months later someone asks why adoption is flat. It is usually diagnosed as a skills problem and answered with more training, which is the wrong answer, because it was never a skills problem.

The blocker is risk, not capability

A designer opening a production branch is being asked to take on a category of consequence they have never carried. A bad Figma file wastes a review. A bad commit reaches customers. The asymmetry is obvious to the person being asked, and no amount of enthusiasm from me changes their side of it.

So the question I had to answer was not can they do this. It was whose problem is it when it goes wrong. Until that had a stated answer, the rational move for any designer on my team was to stay in Figma and let someone else find out.

Guardrails before access

So I did not start with the team. I started with the frontend team, who own the risk, and we wrote the rules together before a single designer had commit access. Two of them do most of the work.

The scope gate

Designers work in HTML and SCSS. Anything that needs a TypeScript change is not attempted and not worked around; it is flagged and escalated to engineering. A visual pass that edits application logic is how a polish sweep becomes a regression, and the gate hard-drops those rather than deferring them.

The global check

Anything touching a global stylesheet is surfaced as a written proposal (current rule, proposed change, expected ripple, risk level) and left unapplied. A change to a global rule is a change to every screen in the product, and that is not a decision to make inside one component’s review.

Underneath both sits Stylelint enforcement and the frontend team’s existing QA gates, which nothing skips.

Then I took the riskiest slice

With the rules agreed, the next question was who tests them on real work. Handing that to a designer would have meant asking someone else to be the first person whose name is on a bad commit, and that was the thing I had just spent weeks removing.

So I ran the deepest adoption in the company myself: the design-system consolidation and the mobile and tablet rebuild, 144 commits and roughly 1,200 files, delivered inside the guardrails while running the team. An independent regression audit across 370 changed files found zero critical and zero confirmed high-severity defects.

That number is the whole enablement argument. Not because it is impressive on its own, but because it converted the proposition from trust me into here is what happened when it was tried at the largest scale available, by the person who would have worn the failure. The second and third designer into the branch were not being asked to take a risk. They were following a documented path.

Then together, not in a workshop

What came next was deliberately unglamorous. No curriculum. Pairing sessions: my screen or theirs, on their own live task, with the agent in the loop. I have described my own version of this elsewhere as 1:1s with an agent, and the team’s version is the same thing with two people watching.

Two rules made it stick.

Automate your own tedium first, not a company priority. Everyone’s first agent skill was something that annoyed them: a naming pass, a resize batch, a first-draft layout. Payoff arrives inside a day, and the habit forms around it. A skill built to serve a quarterly goal usually gets abandoned before it works.

Commit the skill, don’t keep it. Everything lands in the department repo and is versioned like any other artifact, which is the subject of Episode 01. An hour someone spends automating their own tedium becomes an hour saved eleven more times, and it stops walking out of the building when they do.

Adoption is measured by refusals

The thing nobody warns you about is that an agent will happily produce a hundred changes to a component that was working fine. Volume is the easy part, and it is a liability.

So the ideation workflow I built scores every idea against one rubric and puts four gates in front of it: the two guardrails above, an ROI cut, and a stakeholder eyeball where surviving edits sit committed but unpushed until a human sees them running. On a single profile widget it produced 174 ideas, of which five shipped, two were raised as global proposals, and 167 were dropped with a written reason.

167 dropped is not a failed run. It stops a polish pass becoming 174 unreviewed changes, and the written reasons stop the same ideas being re-proposed in six months. The accessibility case study carries the full run.

One finding from it changed how I coach this. The first pass surfaced almost entirely accessibility fixes, which looked like a great result until I saw why: an invisible keyboard fix scores enormously well on impact-over-effort, while visual craft rarely clears the same bar. Rank purely on that and accessibility wins every run forever, and the visual work never happens. A scoring rubric does not remove judgement from design work. It relocates it into the choice of what you are scoring for, and that choice has to stay with a person.

What I would tell another manager

• Negotiate the guardrails with whoever owns the risk, before access. Not as governance theatre, but as the thing that makes trying it cheap.
• Go first, and pick the hardest slice. The manager should be the person whose branch gets audited, because the manager is the only one who can afford the answer.
• Publish the number, including the unflattering version. An audit nobody sees persuades nobody.
• Automate tedium, not priorities. Adoption is built on small selfish wins.
• Make the mandate about judgement, not speed. Ours is think more, do less. If the mandate is throughput, the first thing that gets automated is the thinking, because that is what takes longest.

The honest limit

Adoption is not uniform and I would rather say so than average it away. Four of us worked directly in the branch on the design-system project; the rest of the team uses agents further upstream, on drafting, naming and production work, and some are considerably further along than others. That spread is real.

What is uniform is the floor. Nobody on the team is now in a position where the tool is a mystery, nobody is guessing about what they are allowed to touch, and nobody has been handed a risk that was mine to take.