Building a design system with AI agents

I recently built a React form library, Console Forms, as a portfolio project: eleven components, a Storybook, design tokens and a CI pipeline. It took me about eight to ten sessions, all evenings and some nights after work. I used coding agents in VS Code to write the code, and a chat assistant to plan the work and go through each agent’s report with me.

By hand it would have taken me roughly twice as long, I’d guess. That’s a feeling, not a measurement.

But the speed isn’t what stuck with me. What stuck with me is what happened to the work itself.

Faster, but not simpler

The project didn’t get any less complicated. A date picker is still a date picker, with partial input, locales, keyboard behavior, screen reader semantics and forced colors to worry about. What changed was where my time went. I wrote far less code, and I spent a lot more time deciding, reading and checking.

It changes how I think about estimates too. The typing shrinks. The verifying doesn’t. If your estimate only counts the typing, it’s wrong.

Working in parallel

The best part of the setup is that things happen at the same time. While one agent was fixing a theme flicker on its own branch, I was reading the report from another. Writing speed stops being the bottleneck, and making good decisions quickly takes its place.

That suited me, because I only ever had a few hours at a time. I could leave an agent working, come back and review what it had done. But it also means you never really wait. You’re always supervising something.

Writing the rules down wasn’t enough

I put the rules in writing: an AGENTS.md at the root, a CLAUDE.md, instructions for GitHub Copilot. The agents read them. Things went wrong anyway.

One of my tests stayed green because it was replaying a cached result. It was passing, and it hadn’t run anything. Another one read each Storybook story’s status before the story had finished, so five broken stories got through until a browser-based accessibility job caught them. And some states were invisible in forced-colors mode, while a focused empty date field had a contrast ratio of 1.65. Both made it through until someone looked closely.

None of this is exotic. A tired human makes the same mistakes. The difference is speed: an agent can produce a lot of work in an hour that looks right, passes, and is subtly wrong.

Each of those ended up as a written rule for the next agent. Things like “a green job isn’t evidence unless you know it did the work”, and “never re-run a failed job just to make it green.”

What I read, and what I trusted

I read every pull request and merged it myself. There are more than fifty, and no second reviewer, so GitHub shows zero formal reviews. I’d rather say that than suggest a process I don’t have.

I trusted the gates for what they can prove: lint, types, tests, axe in a real browser in both themes, a size budget per component, Lighthouse. I didn’t trust them for what they can’t. I haven’t done a screen reader pass yet, so I wouldn’t call the library accessible beyond what’s actually verified.

Where this leaves me

I’ve worked on design systems before, in a larger setting, and I know how rarely they get finished. What made this one finishable wasn’t only the AI. It was a small, fixed scope (eleven form controls and nothing else) and gates that grew along with the code.

If anything, I’m more convinced that the senior part of the job is judgment: deciding what to build, setting the constraints, and noticing when something green isn’t proving anything. The agents made me faster, but I was still the one responsible for what shipped.

The Storybook is live at design.aleixvidal.dev and the code is open source on GitHub. The package isn’t on npm yet.