# From Jira to PR: How we built agent-driven pipelines for design system changes

DevFeed: [From Jira to PR: How we built agent-driven pipelines for design system changes](<https://devfeed.tech/articles/from-jira-to-pr-how-we-built-agent-driven-pipelines-for-design-system-changes-1891.md>)

Original publisher: [Read original article](<https://1password.com/blog/agent-driven-design-system>)

Author: info@1password.com (Nancy Wang; Wayne Duso; Katie Davis; Matt Davey)

Published: 2026-05-19T00:00:00Z

Content type: article

Language: en

Sources: [Blog on 1Password Blog](<https://devfeed.tech/sources/blog-on-1password-blog.md>)

Topics: [agentic-coding](<https://devfeed.tech/topics/agentic-coding.md>), [React](<https://devfeed.tech/topics/react.md>), [Figma](<https://devfeed.tech/topics/figma.md>), [Storybook](<https://devfeed.tech/topics/storybook.md>), [coding](<https://devfeed.tech/topics/coding.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [agentic](<https://devfeed.tech/tags/agentic.md>), [agentic-coding](<https://devfeed.tech/tags/agentic-coding.md>), [ai](<https://devfeed.tech/tags/ai.md>), [coding](<https://devfeed.tech/tags/coding.md>), [design](<https://devfeed.tech/tags/design.md>), [developers](<https://devfeed.tech/tags/developers.md>), [figma](<https://devfeed.tech/tags/figma.md>), [react](<https://devfeed.tech/tags/react.md>), [tokens](<https://devfeed.tech/tags/tokens.md>), [validation](<https://devfeed.tech/tags/validation.md>), [web](<https://devfeed.tech/tags/web.md>)

## AI overview

The article describes using a coding agent to automate a well-defined design-system workflow from ticket and Figma review through component implementation, Storybook stories, testing, and pull requests. It emphasizes that strict conventions, predictable outputs, design-system context, and automated validation help agents work effectively, while insufficient context leads to incorrect tokens and component choices.

## Source excerpt

Design system work follows a well-defined loop: read the ticket, check the Figma spec, find the right component primitives, apply the right tokens, write the Storybook stories, run the tests, open the PR. The steps are consistent enough that when we looked at our design system backlog, we didn't just see a list of tasks; we saw a set of instructions waiting to be executed. So we set an agent loose on the loop. At first, it was a semi-hot mess. But then we gave it the right context, and boom, it has completely changed how we improve our Design System. Here's our approach on what we did and what we learned. Why we started with our design system Every team considering agentic coding faces the same question of where to begin. The tempting answer is your largest codebase or your most complex feature. The right answer is wherever the work is most well-specified, and the feedback loop is fastest. Our React component library, the web layer of our design system, happened to be both. Conventions are strict by design: that's the whole point of having a design system. The output shape is predictable and well-documented: a component, some design tokens, a story, and a test. The blast radius of any change is traceable. And if a token is wrong, the tests catch it automatically, without a human having to notice. That combination of explicit conventions, predictable outputs, and automatic validation describes exactly the kind of bounded context where agents do well. When we looked at where to prove the pattern before adapting it to larger, messier codebases, the design system was an obvious answer. What happened when we pointed a general-purpose agent at our design system The first attempt was to take a well-scoped ticket, hand it to a capable coding agent, and see what comes out. The results were instructive, and not in the way we hoped. The agent could read the ticket and navigate the codebase. But without design system-specific context, it filled knowledge gaps with confident-sou