I didn't have access to the code.
There was a project where the repo existed, but I had no access to it. No Figma file either, just a live app and a browser inspector. I had to dig the tokens, the predefined values, out of that, before I could start building anything on top of it with AI.
Since then I map an existing system in three very different situations, before I build a single pixel. The level of access forces a different method every time, and each one has its own logic.
The three scenarios
1. I have repo access
This is the best case, especially when the tech stack is ideal too, Next.js plus Tailwind. I read the tokens and the components straight from the code. This is usually where the system's own mistakes surface too: a missing token, a hardcoded value where a color or a spacing should sit, a component someone rebuilt from scratch instead of using the one that already existed. I don't fix these quietly. I ask about them. Sometimes it turns out it was an intentional exception, for a reason I couldn't see.
2. Only Figma, no access to the code
Here I use Figma CLI (opens in a new tab) to read the tokens and components straight from the Figma file. Sil Bormüller (opens in a new tab) built it, and there's one basic difference from the official Figma MCP, and that's why I pick it instead.
| Figma CLI | Figma MCP (official) | |
|---|---|---|
| Connection | directly to local Figma Desktop, over CDP | Figma REST API, through the cloud |
| Figma token | not needed | needed (figd_…) |
| Rate limit | none | as low as 6 reads / month per seat |
| Offline | yes | no |
In practice this means that when I'm mapping a bigger system, I don't hit the limit within minutes, and I don't have to manage a Figma token either.
3. Repo exists, but I can't access it. Just the live app.
The hardest case, and it's the one that opened this post. I map it with a browser inspector: what's built from what, computed styles, states, everything I need to build the foundation of the system from underneath it. I have the AI write small scripts that read out this data. It takes time, but it has always paid off so far.
Fast, imperfect first version
Once I have the foundation, I first think it through in plan mode, and only then start on the layout, unless the project is extra urgent. When I actually build, I don't aim for pixel perfect right away. The point of the first version is to show the direction, not to be perfect. A live prototype put together fast with AI helps the most here: within a day there's something real, something you can react to, not within weeks.
Then comes the check. When the AI hallucinates, or makes something up, that's not its fault. Its job is to answer, to keep things moving. In that case, my rule system was weak, because it didn't say in advance what it can and can't do. That becomes the new rule, and the system keeps growing along the way.
When I actually have to build something new
Sometimes there's nothing to map, because that element, that component, doesn't exist yet. Here I try out several variations at once. Plan mode again, sometimes ASCII sketches right in the terminal session, and a research agent I send out to find patterns, precedents.
On one project, the brief itself named which guidelines, which design systems were recommended to borrow from, because those are well tested. I write that into the project, so the research agent knows where to look first. That doesn't mean there's no decision of my own in it, just that I don't reinvent what someone else already solved.