The agent had mapped the whole onboarding project. It had all the issues in it. I read it back and I still could not tell whether the flow it described was the flow I had in my head. That is not the agent being unclear. It is a lot of information about a sequence of screens, written as text, and text is a bad medium for a journey. So before I let the pipeline build it, I built a clickable prototype of the whole thing.
This is the third article of arc three, on research in automated design: the previous one took a research outcome from project through to delivery, and this one is the step I add when the outcome is a journey rather than a screen.
The prototyping tool
Lovable and tools like it are probably familiar: you describe a prototype and iterate on it quickly. I built a version of that inside Claude Code. The prototypes live in their own repo, separate from the product, and deploy to prototypes.fiuto.ai, so every one of them has a URL I can open and click through.
The difference from Lovable is what it starts with. It has full product knowledge, it knows what the repo looks like, and it builds from Fiuto’s own design system components. What comes out is not a prototype that approximately resembles my product. It is made from the same parts as my product.
Where the single-screen path stops
Often you only need one screen, maybe two, to hand the agent so it can build the full feature. That is what /ux is for. A skill is a named set of instructions I hand to a fresh agent, so it starts with the process already in its head. /ux is the design one. It reads the description I give it, produces designs to pick from, and iterates on the one I pick. It works on one or two screens. It will not generate a journey.
Sometimes the thing I am changing is a journey.
What the research asked for, and what I had
The weekly research routine, the one I call best practices, came back with a point I could not design around one screen at a time: users need a full end-to-end flow. They get into the app and they get it done quickly, with assistance or without, and they reach the activation point straight away.
I already had an onboarding screen. I built it in a couple of hours because I did not have time to work on it properly, and it did one job: collect enough about the user for the agent to start their project with some memory of who they are. That was good enough for what I needed then. It is not good enough for a full cycle.
So I worked with /build, the skill that runs a feature from brief through research, planning, implementation and review, and had it map out the whole thing as a project. Then I opened a separate session to work through it. The project is in Linear with all its issues. At the point of the run described here it was about halfway: most of the issues were done, and it was still going.
What the prototype unblocked
Parts of that project were blocked on me, because I was not sure that what the agent was telling me matched what I was picturing. Specs describe screens. They do not tell you what the flow is like when you move through it.
So I used the prototype repo to build the onboarding we had agreed, end to end. It generates a very good prototype: you click from the first screen to the last and see what the flow will be, not just what the specs say. That is what makes it useful for deciding with the agent whether to keep going.
The last screen is the study page, the surface in Fiuto where a user assembles the research study they are going to send out, and it looks exactly like the real one. It is built from the same design system components, so it should.
From prototype to tickets to a PR
From there it is back and forth with the agent. I prefer this, I prefer that. When the direction is agreed, it goes into UX definition: the work is handed to a UX agent as tickets, and those tickets are what it designs against.
I review those screen by screen. This looks good, this looks bad, do this instead. Once the tickets are agreed the agent works through them and delivers a PR into the repo, and from there the build agent picks the work up again.
That run hit an error partway through. I picked it back up with the agent and carried on. It is a very long task. The state lives in the project and the tickets rather than in the agent session, so picking it up again resumes where it stopped.
Where it stands
Onboarding was worth this much process because it has to be right from the very start, and because it closes the loop with the work in the previous article. A researcher gets into the app, gets straight into a study, gets that study done as quickly as possible, gets results out of it and the insights the AI writes from those results, and shares the study. I hope that produces a good level of activation and sharing. I do not know yet whether it will. Nothing described here had shipped at the time of that run. The app has since soft launched.
There is one more thing a prototyping tool makes possible, which I had not done at the time of that run: running a real user test on the prototype itself.
Running this with your own agent
None of this needs my repo.
- Give prototypes their own repo, separate from the product, and deploy them to URLs you can open. Deploying it means you can open it, and so can anyone whose opinion you want.
- Point the prototype agent at your design system and your product repo, not at a blank canvas. The value is that the output is made of your real components, so what you approve is what can be built.
- Keep the cheap path as the default. For one or two screens, have your design agent produce options from a description and iterate. Only reach for a journey prototype when the change spans screens.
- Build the prototype from the plan, not from a fresh description. The plan is the thing you are checking. If you re-describe the flow to the prototype agent, you will validate your description and learn nothing about the plan.
- Click it from the first screen to the last, and check any screen you already have in production against the real thing. Both are built from the same components, so they should match.
- Iterate in the prototype, where a change is cheap, and settle the direction before it turns into tickets.
- Turn the agreed journey into design tickets, and review them one at a time before anything is implemented.
- Expect a long run to hit an error before it finishes. Keep the state in your tracker rather than in the agent session, so you can pick it up where it stopped.
If you build one of these, the cheapest next move is a few real users clicking that URL before the tickets get written. Fiuto runs that from the coding agent, without you opening the app.
The next article moves past the build to what comes back after it: refining an experience that is already implemented.
