I asked an agent to swap one colour value across a file. It did. It also rewrote the line that defined the value in the first place, so the definition now pointed at itself.
Nothing errored. Nothing warned. The instruction ran perfectly, which is the whole problem.
Every one of these has the same shape
A single condition matched more than I meant, and everything that matched got changed.
The second one I still think about: hiding a set of shadow rectangles also hid a keyboard, because the keyboard's parts satisfied exactly the same single condition. Again no error, again a clean report of success.
Once you see the pattern it's everywhere. It isn't a model being careless. It's an instruction that was less precise than it felt while writing it, executed with total literalness by something that has no idea what any of these objects are for.
The rule: scope, and two conditions, never one
Name the region it may touch. Not "the file" — this section, these frames, this layer group.
Then give it two properties that must both be true. Not "everything with this colour" but "everything with this colour, inside this region, that is a fill rather than a definition". The second condition is doing the real work: it's what stops the match spreading into things that happen to share one attribute.
It's a small amount of extra writing. It's the difference between a change and an incident.
It cannot see the result — that's the fixed constraint
An agent writes the change, the change renders somewhere it has no eyes on, and it reports success based on the instruction completing rather than the outcome being right.
People treat that missing feedback loop as a tooling problem, something that will be solved in a future version. I don't think it is one. It's a sequencing problem, and sequencing is available today.
The loop can't be closed by the agent. Fine. It can still be closed by a person — just not a hundred times.
One, then all
Run the operation on a single representative case. Render it. Look at it with your own eyes, before and after. Only when that passes does the same operation run across everything else.
Binding values, building components, swapping instances, generating images — same shape every time.
This sounds obvious written down and almost nobody does it. The pilot feels like a waste when the batch is right there and the agent sounds confident. That confidence is the tell: it reports identically whether it produced one correct thing or a hundred wrong ones, because it isn't looking at the output, it's looking at whether the instruction ran.
The economics favour the pilot, which surprised me
I assumed the careful path was the slower one. It isn't.
One pilot plus one clean batch costs less in tokens, time and patience than one confident batch plus the unwind. And unwinding is much worse than redoing — you're now hunting for damage across a hundred items with no error message to guide you, and you can't be sure you found all of it.
There's a second effect I didn't expect. Because a pilot is small, I actually look at it properly. When a hundred results land at once I skim, and skimming is precisely how the subtle wrong things get through — the ones that look plausible.
Bulk swapping will eat your real content
Worth calling out separately because the damage is silent.
When screen layers get swapped to component instances, the overrides are carrying real copy — actual names, actual prices, actual text somebody wrote. A careless bulk swap replaces all of it with the master's placeholder content, and you find out several screens later, if at all.
This is the single most expensive small mistake in the whole process, because the damage is distributed and invisible unless you happen to open the right screen. Pilot it. Every time.
Never accept a blanket fix
Any tool that offers to correct everything at once is offering to guess, and the guess is usually "snap to the nearest value".
Nearest is a visual measure, not a semantic one. A value that's visually closest is very often not the value that was meant, and once it's applied there's nothing left in the file recording that a choice was ever made. The system quietly acquires meanings nobody chose.
Use those tools to find things. Decide the fixes yourself, or at least decide the categories and apply them deliberately.
Re-run the whole check, not the part you touched
After a change that crosses layers, checking only the thing you changed tells you very little. The failure mode of bulk operations is precisely that they affect things you weren't thinking about.
So the check has to cover the same ground every time, including the parts you're confident about. Confidence is not evidence, and on the two occasions above I was completely confident.
What this doesn't solve
Pick the wrong representative case and the pilot passes while the batch still breaks. Choosing one that's hard enough to be a real test is a judgment call and I haven't turned it into a rule. I lean toward the messiest example rather than the cleanest, which is instinct, not method.
And there's a cost to all of this: it's slower per operation, and on a small file that overhead can exceed what the damage would have been. I still run it, because the failures aren't proportional to file size — the keyboard incident happened in a file I'd have called simple.
The whole thing, recorded on one real project
I recorded the full path end to end — brief, structure and flows, generated screens, locked token system, Figma with real components and variables, clickable prototype, developer handoff — on a single project, breakages included:
Claude AI UI/UX: Complete Workflow from Brief to Figma — the same path on one real project, brief through to a Figma handoff.
If a bulk operation has quietly eaten something of yours, I'd like to know what matched. Those stories are the most useful thing anyone has given me.
Top comments (0)