Design systems for teams shipping with AI agents

Kilo has brought in Ivan as its first designer, and he is joining a team that already ships features at high speed. According to the post, there was no design function before he arrived, yet product work kept moving as engineers and AI agents pushed code directly into production.

Ivan describes the pace as “agent speed.” Engineers at the company behave like “mini-CEOs,” seeing a problem and shipping a solution without waiting for mockups or formal specifications. That speed has made the role of design harder to define, because the work often lands before a designer even sees it.

He says there are two bad outcomes for a designer in that setup. One is becoming a “pixel janitor,” cleaning up after decisions that have already shipped. The other is producing polished Figma files that look good but are irrelevant by the time the team looks at them.

That tension is pushing Kilo to rethink what a design system is for. Traditional systems usually assume a human designer will read the rules, apply judgment, and decide when to break them. Ivan argues that assumption breaks down when AI agents are writing code and engineers are moving too quickly to keep checking design files.

In his view, the system has to be directly usable by the people and agents doing the shipping. Documentation becomes part of the infrastructure, not just a reference for designers. A file like DESIGN.md, he says, can matter as much as README.md if it is written clearly enough for agents to read and act on.

That means the documentation has to be specific. Instead of broad values like “we value simplicity,” Ivan wants concrete rules such as “form labels are sentence case, never title case” and “error states always include a suggested action.” The goal is to write guidance that is machine-actionable, not just inspirational.

He outlines three phases for the work. In the short term, the team is auditing what already exists, finding inconsistencies, and creating a shared baseline. He says that means documenting the reality of the product now, including drift in button styles, spacing, and color use.

In the medium term, Kilo wants to formalize the system through DESIGN.md and custom skills that encode “the Kilo way.” Ivan also describes the possibility of a drift linter, a CLI tool that could flag components or patterns that do not match the design system, similar to how code linters catch style issues.

Long term, the company wants agents themselves to help maintain consistency. Ivan imagines reviewers that can flag design drift in pull requests, check copy against voice guidelines, and spot palette violations before they spread. The aim, he says, is to set policy, build reviewers, and then review the reviewers instead of manually inspecting every pixel forever.

He still has open questions about how much process a high-velocity culture can tolerate, where skills should live, and how to measure drift without producing too many false alarms. For now, he is in the audit phase, documenting what exists and building the baseline before the next layer of the system takes shape.