Anyone in the company can change the website with AI now. How BILL keeps it consistent

Code that only looks like the product

In August 2026, David Cai, a UI software architect at the US fintech company BILL, described on the company’s engineering blog a problem anyone working with AI agents will know. Ask an agent for a settings page and you get a plausible-looking settings page. Look closer and you find hard-coded colours where design tokens should be, and a hand-rolled button that almost matches the one in the component library.

Individually, these choices didn’t look like mistakes. Together they pulled the product away from the design system, and every deviation cost a review comment and another round of fixes. According to the post, all of these failures had one cause: the agent was working blind. The knowledge of how to do it right existed, just not in a form the agent could use.

A design system that agents can read too

BILL’s design system is called Trinity, and Storybook is its single source of truth. The team didn’t rebuild anything. It added a layer for agents on top of the existing system: a command-line tool, an MCP server and a set of agent skills through which an agent can ask about components and rules.

The A/B tests described in the post show the effect. With access to the design system, the agent produced the correct components on the first pass, and token usage per task dropped by 31 to 63 percent. Without that access, in one test the agent was asked for a radio tile group and shipped standard radio buttons with hard-coded colours and spacing instead.

Luke Wroblewski sees the same thing

Luke Wroblewski has worked on design systems for more than 20 years, and on LukeW.com describes a pattern every design team knows. A company invests in a system, then can’t keep it up to date, and eventually the documentation describes a product that no longer exists. AI agents add a second problem. Marketing, engineering and product all change the site through their own agents, and each agent brings its own tone, colours and spacing unless something steers it.

In the projects shown in the post (the Intent, Sol and Aria websites), it works like this. Colours, fonts, type sizes and the grid live in code as design tokens. An AGENTS.md file tells agents to reuse the existing classes and variables instead of duplicating values. The design system page is built from the same code as the site, so it is always current. When someone asks an agent for a new button, it reuses the existing component, which also adapts to dark mode, and nobody has to check anything by hand.

“Agents read it every single time.”

That’s the last line of the post. Designers spent years trying to get people to read design system documentation, with mixed results. Agents read it on their own, as long as it exists in a form they can read.

How common is this

A zeroheight survey of 123 design system practitioners found that 59% see UI bypassing the design system. Half say other parts of the organisation use AI without involving the design system, and the same share say other teams’ AI use is creating problems. 44% of organisations simply tolerate it. Only 17% rate their documentation as very AI-ready, even though 48% already run an MCP server.

Where to start

You don’t need an MCP server on day one. The sensible place to start is tokens: colours, typography and spacing stored in code as named values the whole site uses. Once they’re in place, add a short instruction file for agents and automatic checks that new screens and code changes match the design system before they reach customers. If your company doesn’t have a design system yet, it is best designed together with the interface, as we describe on our UX/UI design page.

In our service this is the consistency without policing area. Inconsistencies show up straight away rather than after launch, no matter who made the change or with which tool. For how a well-documented design system shortens handoff to developers, read our post on design handoff in the age of AI.