System

Problem

Design systems usually optimize for flexibility early on. That makes sense when a product is still exploratory, but it does not scale well in complex environments.

In multi-step workflows, continuous iteration, and AI-assisted generation, small inconsistencies compound quickly. Components drift, patterns diverge, and similar problems get solved in slightly different ways. Nothing is obviously broken, but the system becomes harder to reason about and gradually harder to trust.

The issue is not only visual inconsistency. It is loss of predictability.

Solution

I made the opposite tradeoff: constraint over flexibility.

The goal was not to make it easy to build anything. The goal was to make it hard to build something inconsistent.

That changed the role of the system. Instead of acting only as a flexible component library, it became a governed operating model for design and implementation. The system defines boundaries, translates intent into constrained execution, and gives AI enough structure to produce useful work without introducing noise.

How it was applied

The system was applied through four connected layers: first the operating model, then the governance structure, then the execution rules, and finally the playground where the design system could be inspected before the product interface was mature.

1. Operating model

The workflow is built around three main phases: Ideate, Execute and Evaluate.

Ideate is where I work with ChatGPT to reason through the design problem, clarify UX decisions, model workflows, and shape the prompt before implementation. This phase is intentionally human-led. The AI helps structure thinking, but the direction still comes from the designer.

Execute is where Codex implements scoped changes. It does not operate as a freeform generator. It receives a governed prompt with constraints, files, scope, and success criteria.

Evaluate is where the output is reviewed. That can mean screenshots, small videos, manual UX review, or automated checks with Playwright. Evaluation is not only about whether the UI looks right. It is also about whether the system stayed coherent.

At the center sits Governance. Governance is always on. It is not another step in the loop; it is the set of rules and constraints that shape every step.

Two secondary flows make the loop compound over time:

• Govern sits between ideation and execution. It turns intent into constraints, scope, rules, and success criteria.
• Codify sits between evaluation and the next round of ideation. It turns what was learned into better prompts, stronger rules, reusable patterns, and clearer boundaries.

2. Governance detail

Governance is the mechanism that keeps the system coherent.

It combines design rules, architecture boundaries, AI operating instructions, token usage, and prompting discipline into one shared structure. This matters because AI-assisted iteration can drift quickly when constraints are implicit.

The core governance artifacts are:

• CONTRACT.md defines what must remain true: design system principles, architecture boundaries, token usage, quality standards, and non-negotiable rules.
• AGENTS.md defines how AI should operate: execution modes, task structure, prompting rules, debugging protocol, scope discipline, and communication patterns.
• Semantic tokens make visual decisions systematic instead of local.
• Architecture boundaries define what can change and what cannot.
• Execution modes define how large or risky a task is allowed to become.
• Token optimization keeps prompts focused, cheaper, and easier to evaluate.

Together, these files make the system executable. They turn design principles into operational constraints that Codex can follow.

3. Execution detail

The execution layer exists because not every implementation request carries the same risk. A small token adjustment and a new workspace architecture should not be handled with the same level of freedom.

Without scope, AI tends to overreach: it refactors when it should patch, invents patterns when it should reuse them, or changes adjacent files because they look related. Scoping made each request more predictable.

• Micro is for precise, localized changes. It optimizes for control and prevents new patterns, refactors, or unrelated improvements.
• Meso is for bounded feature work. It allows coordinated changes, but only inside a defined area.
• Macro is for structural system evolution. It can question workflows or architecture, but requires planning, decomposition, and governance review before implementation.

The execution prompt made that scope practical. ChatGPT was shaped to translate design intent into a Codex-ready brief: task type, feature type, goal, exact files, constraints, and success criteria.

This made the prompt behave less like a request and more like a contract for execution.

Debug prompting appeared when normal iteration created too much extra change. Instead of asking Codex to “try again,” the debug prompt forces diagnosis first: what should happen, what is wrong, which files are involved, and what is the smallest fix.

That prevents debugging from becoming redesign.

4. Design system playground

The design system philosophy was simple: structure over decoration, semantic tokens over hardcoded values, and interaction driven by hierarchy instead of color.

The playground helped test whether that philosophy was actually working before there was a real interface. It gave me a place to see tokens, typography, buttons, fields, states, status badges, and early application patterns together instead of judging them in isolation.

This was especially useful for an ERP-style case management product, where small UI decisions repeat across many workflows. Field density, status treatment, action hierarchy, borders, muted surfaces, and activity patterns all needed to feel coherent before the interface became more complex.

The playground was not only a component inventory. It was a pressure-testing surface for the system.

Tradeoff

You lose flexibility.

Screens cannot easily diverge from the system, and custom solutions are harder to justify or implement. Some things feel slower at the beginning because decisions have to be made at the system level instead of per screen.

That is intentional, he system trades short-term freedom for long-term predictability.

Outcome

The system became more predictable as it evolved.

Over time, the same kind of work required less prompting, fewer tokens, and less rework. That was one of the clearest signals that the governance model was working: the system was not only producing better screens, it was reducing the effort needed to keep those screens coherent.

Codex became more useful because it was no longer operating from vague intent. It worked inside a clearer structure: scoped tasks, explicit constraints, reusable primitives, semantic tokens, and defined success criteria.

The practical impact was:

• More work done with fewer tokens.
• Fewer rounds of correction after each implementation.
• Less drift between components and screens.
• Stronger reuse of existing patterns.
• Clearer debugging when something broke.
• More confidence to keep iterating without degrading the system.

The design system also became more robust. Each iteration added clarity to the rules, prompts, components, and boundaries. Instead of becoming messier over time, the system became easier to reason about.

That was the main outcome: AI-assisted iteration became more controlled, more efficient, and more reliable.

Next steps

Structurally, this is mostly done, but it has not been tested under real pressure yet.

The next step is to push it harder with more realistic and messy data, more edge cases, and longer AI iteration cycles. I want to see whether the constraints continue to prevent drift as workflows become more complex.

The goal is not to add more. It is to test whether the system still holds when complexity increases.