Rex Tseng

Works

Building an AI Design Pipeline at Bitget

From a design system agents can read, to a router that decides who works next

Landing pages for the Growth team need to move fast and still stay on the design system. I wanted to know whether AI agents could carry a page from raw requirements to a reviewed build. When I started, few people around me had worked with agents, and the models were still unreliable at following a design system.

There was no playbook, so I built the method by trial and error: turning the design system into skills an agent can read, deciding how to classify and split the work, and tightening the pipeline each time it failed. It now runs as a router and eight agents. The demo below runs the routing rules on whatever you type.

Role
ResearchAgent architectureWorkflow design
Platform
Claude Code

The system at a glance

Specialist agents behind one routerFive in the main chain, three in the direction loop
8
Platform skillsWeb and app, plus guides for choosing components and exploring directions
2
Review dimensionsDistilled from real design-review comments
9 + 1
AI-slop tellsThe builder checks its own page against them
12
Pass mark per dimensionThe auditor scores five dimensions; all five must reach it
8 / 10

Figures are taken from the current version of the system.

One router, and boundaries that make routing possible

The entry agent never produces a page itself. It checks that a project folder and a request exist, looks at which files are already there, and hands the work to the first step still missing. If a brief already exists, the brief step is skipped; if only a check is requested, the work goes straight to the checker.

That only works because every agent states when it must not run. The brief parser handles messy notes and never runs when a brief exists. The token enforcer changes values but never the layout. The audit diagnoses and never edits. A request can only go where a rule says it belongs.

Try the router

Type a request or pick an example. The router applies its rules and shows which agents run, which are skipped, and why. The agents themselves run in Claude Code.

Waiting for a request.

Router

page-pipeline

Checks that a project folder and a request exist, looks at which files are already there, and hands the work to the first step still missing. It never builds anything itself.

In request + project folderOut a decision: who works next

Main chain

  1. Brief parser
    brief-parser

    Turns messy notes, chat logs and meeting summaries into one structured brief. Anything unclear goes into an open-questions list instead of being guessed.

    In raw requirementsOut brief.json

    Human checkpointYou confirm the brief before anything is built.

  2. Page builder
    page-builder-pro

    Goes from the brief straight to a working page: structure, layout and code in one step. Talks through a direction first, then checks its own work against twelve AI-slop tells.

    In brief.jsonOut index.html

    Human checkpointYou pick the direction, then accept it, ask for another, or adjust one section.

  3. AI-slop audit
    ui-system-audit

    A quality gate. Diagnoses hierarchy, structure and responsive behaviour, and flags template-default patterns. Diagnosis only: it changes nothing.

    In index.htmlOut a list of problems

  4. Token enforcer
    design-system-enforcer

    Replaces raw values with the design system’s tokens and keeps to its rules. Never touches the layout.

    In index.htmlOut index-refined.html

  5. Review standard
    ds-review-standard

    Reviews the page the way a human design-system reviewer would: nine dimensions plus one, each finding marked must fix, suggest or to confirm, then a top three to fix first.

    In the refined pageOut graded review notes

Direction loop

  1. Direction explorer
    direction-explorer

    Reads the brief and the log of directions already tried, then proposes one new direction. It must differ on at least two of six axes: density, hierarchy, tone, colour strategy, shape language and boldness.

    In brief + direction logOut one new direction

  2. Auditor
    auditor

    The factual layer. Scores the new version from 1 to 10 on five dimensions and lists concrete, fixable problems. All five must reach 8 to pass. It does not argue about strategy.

    In page + screenshot + briefOut scores and fixes

  3. Strategy challenger

    The strategic layer, playing a senior UED director. Asks whether the direction is right, bold enough and convincing for the business, and wants a reason behind every decision.

    In the scored versionOut challenges to answer

↺ Repeats until a direction passes both checks.

Making a design system readable to agents

A design system written for people is hard for a model to follow. Rules are scattered across documents, many values are implied, and “looks right” has no definition. My first attempts kept drifting off the system. When I traced why, it was usually how the knowledge was organised, and no amount of prompt tuning fixed that.

I extracted the system from Figma myself and reorganised it around the questions an agent asks while it works: what is the value, which component fits, is this allowed, how should it be generated. Foundations became structured data, components became specifications of structure and states, and the generation rules became a guide of their own. Web and app each got a separate skill, with a short guide for choosing components and another for exploring directions, so an agent loads only the slice it needs each time.

An index maps each rule to where it lives, and a log of corrections outranks the base specification, so a lesson learned on one page is applied to the next.

Trial and error, kept on the record

One QA run failed. I traced it to a missing reference sample, added the sample, and left the prompt alone. The structure also changed in a few places:

  1. Planning the page structure, wireframing and building began as three agents passing files along. I merged them into one builder that reads the brief directly, and dropped the intermediate files.
  2. Diagnosing a page, aligning its values to tokens and judging it against a review standard are three separate agents. Each states when it must stay out, so they do not overlap.
  3. I distilled real reviewer comments into nine dimensions plus a tenth for aesthetic judgement. Every finding is graded must fix, suggest or to confirm.
  4. Directions kept ending up looking alike, so the direction explorer now reads a log of what has been tried and must differ from it on at least two axes.
  5. What I learned in one conversation was gone by the next. After each project a retrospect agent reads the project folder and conversation history and files what was learned, and corrections made on a page are merged back into the skills.

Where a person decides

The pipeline does not run unattended from start to finish. It stops at three points: after the brief, so a misreading of the requirements is caught before anything is built; before the build, where directions are discussed; and after the first build, where the designer accepts it, asks for another direction, adjusts one section, or changes the design philosophy. Only then does the token and review stage begin.

The agents propose, build and check. Direction and taste stay with the designer.

A loop for when the direction is wrong

Sometimes the whole direction is wrong, and fixing details does not help. A direction explorer reads the brief and the log of directions already tried, and must propose one that differs on at least two of six axes: density, hierarchy, tone, colour strategy, shape language and how bold it dares to be.

An auditor then scores the result from 1 to 10 on five factual dimensions, and a strategy challenger, playing a senior UED director, asks whether the direction is right, bold enough and convincing for the business. One points out what is objectively wrong; the other asks whether this is worth doing. A page does not pass just by following the rules.