Product & Design
Catch design-system drift before inconsistencies become the interface.
ZeroTwo checks approved Figma components and variables against the code in GitHub. It groups the differences and sends proposed fixes to design and engineering for review.
An AI design system drift agent helps design-system and frontend teams detect meaningful differences between approved Figma assets and production code. In ZeroTwo, the agent compares component anatomy, variants, states, tokens, content rules, responsive behavior, and accessibility evidence, then produces a source-linked drift report in Slack. It identifies review work; it does not overwrite Figma libraries, merge code, or decide which surface is canonical.
What changes
Evidence
Reviewers compare screenshots and memory
The report links each difference to Figma evidence, code location, token, state, and owner
Classification
Every visual difference is treated as a defect
ZeroTwo separates intentional divergence, stale design, stale code, missing state, and unverified difference
Accessibility
Focus, error, disabled, and reduced-motion states are checked late
The audit includes interactive and accessibility states as first-class parity evidence
Remediation
A generated patch can overwrite the wrong source of truth
Design and engineering owners approve whether Figma, code, documentation, or all three should change
Why use an agent for design-system drift
Audit more than pixels
The workflow covers tokens, anatomy, variants, states, content rules, responsiveness, motion, and accessibility.
Preserve source evidence
Each finding links to the Figma component or variable and the relevant code, story, test, or token.
Reduce false positives
Intentional divergence and stale source material are classified instead of automatically labeled defects.
Route fixes to the right owner
The report distinguishes design, code, documentation, and shared governance actions before anyone edits.
Agree on the design rules before fixing visual drift.
Figma and code can differ in colors, layout, names, states, and screen-size rules. Also check copy, icons, keyboard focus, and motion. Screenshots catch only some of these gaps. A planned platform difference is not a bug.
A useful agent should preserve both sources, classify why they differ, and route a decision. It should not assume Figma or code is always correct or generate a broad rewrite that hides the underlying governance gap.
How ZeroTwo prepares a design-system drift report
Collects approved design-system evidence
FigmaZeroTwo reads the selected Figma library context, components, variants, variables, styles, state definitions, and review status within the approved scope.
Collects implementation evidence
GitHubThe audit gathers component code, token definitions, stories, tests, accessibility states, responsive rules, and recent pull-request context from GitHub.
Classifies meaningful drift
GPT-5The agent compares anatomy, tokens, variants, content, responsiveness, motion, and accessibility, then labels each finding with evidence, severity, confidence, and likely owner.
Routes disputed or severe findings
SlackA Slack review card lets design and engineering owners confirm intentional divergence, mark stale evidence, assign a fix, or reject a false positive.
Verifies reviewed remediation
GitHubThe next audit checks the approved change and records whether Figma, code, documentation, or tests were updated without merging anything automatically.
Define parity before asking AI to find drift
Decide which source owns each rule. Cover tokens, layout, copy, accessibility, motion, and platform behavior. Without that agreement, the agent can find a difference but cannot know which side to fix.
Severity should reflect user and maintenance impact. A small color delta may be serious when it breaks contrast; a larger layout difference may be intentional on mobile. Keep the rule, evidence, affected surfaces, and confidence visible.
Use the agent to prepare review work, not bypass it. Updating a shared token or component can affect many products, so design and engineering owners should approve scope, migration plan, tests, and release timing.
Get started in under 10 minutes
Connect your tools
One-click OAuth for each integration. No API keys, no engineering.
Describe what you need
“Each week, compare the approved Figma design-system library with the selected GitHub component and token paths. Check component anatomy, variants, token values, content constraints, responsive behavior, hover, focus, disabled, loading, error, reduced-motion, and accessibility states. For each difference, link both sources, classify intentional divergence, stale design, stale code, missing state, or unknown, and route severe or disputed findings to #design-system. Do not edit Figma, open a pull request, or merge code.”
It runs on schedule
Runs weekly and before shared design-system releases; all remediation remains owner-reviewed.
Frequently asked questions
It is an agent that compares approved design-system evidence with implementation evidence and produces a reviewable difference report. In ZeroTwo, it can organize Figma components and variables alongside GitHub tokens, code, states, stories, and tests. It classifies drift but does not assume which source is correct or make changes automatically.
Check component anatomy, variants, design tokens, typography, color, spacing, icons, content rules, responsive behavior, motion, and interactive states such as hover, focus, disabled, loading, and error. Include accessibility evidence and platform-specific exceptions. A screenshot-only comparison is not enough to audit the behavioral contract.
The agent can suggest the likely owner and remediation path, but automatic broad fixes are risky. Figma may be stale, code may be stale, the difference may be intentional, or the change may affect many products. Design and engineering owners should decide the source of truth, migration scope, tests, and release plan.
It uses an explicit parity contract and classifies findings as intentional divergence, stale design, stale code, missing state, or unknown. Each finding includes both sources, affected surface, rule, severity, confidence, and owner. Reviewers can reject or reclassify results, and the next run uses the approved decision as evidence.
Track confirmed findings, false-positive rate, time to owner decision, recurring drift categories, severe accessibility issues found, reviewer corrections, remediation completion, and regressions after fixes. The goal is not to maximize findings; it is to keep the design-system contract inspectable and reduce user-visible inconsistency without creating unnecessary churn.
Related workflows
- Product & DesignDesign Accessibility Audit
- Product & DesignRelease Notes Draft Agent
- Engineering & DevOpsSprint Retrospective
Turn design-system drift into a reviewed parity decision.
Compare the full component contract, preserve evidence, and route the right fix to design and engineering owners.