Where it started
For years, Cambium lived in Figma as redlines written for a human to read.
Cambium was Kapiche’s design system, which I built and then maintained for most of my time at the company. For years it worked the way design systems were expected to work, with components and specifications living in Figma and redlines drawn directly onto the canvas. Measuring lines, dimension values and written rules sat beside each component. They covered everything from where a tooltip should appear relative to its trigger through to the width at which text should begin wrapping. Component matrices alongside them documented every state an engineer might need to build. All of this rested on the assumption that a human reads the specification and then writes the code. For a long time that assumption held perfectly well. For years, consistency problems disappeared for anything Cambium touched.
What broke it
The system lived in three places, and its gaps pushed engineers into hardcoding values.
By 2026 the same design system was living in three places at once. It existed in Figma where I designed, had been ported into Claude Design because I had moved to an AI-assisted workflow myself, and also sat in Kapiche’s GitHub repository where the engineers built from it. Each of those was a plausible source of truth. Over time they drifted apart to the point where an engineer checking the repository and a designer checking Figma could both be working entirely correctly and still disagree about what the system said.
What made this harder to see was that the drift wasn’t purely a copying problem. The system was also incomplete in a way that quietly pushed people out of it. The colour scales shipped only the 50, 500 and 600 steps. Whenever an engineer needed a shade the system didn’t define, they had little choice but to hardcode a hex value. Those hardcoded values then aged independently of everything else, invisible to anyone reading either the tokens or the Figma file. The engineers weren’t ignoring the design system so much as routing around a gap in it. That is a far more uncomfortable diagnosis, because it makes the system responsible rather than the people using it.
Some of that had already accumulated into real defects. When I ran a contrast audit as part of the Carson work, I found two semantic colours failing WCAG AA as text in production, with green sitting at 3.7:1 and amber at 3.1:1.
What Carson needed
Carson got its own identity on Cambium’s structure, so there was still one system to maintain.
Carson was Kapiche’s self-serve analytics product and it needed to read as a separate product with its own feel, not a cheaper version of Kapiche. That could reasonably have justified building it a new design system from scratch. As the only designer in the company, though, I wasn’t willing to take on two systems to maintain, so Carson’s design system descends from Cambium instead of replacing it.
The structure is what carried across. Carson’s action colour is a cobalt cerulean rather than Kapiche’s blue, but the tokens keep Cambium’s names, --teal-50 through --teal-950. Those names describe the role a colour plays rather than the hue it happens to be. Anyone moving between the two products is reading the same grammar, even though the vocabulary has changed. The identity is what didn’t carry, with a new palette and typeface, the navy tint stripped out of the neutrals, and a coral held strictly for brand marks and banned from the interface entirely. As a result, Carson feels like its own product at the surface while remaining structurally the same system underneath.
The fix
The three changes I made were all aimed at the underlying failure instead of its symptoms.
- 01
Complete the colour scales
I completed the colour scales first, so that the mid-shades engineers had been hardcoding finally existed as tokens. The principle was that a system people have to route around will drift no matter how well it is documented.
- 02
Write a manifest
I then wrote a manifest declaring which source wins when the documents disagree. It is a governance document rather than style guidance, so the question of which version is correct has an answer instead of becoming an argument.
- 03
Build it as a working site
The last change was to build the system as a working HTML site with copyable values, live components and real interaction states. It sits alongside a machine-readable rules file, so both are driven by the same source. Engineers using their own AI tooling can generate directly from the rules. The site is how a human then judges whether what came out the other end is right. Without a reference to review against, generating from the rules would only move the drift somewhere harder to spot.
What AI changed
Machine-readable rules made the system easier to maintain and a framework for prototypes.
AI made the design system much easier to use, update and maintain. With the rules in a machine-readable file, a change to a token or component could be made once and carried through to the site and the rules together. It no longer had to be copied by hand into each place the system lived.
It also changed what the system was for. Prototypes could be built rapidly by AI agents using the design system as their framework. What came out already used the right tokens, components and states, so review could focus on whether the idea worked instead of on correcting the styling.