Building a design system machines can read

Wallarm's platform had no shared design system. Every new screen started with days of archaeology before any design: going through the console screen by screen, looking for something consistent to stand on, and finding none.

• —No shared design system. Every page ran on its own rules.
• —New screens started with days of archaeology, not design.
• —Fast concepts came out inconsistent and low quality.
• —An AI-first company could not move AI-first. There were no consistent parts to build from.

What finally made the design system urgent was vibe-coding. Once PMs and engineers started shipping rough prototypes to explain ideas, the missing design system became the bottleneck. Everyone could suddenly prototype, but without shared, consistent parts the results came out rough and inconsistent.

• —Co-designed a new design system with our design lead: tokens, rules, and components tuned to Wallarm.
• —Wrote UI in React and Tailwind inside the engineering codebase and merged my own work, type fixes included.
• —Wrote the design-system documentation: a spec per component, how they combine, and the do's and don'ts.
• —That documentation, living in the codebase next to the components, is what lets people and AI agents use the design system correctly.

The design system starts with tokens: color, type, spacing, and elevation, tuned to a dense cybersecurity product where status and severity have to read at a glance.

Good components were the ordinary part, and the two of us did that together. The part that made the design system AI-first was the documentation: a spec for every component, how components combine, the do's and don'ts.

The design system changed how the work happens. A feature used to move in a long line: research, weeks of mockups, a handoff to engineering, then a build. Now product often starts the concept, a PM brings a vibe-coded draft, and the same feature goes from idea to shipped noticeably faster than before. Here is the loop it runs through:

1. 01

   New feature, own sandbox

   A fresh micro-frontend with the design system already inside.

2. 02

   Build it, often with AI

   A PM or engineer vibe-codes a first version from the components on hand.

3. 03

   Docs keep it on the design system

   The specs, combinations, and do's and don'ts let the agent build the real thing instead of guessing.

4. 04

   Ships on the design system

   The same parts and rules every time, whoever or whatever built it.

This works because the design system is documented precisely enough for a machine to follow it: a spec per component, how they combine, the do's and don'ts. Whoever fits ships it: the designer, the PM, or the engineering team, depending on how complex the feature is.

What a designer does now depends on the work:

• —Settings and service pages: fast, often no designer needed. We approve at the end and fix the code when it is not clean.
• —Features from product: the PM's draft gets us most of the way. We turn it into a real concept and do the research around it.
• —Net-new features: iterate straight into the design system, test with users fast, ship without the old friction.

The designer who hands off pretty pictures is gone. I work on product's ground and engineering's now. Engineers still ship the code. Everyone speaks one language, and the friction drops. A design system used to be a library you referred to. Here it became part of the codebase every new feature starts from, something an agent builds with directly.

This is the design system the infrastructure-discovery work was built on, a parallel track with its own case study →