Lucid Care: How far can you orchestrate AI agents before they stop building your product?

The experiment

I took an old side project, one with nothing riding on it, and decided to see how far AI agents could carry a redesign if I tried to stay out of the room. Not how fast, but how far before the work stopped being mine.

Lucid Care is an eldercare advisory tool. A care adviser sits at someone's kitchen table, with an elderly person and their family, and works through a statutory consultation. I had built the first version years ago: a 47-field form built for the auditor, not for the person across the table. I still had all the old screens. So I fed them to the agents and handed over the thinking, not just the making.

Write a new PRD from these screens. Walk the flow, review the usability, write fresh specs, produce new wireframes. I wanted to watch the agents do the parts of my job I'd normally guard.

What the agents got right

They were good. The PRD was sound. The flow held up under pressure, and the specs were clean enough that an engineer could have built from them without a single question for me. If the job had been to turn a messy old product into correct specifications, I could have almost left the room.

Correct, but not right

Then I asked the agents to keep going: build the interface from the specs they had just written. What came back matched the specs exactly, but it was ugly. The same agent that had just written a sharp PRD produced screens I would never put my name on. The colours fought each other, and neither the spacing nor the type had any rhythm on the page. Structurally the UX was right; at a glance you could tell no designer had been in the room. The same machine, working just as hard, gave me one thing I would defend and one I would hide.

I went looking for why, and the answer wasn't the agent. An agent builds the average of everything it has ever seen, unless something tells it what you specifically want. Mine told it almost nothing. I had skipped the look and feel work, so my taste lived in my head and in a few scattered notes, not anywhere the agent could read. The design tokens were half defined. The list of components was out of date. And I had tossed in a mockup I'd once started for the new version as a taste reference. It was only half finished, but nothing in it said so. The agent read it as final, built on top of it, and every small flaw I hadn't polished out yet scaled quietly into the code.

That was the real finding, and it was more useful than the redesign. What I had was a read-only design system: the agent could see it, not build from it. So the experiment quietly changed shape. The interesting work was no longer the screens, it was making the system itself something an agent could pick up and build inside without me narrating every decision.

Rebuilding the system to be read

So I rebuilt it around being read, not just looked at.

I moved the source of truth into the code, where the agent actually works, and named every token by what it means rather than what it looks like, so one colour always means one thing. I generated an index of every component, what each is made of and how the parts connect, straight from the code, so it can't quietly fall out of date again. I wrote down the handful of patterns the product is assembled from, so a plain instruction like build a session screen resolves to the right parts in the right places. And I made the point of view non-negotiable: one colour acts, one signals when the assistant is speaking, because the rebuilt product now drafts consultation notes for the adviser, one commits a decision. No room left for the agent to reach for its defaults. At a kitchen table consultation the adviser has to see at a glance whether the assistant is only suggesting or a decision is being committed. Predictability there is not a matter of taste, it is what keeps the family trusting the screen.

The whole layer came to three files: an index of what exists, notes on when to use each part, and recipes for how screens assemble. Atlassian ships the same idea as a server queried by thousands of engineers; I shipped it as three files for one agent. Same architecture, solo scale.

The order matters more than the tooling. Feed an agent a finished-looking mockup and you get your flaws at scale. Feed it a written system, wireframes and requirements, and you get your product. I had done it backwards the first time; the method is the sequence.

Where I stayed in the room

The agents still did the production. I held the judgment, and the clearest proof of where that line falls is the handful of times I overruled them.

The agent chose the right pattern for the wrong experience. It proposed a locked sequence of questions, textbook form design. But the consultation is human to human: the adviser talks with a family at a kitchen table, so I kept every question visible, free to enter in any order.

The agent took a half-finished mockup as the finished standard. The more finished a mockup looked, the more faithfully the agents copied its flaws along with its intent. Polish used to be a signal that decisions had been made, and the agent is trained to trust it: a half-finished mock reads as finished thinking, so the agent stops thinking. I took the mockups away and gave them wireframes and a written system instead. I went a step further and stopped drawing the wireframes too: a screen sketched in plain text, boxes made of slashes and pipes, typed straight into the chat, cost nothing to redraw and never got thrown away, so I always had a cheap way to hand the agent structure before asking for pixels.

The agent defaulted to the component library every tool reaches for. I chose a different one on purpose, because when the tool picks the aesthetic, there is no designer in the room.

The agent hit a conflict between my spec and the real code, and offered to resolve it with a guess. I told it to follow the real code, and we reconcile the document afterwards.

None of those were skill, they were judgment, the part of the job that did not move to the agent.

Running the experiment again

When the system was rebuilt, I ran the first experiment again. Same brief, same agents, same instruction to stay out of the room. This time the agent read the system, planned, and produced a screen that was actually mine, on the first pass, with no one explaining what mine meant. The test I had failed at the start, I now passed. On the agent-readiness audit I had run before the rebuild, the system scored barely a one out of three. It scores a solid three now. And because the index and the patterns regenerate every time the project builds, the system can't quietly start lying to the agent later.

The real deliverable

A design system is usually treated as the coat of paint, the thing you add after the product works. Here it was the load-bearing wall: it decided whether a machine handed back my product or a competent stranger's. The visible output was the new screens. The real redesign was a system, legible enough that a machine could build inside it without guessing what it meant.

The agent that handed me someone else's design at the start was never the problem; the system it had to read from was. It is built to be read now, and it builds mine.

So here is the question for any team putting agents to work on their product. When an agent reads your design system, does it build your product, or the average of everyone else's?