Earlier arcs in this series took a feature from research through design into delivery, and this arc is about what comes back after implementation. What I have not shown is what to do when that review is bigger than one person can work through. When I release something big, the presentation and the code both come back with problems, and on a feature of any size there are more of them than I can list. So the review is the part I stopped doing myself.
I deliver to a staging environment first. Production exists as well, and at the time of this run it was still tied to staging rather than fully separated from it. The app had no users then, so a broken screen mattered less than it would once it hit the real app environment. It has soft launched since, which raises the stakes on exactly this loop.
The surface I was reviewing
Fiuto’s product loop runs onboarding, then study creation, then study results, then study analysis. A study is the test you put in front of respondents. An analysis is what Fiuto writes from those responses, and it is the same object the research arc called an insight. I was working on the analysis end of that loop.
I can generate an analysis from any study that has respondents. The overview sits across studies, so with three of them I get one cross-study view of what they say together. All the data in these studies is synthetic. It is there for testing.
Inside a single analysis there is a summary under the title, a few items carrying the main findings, a full analysis page, and a deck. The deck is what I had been working on the day before, and it was not working well. It rendered stretched vertically. Editing it failed. There were so many bugs I could not start to list them.
Why I could not review it by hand
Reviewing that implementation myself would have taken days, and the reason is the shape of the feature. The deck is not generated inside the app. A separate repo generates the slides, and that repo uses its own package to build the decks.
So one visible defect can come from the analysis data, from the report repo, from the package, or from the rendering, and I would have to work that out for every bug in a list I had not even finished writing.
The swarm
What I did instead was tell the build orchestrator about the issues. The build orchestrator is a skill my coding agent loads to run a feature from brief to ship, and a skill here is just a written procedure the agent reads and follows. It already knows the repos and the conventions, and it knows how to fan work out to other agents.
Then I had it create a swarm of QA agents to work through the issues.
One agent went first and mapped the full journey, from generating an analysis through to opening and editing the deck. Ten agents then worked from that map, each reviewing a different aspect of the deck implementation, all of them reviewing visually in a Playwright browser rather than reading source and inferring what it would render.
That last part matters. A deck stretched vertically does not exist in the code. It only exists on screen.
What came back
They returned one consolidated report.
It was not only a list of generation problems. It reported what had been checked and how each check went: three validation failures, 15 successes. It calculated the cost of the run. That was valuable to me because the next piece of work at the time was modelling the cost of each AI feature. And it produced the full list of bugs they found.
Ten agents in a browser, plus one mapping the journey before them. That would have cost me days to do personally, and it would not have been as specific as the agents were.
From report to tickets
Once I have the report, I turn it into a project. An agent maps the source first, so each bug is pinned to the code that produces it, and then decomposes the list into tickets in a Linear project. An implementation agent picks that project up and works through them. That run was still going when I recorded this, so I have no outcome to report on it.
This is how I use agents to curate the implementation visually.
Running this on your own repo
You need a coding agent that can spawn other agents and drive a browser. Nothing here is specific to Fiuto.
- Point the review at a surface, not at a codebase. Name the user-visible journey you want checked, from the first click to the last, and let the agents find whichever repo produces each part of it.
- Map the journey with one agent before you review anything. Have it walk the flow and write down every screen, state, and action. That map is what the reviewers share, and it is the reason ten of them do not all check the same button.
- Split the map into aspects and give each aspect its own agent. Layout, generated content, interactive controls, error and empty states, whatever the surface has. Let the aspects overlap, because a gap between two of them is a bug nobody was asked to look for.
- Require a real browser. Playwright or equivalent, with screenshots at each step. An agent that reads the source instead will report the code as correct, and on a visual bug that tells you nothing.
- Fix the report shape before the run, not after. Ask for a check, a verdict, evidence, and a severity per finding, plus counts of what passed and what failed. Ten agents writing freely gives you ten formats to reconcile by hand.
- Ask for the cost of the run. You want the price of the review next to the hours it saved, and if you are shipping AI features you will need that number again later.
- Read the consolidated report yourself. This is the step that stays human. The agents found the bugs, and you decide which ones are worth fixing now.
- Use one agent to decompose the report into tickets and a different one to implement them. Keep the source mapping in the decomposition step so each ticket already points at the code it touches.
- Re-run the same swarm after the fixes land. The journey map and the aspect split are already written, so the second pass costs you a prompt.
That closes this arc, which is about what happens once the feature already exists. It is also the last article in the series.
