A lot of the current discussion around AI focuses on context. We connect models to codebases, design systems, documentation, tokens, component libraries and increasingly detailed product specifications.

The assumption is understandable: if AI receives an accurate source of truth, it should have everything necessary to produce an accurate result. In practice, that assumption is incomplete.

There is another problem, and I believe it may become more difficult than providing the context itself. AI does not always follow the information it has been given.

This is where the idea of a discipline layer becomes important. Context tells the model what is correct, while discipline determines whether it actually remains within those boundaries.

A correct source of truth can still produce the wrong result

I have been dealing with this problem directly while building TrueUI, a Figma plugin designed to make AI work with an existing design system instead of inventing one.

The first challenge was relatively clear. The AI needed an accurate representation of the system, including its components, variants, colors, typography, icons, spacing and other design decisions.

That required mapping the design system into information the model could actually use. Once that mapping became sufficiently accurate, I expected generation quality to improve accordingly.

It did improve, but another problem became much more visible. The model could understand the specification correctly and still choose not to execute every part of it.

Consider a relatively simple component request. A search component contains three states: Collapsed, Open and Focused, with Collapsed defined as a round icon-only control.

The model can receive that requirement correctly, understand the three requested states and even describe the differences accurately before it begins creating anything.

The generated result can still contain three almost identical search fields. Collapsed may remain a full field, Open may look nearly identical, and Focused may only change its border.

From a structural perspective, the result is wrong. Yet from the model’s perspective, it has created three states and introduced a visible difference between them.

The same behaviour appears with larger component sets. Request regular, dropdown, password and date fields, and the model may create all four property names while repeating one structure.

Everything can look technically organised. The Figma component set exists, the properties exist, and the variants are arranged correctly, yet several explicit requirements have disappeared during execution.

At that point, the problem is no longer a missing specification. The model received the information it needed. The failure happened between understanding the requirement and executing it.

Knowing what to do is different from doing it

This distinction is easy to overlook because we often treat AI mistakes as context problems. When the output is wrong, the natural response is to provide more information.

Sometimes that works. If the model does not know which button exists, which token is valid or which icon belongs to the system, better context can solve the problem.

But there is another class of failures where the model already knows the answer. It simply makes a different implementation decision while completing the task.

AI models constantly make decisions about efficiency, structure and interpretation. They simplify requirements, infer patterns, remove what appears redundant and choose alternatives they consider more appropriate.

That behaviour is valuable when the task is genuinely open-ended. If I ask for a good dashboard, I want the model to make design decisions instead of mechanically following instructions.

The problem begins when the model applies the same freedom to requirements that are not optional. A required state, icon, content element or structural difference should not become a suggestion.

This creates an important distinction between creative freedom and contractual requirements. AI needs room to make decisions, but it also needs to recognise where that freedom ends.

The source of truth solves only the first problem

This is why I think the current debate about whether design systems should live in Figma, Storybook, code or another structured layer misses part of the issue.

Where the source of truth lives certainly matters. Maintaining several disconnected representations creates drift, duplicated work and uncertainty about which version represents the actual product.

However, consolidating that information does not guarantee that an AI agent will use it correctly. A perfect source can still produce an imperfect interpretation during execution.

You could give the model direct access to the production codebase, the component library, every design token and the complete documentation describing how everything should behave.

The model could still choose a different component, simplify a state, substitute an icon or remove something it believes is unnecessary for the result.

That means an AI-enabled system needs to solve two separate problems.

The first is specification: making sure the model understands the system, the available building blocks and the exact requirements of the task.

The second is discipline: making sure required information survives execution and appears correctly in the final result instead of being silently reinterpreted or discarded.

A discipline layer is not just a longer prompt

One of the more frustrating lessons from building TrueUI has been discovering that adding more instructions does not necessarily create more disciplined behaviour.

The obvious response to a failure is to strengthen the prompt. Explain the requirement again, add another rule, add validation language and explicitly describe what must not happen.

There is a limit to that approach. A longer instruction set can introduce competing priorities, increase complexity and sometimes make the model less reliable rather than more accurate.

I have seen newer versions of the same generation system contain more rules, more checks and more detailed guidance while performing worse against the original user request.

That experience changed how I think about discipline. It cannot depend entirely on persuading the model to remember every requirement while simultaneously solving the design problem.

A real discipline layer needs to turn important requirements into things the system can inspect. It should determine whether requested states, components and structural differences actually survived generation.

For example, if Collapsed must contain only an icon, the system should verify that the generated Collapsed variant does not still contain the complete search field.

If four field types were requested, the system should verify that all four exist and that the structural differences specified for each type are actually represented.

If the design system provides an approved icon, the system should detect when the generated result replaces it with an unrelated alternative rather than assuming visual similarity is sufficient.

This is fundamentally different from asking the model whether it thinks it completed the task successfully. The requirement itself becomes part of the acceptance criteria.

Discipline can be harder than mapping the system

When I began working on TrueUI, I expected design-system mapping to be one of the most difficult parts. It requires extracting and organising a large amount of structured information.

The system needs to understand components, tokens, typography, icons, variants and relationships without overwhelming the model with irrelevant information or losing important details.

That problem is complex, but it has relatively clear boundaries. You can inspect a design system, represent what exists and eventually determine whether that representation is accurate.

The discipline problem behaves differently. Closing one path for deviation does not necessarily prevent the model from finding another technically valid way to satisfy the task.

A validation rule may confirm that three variants look different, while the model satisfies that rule by changing only corner radius instead of implementing the requested structural difference.

A component may contain the correct properties while several of their values produce identical output. The structure looks valid to the system while the user’s actual intent has been lost.

This is why discipline can become more complicated than specification. You are not only describing what should happen; you are determining what evidence proves that it happened.

More capable models may make this problem more important

It is tempting to assume that better models will eventually remove this issue because they will understand instructions more accurately and make fewer obvious mistakes.

That may solve some failures, but greater capability also means greater autonomy. More sophisticated models make more decisions about how they believe a problem should be solved.

That independence is extremely useful for exploratory tasks. It becomes more complicated when an agent is working inside an established product, workflow or operational system.

A model that notices a seemingly better solution may decide to pursue it even when the original instruction deliberately specified something different for reasons it cannot see.

The model is optimising from the information available to it. The organisation may be operating with product constraints, customer expectations or historical decisions that are not negotiable.

This is why stronger AI does not reduce the need for discipline. In many cases, stronger autonomy increases the importance of clearly defining where autonomous judgment is permitted.

This problem extends far beyond design

Design systems make the issue easy to see because visual deviations are immediately visible, but the same principle applies to almost every AI agent performing consequential work.

An agent can have accurate access to company policies, product requirements, APIs, code, operational documentation and customer information while still choosing an unintended path toward its objective.

Giving the agent better context reduces uncertainty. It does not automatically prevent the agent from interpreting, optimising or navigating around constraints while trying to complete its task.

As AI moves from producing suggestions toward planning and executing actions, the distinction between context and discipline becomes increasingly important across product development and operations.

The source of truth tells an agent what environment it operates within. A discipline layer defines which parts of that environment cannot be casually reinterpreted during execution.

From context to controlled execution

I still believe giving AI access to a high-quality source of truth is essential. Without it, the model is forced to invent far too much of the system.

But access should be considered the beginning of the architecture rather than the final solution. Accurate context needs to be followed by controlled execution and verification.

For design systems, that means understanding the components and tokens while also checking whether generated work actually respects the requested structure, content and relationships.

For other AI systems, the exact mechanisms will differ, but the principle remains the same. Important requirements need to survive the transition from understanding to execution.

The industry has spent enormous effort improving what models can see, retrieve and understand. MCP, larger context windows and increasingly connected agents are accelerating that process.

The next challenge is making sure that access to better information consistently produces behaviour that respects the intent behind that information.

The source of truth tells AI what is correct. The discipline layer makes sure that correctness survives execution.