Our design system as a skill made an AI agent at least 2× faster

The site you're reading was built twice from the same design handoff, one day apart. Both times the work was done by an AI coding agent, with me steering. Both builds used the same design system architecture.

The first build took 31.7 hours to a commit and never matched the design. The second took 2.5 hours and matched it on the first pass.

I didn't plan this as an experiment, so it isn't a clean one. The agent sessions leave full transcripts, though, and they made it possible to measure both runs. The results seemed worth writing down, together with what they can't show.

In run one, the existing site already used our cross-platform design system as a library, pulled in as a git submodule. The agent got the new design export and was asked to migrate the site to it. It knew the design system only from the code it could read.

Run two used a fresh repository and the same design export. This time the agent started from a skill: the design system's architecture packaged as instructions plus a working scaffold. That meant a token layer, theme binding for web and native, one fully worked primitive, the verification scripts and the lint rules, each with the reasoning behind it.

The architecture was the same in both runs. What changed was whether the agent had to rediscover it from code or was handed it as a set of decisions already made.

The figure the table under-sells is the last row. After run one's commit, I spent another 12 hours on the home page alone, telling the agent "it still doesn't look like the design" in several different ways. Run two went from design export to "great, commit it" with no correction in between. The +23.9k lines include the design system itself, which run two built from scratch instead of importing it.

In run two, most of the 80 components were written in about an hour and 45 minutes. Six sub-agents built pages in parallel, all against the same token and primitive contract.

It would be easy to headline "7× faster" and stop. Here is what that would hide.

The model changed. Run one was done mostly by a smaller, faster model, with the larger one for some turns: about 5,300 of 7,600 responses came from the smaller one. Run two used a newer, larger model throughout. That alone is a real factor, and with this data I can't separate it from the skill.

Run two was also a second pass. The design had already been read closely once, and my brief for run two was far more detailed because of what run one taught me. Some of the speed is hindsight.

Run one was a migration. It had to remove or rewrite 6.8k lines of the old site, while run two started from an empty repository, and greenfield work is easier.

And it is one comparison, with no repeats and no control.

The claim these numbers support is narrower than the table. They carry "at least twice as fast" easily, even after a generous discount for the model and the second pass, and 7× is only an upper bound.

One difference the model clearly doesn't explain is the shape of the work.

In run one, architecture decisions came up page by page. The agent decided how to name a spacing value, how to express a breakpoint and which layer a new piece belonged in. Then a later page made a slightly different decision, and something had to be reconciled. That's why run one needed me to say "continue" and "fix it" seven times before the commit. The questions it kept reopening were easy ones.

In run two, those questions were closed before the first page. The skill said where a component lives, how tokens are named, what a primitive's props look like and which scripts fail the build when any of that is violated. The agent spent its first 25 minutes turning the design into tokens and primitives. After that, building a page was mostly assembly, and assembly parallelizes. Six sub-agents can build six pages at once only when none of them is inventing conventions the others don't know about.

Beyond our own project, what I take from this is that a design system saves an agent time the same way it saves a team time, by removing decisions rather than keystrokes. A library gives you the components but not the reasons behind them, and without the reasons every new screen reopens the same questions. Packaged as instructions with enforcement, the same architecture settles those questions before work starts.

Every figure above comes from saved artifacts:

• Time comes from agent session transcripts, including sub-agent transcripts. "Active time" counts the time between consecutive events and drops any gap over 15 minutes, so an overnight pause doesn't count as work.
• Components are .tsx files under components and the design system packages in each commit, from git show. Run two's timeline comes from file creation times on disk, because most files were written through shell commands rather than a file-writing tool.
• Corrections are my own messages in the transcript that redirect or push the agent ("continue", "why did you skip that", "it still isn't the same"). Questions and approvals aren't counted.

I would measure on purpose. This comparison exists only because the transcripts were still on disk. The next one should be designed: the same three or four components, the same model, once with the skill and once without. That would isolate the part of the result I can't separate today.

I would also package the reasons earlier. The design system existed for weeks as a library before it became a skill, and every project that used it in that time paid the same rediscovery cost as run one. Writing down why each rule exists turned out to be the step that made the rest reusable.

And I would count corrections alongside hours. Time depends on the model, the machine and the day. The number of times I had to step in shows how well the agent understood the system, and I would track it from the first session.