No canvas as source of truth

Most design-tool conversations still assume that the canvas is the center.

The tool can become smarter. The canvas can get variables, tokens, states, responsive rules, AI, code export, dev mode, prototypes, publishing, and real preview. That is a logical direction if the goal is to make the design tool closer to code.

But I think there is a stronger move: do not make the canvas smarter as the center. Move the center.

If the repo already contains the product system, why should a separate canvas be treated as the place where the product “really” exists?

In a repo-first workflow, the source of truth is not a drawing of the interface. The source of truth is the system that can be read, changed, checked, versioned, reviewed, and deployed.

That means code. But not only code.

It also means Markdown artifacts, design-system rules, component guidelines, component essences, tokens, scripts, backlog structure, content snapshots, routing, page templates, and deployment workflow. The source of truth is the set of artifacts that actually shape the behavior of the system.

This is why “Figma vs code” is still too small as a debate. The deeper question is where the system remembers itself.

If knowledge lives inside a tool, the tool becomes the boundary of the system. When the tool changes, disappears, exports badly, or fails to represent a constraint, the knowledge leaks.

If knowledge lives in versioned artifacts, another tool can read it. Another agent can operate on it. Another UI can render it. Another workflow can verify it.

Tools are views. Artifacts are the source of truth.

This is where the agent changes the architecture. The agent does not need to sit outside the system as a chatbot that receives pasted context. The agent can operate inside the source of truth.

It can read the Markdown rules. It can inspect components. It can update code. It can modify content snapshots. It can generate missing documentation. It can write component essences. It can run checks. It can prepare a branch, show the diff, and update the system through the same artifacts that humans use to review, version, and deploy.

That is very different from a canvas-first model.

A canvas-first model says the designer works in the canvas, then the tool tries to make that canvas closer to implementation. A repo-first model says the product system lives in the repo, and the agent helps humans steer that system directly.

This also changes what UI is for.

UI is no longer necessarily the place where the product truth lives. UI becomes a preview surface, a review surface, a control surface. It is where the human sees what the agent did, checks the result, compares states, catches risk, and decides whether to continue.

The UI can be beautiful, useful, and custom. It can expose components, pages, breakpoints, tokens, content, and states. But it is still a view into the system, not the source of truth itself.

This is why a custom design-system preview page can make more sense than a generic Storybook setup if it fits the actual workflow better. The point is not the tool name. The point is whether the preview reads from the real system and helps the human control it.

The same applies to Figma. If Figma is just a view, maybe it can be useful in some workflows. But if the repo is already the source of truth, Figma does not need to be the center. In many cases it does not need to be there at all.

The hard part is not making another tool where rectangles can be arranged. The hard part is building a system where intent can become a controlled change to real artifacts.

That means source artifacts are versioned, rules are readable by agents, components are real, previews render the actual system, changes happen through branches and diffs, checks run before deployment, humans review meaning and risk, and the system learns through correction and compression.

This is not a handoff problem anymore. It is an operating model problem.

The old question was how to move design from Figma to code. The new question is why design is outside the source of truth in the first place.

A repo-first model can be summarized as a simple working loop.

human intent
-> agent reads repo artifacts
-> agent edits code / Markdown / rules / components
-> preview renders actual system
-> human reviews
-> checks run
-> branch merges
-> deployment happens
-> lessons compress into rules

This is not “no UI”. This is UI in a different role.

The UI is not the canvas where truth is invented. The UI is the surface where truth is previewed, inspected, controlled, and approved.

No canvas as source of truth. Repo as source of truth. Agent as operator. UI as preview and control surface.