The same screen exists in four places

A design decision does not live in one place. It lives in the written specification, in the code running in the app, in the catalog where the team sees the component alive, and in the Figma file that people outside open. Four representations of the same thing. While they were four sources, nobody knew which one was right, and the honest answer to "what color is this button" was "depends where you looked".

What I changed was not the tool, it was the direction. The specification became the source. The code draws from it. The catalog is the code running, not a copy of it. And the Figma file became generated, not hand-drawn.

That order is what makes the agent useful. It does not need taste to tell me the specification declares three states and the code draws two. That question has a right answer, and it is unbearable to answer by hand across 88 screen parts. Today 22 flows are checked by a program, with output a person reads, and the list of what does not line up is my work for the week.

What it hands back, by the way, is more useful than the green. Translating a screen into the specification always comes back with what the design did not say: a state nobody decided, a piece of text that does not exist, a measurement that appears exactly once. That is not a fault in the program. It is the work queue showing itself.

The missing edge is the one that still costs me time. From Figma back to the specification nothing is generated: somebody draws in the file, and the change has to be told by hand to everything else. Of the four ends, it is the only one with no way back, and it is exactly where the versions start diverging again.

None of this is about writing less. It is about having a source you can question. An agent on a project without that order only speeds up the divergence: instead of one wrong copy, four.