Algolia · 2026 · Pilot owner, design lead and author of the design rules

Design system AI readiness and the AI UX review agent.

Too long, didn’t read.

AI was letting engineers build screens faster than design could supply patterns. Poor AI output was a constant complaint in the design team's retros.

My goal was to raise the quality of what the design team puts out. I started with how ready our design system was for AI.

I ran a diagnostic rather than guessing. The gap was guidance on combining components and a bridge from Figma to code, not more documentation. That fix needed front end capacity nobody had, so I started with an automated UX review on every front end pull request.

Five design rules now run on every front end pull request inside the always on review bot another team owns. The rules are still mine to maintain.

Introduction.

AI coding tools changed the pace of front end work at Algolia. An engineer could go from an idea to a working screen far faster than before. Design could not always supply a reusable pattern that fast. When it could not, work shipped with little design input and the same thing got built a different way each time.


The design team felt it first. Screens built with AI came back inconsistent and off pattern. It was a constant complaint in our retros. Most people had already decided the design system itself was to blame.

My role.

Pilot owner
Design lead
Author and owner of the design rules

Scope.

Product audit
Design system diagnostic
AI comparison tests
Review rules and backtest
Merge into the always on bot

Influenced.

Where design quality is checked
Which reviewer the front end runs
What the design system invests in next

Outcome.

Five design rules on every front end pull request
A tested answer on AI readiness
A ranked set of next steps

Before and after.

Before, inconsistency was spreading as fast as AI could write code. After, there was a tested answer and a check on every change.

Before.

  • Engineers building screens with AI faster than design could supply patterns
  • An audit of seven AI search features logged 48 issues, more than half of them missing patterns or missing components
  • No link between Figma and code, with 11 corner radius values in Figma against 3 in code
  • Nobody checking front end pull requests against design rules

After.

  • A tested answer on what AI needs from the design system and what it does not
  • A ranked sequence of small next steps, starting with guidance on combining components
  • A radius scale proposed to the design system in two pull requests
  • Five design rules checked on every front end pull request, each finding tagged with its rule
The same kind of failure, before and after the reviewer Two pull request pages from the same product, drawn as abstracted GitHub conversations. Before, in April 2026, a setup wizard was reviewed by a person for layout, data and components and approved, while the code that swallows a failed create and shows the user nothing was never commented on, and it merged. After, in August 2026, in an illustrative example, the AI code review flags a missing error state on a search picker, suggests the design system EmptyState component with a retry button, links to its documentation and cites the error and recovery rule. The author adds the error state and it merges. BEFORE Error state missing, not caught Add a six step setup wizard Merged 23 files · +3,042 Conversation Commits Checks Files changed Files changed SetupWizardPage.tsx …/SetupWizardPage.tsx 100 + const agent = await client.createAgent(p); 106 + setShowCompletionModal(true); 107 + } catch (err) { 109 +   console.error('Failed to create', err); 110 + } finally { reviewer approved these changes author merged into main Reviewed, approved and merged. If creating fails, the user sees nothing. AFTER · ILLUSTRATIVE Missing error state caught, solution provided Add value search to the facet picker Merged 6 files · +412 Conversation Commits Checks Files changed Code review (AI) commented …/FacetValueSearch.tsx 42 + if (!options.length) return <NoMatches />; consider · An error state is missing. A failed fetch shows the same empty list as no matches, so the user cannot tell something went wrong or try again. Suggested change + if (isError) return ( +   <EmptyState usageContext="result" +     title={t('facetValues.error')} +     actions={<Button onClick={retry}>Retry</Button>} +   /> + ); Design system EmptyState, errors and retry Rule ux/error-and-recovery-states author replied “Added the error state with a retry.” Add an error state with a retry reviewer approved these changes author merged into main Caught on the diff, with the design system component that fixes it.
The same kind of failure, before and after the reviewer Two pull request pages from the same product, drawn as abstracted GitHub conversations. Before, in April 2026, a setup wizard was reviewed by a person for layout, data and components and approved, while the code that swallows a failed create and shows the user nothing was never commented on, and it merged. After, in August 2026, in an illustrative example, the AI code review flags a missing error state on a search picker, suggests the design system EmptyState component with a retry button, links to its documentation and cites the error and recovery rule. The author adds the error state and it merges. BEFORE Error state missing, not caught Add a six step setup wizard Merged 23 files · +3,042 Conversation Commits Checks Files changed Files changed SetupWizardPage.tsx …/SetupWizardPage.tsx 100 + const agent = await client.createAgent(p); 106 + setShowCompletionModal(true); 107 + } catch (err) { 109 +   console.error('Failed to create', err); 110 + } finally { reviewer approved these changes author merged into main Reviewed, approved and merged. If creating fails, the user sees nothing. AFTER · ILLUSTRATIVE Missing error state caught, solution provided Add value search to the facet picker Merged 6 files · +412 Conversation Commits Checks Files changed Code review (AI) commented …/FacetValueSearch.tsx 42 + if (!options.length) return <NoMatches />; consider · An error state is missing. A failed fetch shows the same empty list as no matches, so the user cannot tell something went wrong or try again. Suggested change + if (isError) return ( +   <EmptyState usageContext="result" +     title={t('facetValues.error')} +     actions={<Button onClick={retry}>Retry</Button>} +   /> + ); Design system EmptyState, errors and retry Rule ux/error-and-recovery-states author replied “Added the error state with a retry.” Add an error state with a retry reviewer approved these changes author merged into main Caught on the diff, with the design system component that fixes it.
Before, a real pull request where a missing error state got through review and merged. After, an illustrative example of the reviewer catching the same kind of gap and suggesting the design system component that fixes it. Redrawn with neutral names.

What the diagnostic found.

Most of the work was here, digging until I found what actually stopped AI building good interface. I did not want to fix the most visible problem. I wanted the one that was really holding everything back.

I started with the product. I audited seven AI search features and logged 48 issues, then scored each one on impact and effort and grouped them into themes. Five themes became the focus areas for everything that followed.

Then I audited the design system itself, layer by layer. Tokens, component interfaces, the link between Figma and code, usage guidance and the Figma library. I rated each layer against the five focus areas, so the weakest layer would show itself.

Then I tested it the way engineers actually use it. I had an AI model build five real screens with nothing but the installed design system package, then checked the code for anything it had invented.

Last, I rebuilt one real page from Figma five times, giving the model a different setup each time. The first had only the design system. The second could also see the Figma design. The third added a map linking Figma components to code components. The fourth added short written guidance to that map. The fifth was given the existing documentation to read. Every run used the same model and the same brief, judged against the design.

The roadblocks and how I got past them.

1. Everyone had already decided the design system was the problem

Most people had made up their minds that the design system needed fixing first. That would have taken a lot of design time and needed developers to implement it. We knew the design system had issues and could be better. The diagnostic showed it was not the best use of time right now. The foundation held up well. The obvious fix of writing more documentation for AI made the output worse. The setup given about 1,700 lines of the existing documentation scored lowest of all five, picking the wrong tokens and adding noise. I took those results to the team and changed the plan to short, curated guidance for the most common patterns.

Outcome.

Design time went to the gaps that mattered, not to a large rebuild of the design system.

2. The real fix needed engineers nobody could spare

A Figma to code link, composition guidance and the missing components all needed front end engineers. There were none to spare. Waiting meant the same mistakes would keep shipping. After discussing with a principal engineer how we could move forward, I looked at where mistakes actually reach customers. A prototype gets thrown away. A pull request ships. So I turned five design rules into an automated reviewer that comments on front end pull requests and never blocks a merge. I backtested it on merged work before asking anyone to trust it. It caught a real setup wizard that failed in silence, with no message and no way to recover.

The review is a safety net. It catches mistakes after they are written. Fixing the design system is what stops them being written. The review's findings show where to spend that engineering time first.

Outcome.

A check on design quality ran on real pull requests with no new headcount and no change to anyone's workflow.

3. A second review bot appeared on the same pull requests

Two bots commenting on the same change is noise. Noise gets muted. Worse, they could contradict each other. If one says a change is fine and the other says it is not, which one does the engineer believe? Running both added complexity for the very people the review was meant to help. So I merged mine into the other team's bot. Theirs already ran on every push, while mine ran only when someone added a label. I gave up the tool, its name and its trigger. Every rule survived the merge. We agreed that they own the bot and I own the design rules inside it.

Outcome.

One clear voice on every front end pull request instead of two competing ones on some.

Where it landed.

Over ten days on the merged bot it raised 14 findings against my rules and none was argued down as inaccurate. Engineers fixed findings before merge and replied naming the commit, one of them 22 minutes after the comment.

Design rules now reach every front end pull request without a designer in the room. Every finding carries the rule that produced it, so design's effect on code quality can be counted rule by rule.

→ Full story and decisions in an interview