Agentic DesignOps

Context

AgentOps was a completely new product initiative at Komodor. The initial "design" work happened directly against a live codebase — not a Figma file handed to engineering to build. The product was being built by developers in a very agile, agentic way, using Shadcn and Tailwind as the base front-end libraries.

Before any real design decisions could govern how the product looked, the system meant to govern it had to be defined and established first.

Rather than redesign the system in Figma and align it with engineering afterward, I flipped the order: read the repository first, and let what was actually shipped define the design system — not the other way around. The product wasn't client-facing yet, so the guiding thought was simple — I could always change the primary button color later, but first I needed a primary button color definition, consistent across the product.

Outcome

• Figma and the codebase now define the identical token set, checkable by name instead of memory.
• The resulting foundation was solid enough to hand real authoring work to an AI coding agent working directly inside the repo.

Key stages

Reading the repo first

Every design system wants to believe it's the source of truth. On a product that's already live, that's rarely true on day one — design files were non-existent, and the docs and the code each described a slightly different version of the product, with the gap growing the longer nobody checked.

AgentOps had colors before it had a color system: a background picked here, a border there, an accent color chosen once and reused from memory — all correct on screen, none of it traceable to one source.

Defining the color palette

I used Claude Code to work directly against the project's repo in GitHub. The LLM scanned for every color in use and documented them as an audit in Figma — turning the color that had been used as the "accent" into a proper token, and defining a limited palette in the process.

The next step was expanding the existing colors into a full 50–950 scale: a limited, formalized set of options for visual design. From there came the token layers — primitives and semantics — enough to properly support the light and dark themes already in use.

Testing the new color system

Once I was happy with the shape of the palette and the basic tokens, I tested it by defining the basic button component. The existing button had a representation in an internal, storybook-like library, and examining it closely surfaced a gap: hover states were opacity-based — fine for rapid prototyping, but not for a long-term consistent system, since you can't have the hover color shift on every surface.

The color palette proved sufficient to define every state the basic button needed.

From reference to enforcement

Once the token layer could be trusted against the repo, the harder problem was keeping new design work grounded in that reality as the product kept shipping — especially once an AI coding agent started working directly inside the codebase, with full visibility into everything living there.

I wrote specific skills to tell the AI agents (the developers) what they were and weren't allowed to do — an ongoing, evolving effort, but one where clearly documenting each decision matters. What designers usually take for granted has to be made explicit in the age of AI — it keeps the LLM from making assumptions, and helps keep the product unified.

Learnings & next steps

Using Claude Code to work directly against a live repo was a genuinely fun way to work. Learning how to ask for exactly what I needed — and making sure the agent wasn't overstepping its bounds or losing context — was its own skill.

The base work of a design system's logic can be accelerated immensely with LLMs, but defining the actual design patterns for a specific product is still not easy: a lot of what feels obvious to a designer is rarely clear to an agent trying to build a UI on its own.