My atomic components were the defaults that ship with DaisyUI, the component library my app is styled with, and they were not very nice. The pills were the worst of it: outlined, not very nice to see, and they turn up in the lists and on the template screens. I did not open a design file. I asked my coding agent to redo them, the whole set in one pass, and the implementation reached the app in approximately a couple of hours.
Fiuto is the app I am building. It is a usability tool that uses AI to help researchers and developers create studies from scratch, a study being the set of tasks and questions you put in front of respondents.
This is the first article in the series. The series is about designing and implementing directly in the app, using skills I wrote for my coding agent, with no design file in between. A skill is a named set of instructions I hand to a fresh agent so it starts with the process already in its head. This first arc covers the core flows, and it starts with simple components. One judgement can cover a whole set of them at once, and that is what makes a batch pass possible.
What I asked for
The request was small. The default atomic components are not very nice, improve them. I did not write a spec and I did not describe a target.
The skill is /ux, the design one. I named its ideate step, the part that generates directions to pick from, and it ran inline in my session rather than going to a separate agent. I am fairly sure naming the step is what did that.
The variants come out of my request, but they are also grounded in best practice, and before it draws anything it does a quick market scan.
Three variants, then iterate
It produces three variants a round and renders them inline, as real markup in the session rather than as a description of a design. The inline renderer runs in Claude Code and in Codex. It works better in Claude Code. So I look at the thing itself, in dark and light, and not at a paragraph telling me what it would look like.
It will usually recommend one of the three. I do not have to take it. I review, say what is wrong, and the next round comes out of that. The rounds run in the session with nothing built in between, so rejecting a direction only costs another round. I keep iterating until the result is pretty much what I wanted.
Into the component workbench
Once the direction is settled it builds the components in Ladle. Ladle is a component workbench: each component renders on its own page, in isolation from the app, so I can check every state without navigating to a screen that happens to contain it.
It did not start from nothing. My repo already had builds of these components in use, and through the iterations the skill adapted those rather than inventing a parallel set. What comes out is the same components, changed, not a second component library sitting next to the first.
Into the app, in batches
From there it was implemented in the app, which took approximately a couple of hours.
I rolled it out in batches rather than all at once, so at the time of the recording old and new were both live depending on where you looked. Staging had the new pills, in the lists and on the template screen. Production still had the old ones. The rollout was partway through, so some components had been updated and some had not, and the priority tag was still the old outlined version. The app has since soft launched.
Seen next to each other, the old pills are terrible. The new ones are much better, and you can see it just by looking at them.
Running this with your own agent
None of this needs my repo.
- Batch by shared judgement. Pills, tags, badges: components that can all be resolved by the same call. If one of them needs an exception, it does not belong in this pass.
- State the problem, not the solution. “These are not very nice, improve them” leaves the agent room to come back with something you had not pictured.
- Have it scan the market before it draws, and ground the variants in best practice as well as in your request.
- Ask for three at a time and look at them rendered, not described. Three is enough to see a spread and few enough to judge quickly. If your agent cannot render inline, have it write the round to one static HTML file and open that in a browser.
- Iterate on rejection. Say what is wrong with each option and let the next round come out of that, rather than rewriting the brief between rounds.
- Point it at the components already in your repo so it adapts them. Otherwise you get a second set to maintain.
- Build the picked direction in isolation before wiring it in. One workbench page per component, every state visible, checked in both themes.
- Roll out in batches and expect a mixed state while you do. Old and new will coexist for a while. Decide that is acceptable before you start.
The next article takes the same workflow to complex components, where the batch rules stop working.
