Industry
Fintech
Employer
Conta Simples
Time Invested
1 week
Reverse-Engineering a Design System: From Storybook to Figma
AI Coding (Claude Code)
How I directed an AI coding agent to rebuild a fintech's Design System (Web and App) by reverse-engineering it straight from Storybook, with triple validation on every wave and a human gate before every publish.
Outcome
5x
faster design-to-dev prototyping and build cycle
+80
component sets migrated and republished across Web and App
+1,5K
component variants rebuilt across Web and App, triple-validated
Context / Problem
The Design System's Figma file was a disorganized stack of old libraries, with no Code Connect. The reference file carried variants that had never actually been componentized: anyone designing from it produced something the code couldn't deliver. The effect cascaded: designers without a reliable library, developers receiving prototypes that didn't match the real component, and squads without a dedicated designer had nothing to consume at all. Rebuilding every component by hand, with every state and variant axis, wouldn't fit in the quarter. The fix: make Figma derive directly from Storybook (the code) and stay resynced with it through Code Connect.
My Role
I owned the rebuild end to end: set the standard, decided the structural rules (what becomes a token, when a value is "bound" to code, which variant axes exist on each component), directed an AI coding agent (Claude Code) operating the Figma Plugin API, and validated the work component by component before releasing each page. I used the same agent to turn the migration into a backlog, then handed engineering the items that were actually code or infrastructure work (Code Connect, access tokens, where the mapping files live).
Discovery
I started with the token foundation, then a pilot component (the button), which surfaced the rules that held for every component after it: only bind a token when the code actually consumes it, measure real geometry from Storybook running live instead of eyeballing it, and treat any drift between documentation and code as a bug to log, never a pattern to copy into Figma. I ran the process in waves: foundation, pilot, critical review, replication, with every decision logged with its rationale and a reversibility flag (what could still be adjusted later via script, and what became a one-way door, like publishing the library). On the App side, which has its own file, tokens and pipeline, I applied the same method, with the agent feeding its own learning notes back into a local ledger and handoff prompts to keep inconsistencies and hallucinations to a minimum.
Solution
The rebuild produced two new Figma libraries, Web and App, each with code as the single source of truth. On Web: 30+ component sets and 1,000+ variants covering the system's base components. On App: 100% coverage of `src/components` (27 of 27) and `src/shared` compositions (23 of 23). Combined: 1,500 variants, every one triple-validated through a scripted binding scan, a visual node check, and a test across the Light and Dark themes. I published the library, and designers started using it day to day, swapping components in seconds through component swap. That cut the time lost in the back-and-forth between design and development: less prototype rework that didn't match the real component, less time re-explaining a pattern that should already have been documented. A side effect that wasn't part of the plan: because the rebuild mirrors the code component by component, it turned into an audit of the product itself. I surfaced 18+ production issues along the way, for example a required field with no visual asterisk, or a mismatch between documented and actual component types.
