Writing code is cheaper than ever. AI-assisted pull requests mean frontend engineers, backend engineers, PMs, designers, and bots can all ship UI. This outpaced the capacity for our design team to review everything that was shipped. We faced a risk of drifting from the design system. I set out to make the system govern itself.

I created a bot that automatically reviewed each pull request against the design system and left a comment noting areas of improvement. I coupled that with a weekly analysis to systematically improve our guidelines based on what surfaced. I laid a foundation to create design leverage while meeting engineers where they are. This empowered the design team to focus on defining the judgement instead of enforcing the system.

The team

Our design team was a small team of five designers. Meanwhile our UI repository saw hundreds of pull requests each week, increasingly from people outside frontend engineering. I pitched the goal that design quality should be called out in a pull request the same way test coverage is. The long-term vision included moving upstream to leverage design-based skills earlier in a project’s process. The first step was to insert design checks into an existing engineering workflow. Through engineering enablement, we could raise the floor of design across the product.

Expanding the design guidelines

A bot can only enforce its reference material. We were working with a contract UX writer who was quickly expanding our component-level design guidelines. I led the efforts to define foundational content like design principles, content guidelines, and UX patterns.

I ran a workshop with the team to identify design principles that were core to Customer.io, opinionated, and would help us make decisions. I drafted, collected feedback, and proposed the three initial principles: one paved road, many dirt roads; do the least surprising thing; and every action builds confidence. These principles would be the foundation for design-based skills engineers (and others) could leverage in their AI tooling.

The content guidelines had the largest impact on the review bot. Words are critical in a user interface. Without a systematic check, usage can easily drift. In the first few weeks since launching the bot, small improvements to the content guidelines were the primary source of feedback. We immediately saw an impact on small details such as sentence casing and notification copy.

The next step was to add patterns to the design system to document guidance for repeated decisions. I drafted a setup wizard recipe to document how a multi-step creation flow should be treated. The recipe documented when to use, when not to use, and all of the various states so we could clean up the existing inconsistency and provide a more familiar experience for customers.

Putting design in the CI flow

The bot looks at a pull request, reads the relevant portions of the diff, fetches design system documentation, and posts a single comment with a summary of its findings. The first iteration served the guidelines through an MCP server. We soon made the design system documentation public and could simply reference the llms.txt files directly. Showing up in the existing engineering workflow was critical to adoption.

Trust with engineers is important; the bot would be ignored the moment it wasted their time. I included only items that required a change. Surfacing findings that already followed conventions would add noise. I built it to auto-minimize past comments so there was only one visible comment at a time. It intentionally does not have the power to approve or block PRs. To keep up with evolving processes, it also checked bot-authored pull requests.

Closing the loop

I built a weekly automated analysis with Claude to review the week’s pull requests to spot common themes, which pull requests were acted on, and where the guidelines themselves needed to be improved. In the first week alone, another designer and I updated punctuation rules, button copy guidance, and more specific tooltip and modal patterns. This was something we could own as a design team to continuously improve the system itself.

Going forward

Over the first four weeks, the rate at which the bot’s comments were acted on steadily climbed: 17% → 25% → 30% → 44%. In the most recent week, roughly two-thirds of pull requests cleanly merged against the guidelines. There is still room to grow, as guidelines can be improved and AI hallucinations persist. It was a step in the right direction and gave a small design team real leverage. The next step is to expand this further upstream in the workflow. The same guidelines can be used to inform spec-writing and prototyping. The future of design systems is less a library to reference and more an active participant in the workflow.