Slot Machine: Use AI to need less AI in design systems
TJ Pitre is the founder of Southleft, a front-end agency specializing in design systems and AI-driven product workflows. His July 2026 article in the Slot Machine newsletter argues against treating AI as a continuous enforcement layer in design systems — and for treating it as a one-time authoring tool instead.
The core argument
Pitre divides design system work into two piles. The first requires judgment: deciding what a component spec should say, choosing token names, writing documentation that handles ambiguity. The second is mechanical: checking that every screen a developer builds actually follows what the spec says. AI handles the first pile well and the second pile poorly.
“AI is great at the first pile and a liability in the second,” Pitre writes. The reason is structural: a language model can be argued with, reframed, and confused by novel context. A schema validator cannot. Authority in a design system belongs to whatever layer can refuse deterministically — and that should never be a model.
Evidence from a controlled test
Pitre describes a test run by Southleft. An AI agent asked to build screens without governance constraints scored 69 out of 100, with 90 violations of design system rules. The same agent, operating under DS Contracts — compiled specification files that constrain which components can be used and how — scored 100 out of 100.
The article attributes this to a simple mechanism: when the agent has access only to what the spec allows, it cannot produce output that violates the spec. The mechanical layer enforces what the model cannot be trusted to enforce on its own.
The design tokens example
The article uses the Design Tokens Community Group’s 2.0 specification (released 2025) as evidence that design systems can be made machine-readable without AI involvement. Tools like Figma and Style Dictionary already consume shared token formats. When tokens are properly specified, AI can read them during the authoring phase without needing to interpret them repeatedly during the build phase.
Pitre also references Nathan Curtis’s component spec tool, which extracts specifications in roughly one second deterministically. The same task via AI inference takes five to ten minutes and produces variable output. For recurring mechanical work, determinism beats AI on both speed and consistency.
What this means in practice
Pitre’s prescription: use AI to write the contract once (component specs, token definitions, documentation), then compile that contract into a format that deterministic tools can enforce. After that, remove AI from the loop. Agents building screens should operate inside the compiled contract, not alongside an AI model re-evaluating the contract on each run.
The article is relevant for any design system team debating where to add AI-assisted tooling. It draws a line that is often blurred in practice: AI for creative and authoring work, determinism for validation and enforcement.