A workflow for reviewing AI agents' UI work

Line-Item Review

When an AI agent makes dozens of UI changes on one branch, I review them one at a time. Each change has a name and a reason, I can see it in the running app, and I keep or drop it on its own.

Made with Claude Opus 5.5. The workflow and the results are mine. Claude Opus 5.5, Anthropic's AI model, wrote this page and built the demo site, its screenshots and the example data, working from my notes and feedback.

The review tray on a demo site. C-005 is selected, so the six “Place hold” buttons it added are outlined, and the agent's explanation sits alongside.

The problem

Coding agents are good at UI work, and they are prolific. Ask for a redesign and you get back a branch with fifty or eighty changes: spacing, copy, layout, new components, removed ones, a reworked form.

Reviewing that branch leaves two bad options. You can accept or reject the whole thing, which throws away good work along with the bad. Or you can read the code diff, which is slow and still doesn't show you what each change looks like or why the agent made it.

I wanted a third option: see every change in the running app, understand it in plain language, and decide on each one separately.

How it works

The agent keeps a change catalogue

Every change the agent makes gets an entry in one file, such as review/changes.json. Each entry has an ID, a title, a plain-language note on what changed and why, the pages and element it affects, the commits that make it up, and the other changes it depends on.

{
  "id": "C-005",
  "title": "“Place hold” button replaces the Hold link",
  "what_why": "The small “Hold” link did not look clickable,
               and testers missed it. It is now a button
               that says what it does.",
  "pages": ["catalogue", "book"],
  "element": "[data-ch~='C-005']",
  "commits": ["9c41e07"],
  "depends_on": ["C-001"],
  "live_preview": true
}

The entry behind the screenshot at the top. The agent writes each entry as it works, so the reason is recorded when the decision is made.

A review tray inside the app

The preview build of the app gets a review tray. It's off by default and never ships to production. Open it on any page and it lists only the changes that touch that page. Click one and the app outlines the affected elements and shows the agent's explanation next to them.

The catalogue already lists each change's commits, so the card can also show their git diff. The plain-language reason and the code that implements it sit on the same card.

A book page for Middlemarch with the note about the hold queue outlined in amber. The review panel explains change C-012. — On the book page the tray lists the 12 changes that touch it. C-012 added the note about the hold queue, so that box is outlined.

The change card for C-005 with its git diff open: HoldButton.tsx swaps a link for a button inside a form, and a new buttons.css file adds the button styles. — The card for C-005, with its git diff open.

What each change card shows

The ID, and whether the change can be previewed live
A title and a plain-language note on what changed and why
Where the change came from, and its commits
The git diff for those commits, folded away until you open it
A Show without switch, or the reason there isn't one
What the change depends on, and what depends on it
Keep, Drop or Undecided, with an optional note

Keep or Drop, one change at a time

Each change is marked Keep, Drop or Undecided. Where it's feasible, a Show without switch puts the element back the way it was, in place, so I can compare before deciding. Dropping a change takes it off the page right away, so the preview always shows the result of the decisions so far. Changes that can't be previewed live say why. Decisions are saved on the server with notes, and they can be exported.

Search results shown as cards with covers, outlined as change C-006. — C-006 turned the results table into cards. Flip the switch to see the page without it, the same way the tray's own switch works. It's only a preview until you choose Keep or Drop.

The same search results shown as the old table, with the review panel's switch turned on. — C-006 turned the results table into cards. Flip the switch to see the page without it, the same way the tray's own switch works. It's only a preview until you choose Keep or Drop.

The redesign with C-002 kept: headings in a book serif and 16px body text. — Choose Drop for C-002 and the page goes straight back to the old 13px Verdana. The rest of the redesign stays, because only that one line item was dropped.

The same page with C-002 dropped: every heading, label and button is back in 13px Verdana, and the build bar lists C-002 as dropped. — Choose Drop for C-002 and the page goes straight back to the old 13px Verdana. The rest of the redesign stays, because only that one line item was dropped.

The book page with the Place hold button outlined. The review panel says live preview is not possible for change C-016 and explains why. — C-016 changes what happens after a click, so it can't be shown in place. The tray says so and points to the two servers instead.

Stable and redesign, side by side

Two copies of the app run at the same time on separate local ports: the last stable version and the agent's redesign. With one on each monitor, I can click through the same flow in both. This covers the changes the tray can't preview live, and it shows the overall feel of the redesign, which no single line item does.

The stable build: a navy header, a small search box and a plain results table. — The same search on both builds. The stable build is untouched; the redesign carries all 17 catalogued changes.

The redesign: a large search field, format filters, result cards with covers, and an events strip. — The same search on both builds. The stable build is untouched; the redesign carries all 17 catalogued changes.

A clean rebuild with only the kept changes

Once every change has a decision, the agent doesn't edit the redesign branch. It starts a fresh branch from the stable tag and applies only the kept changes, in dependency order, with tests. Nothing merges until I've reviewed the result and merged it myself.

The review panel's summary: 14 changes kept, 3 dropped with notes, and a numbered rebuild plan that starts from the stable tag. — The tray's summary once every change has a decision.

What the rebuild gives you

Dropped changes never enter the new branch, so there is nothing to revert.
Dependencies are in the catalogue, so a kept change that needs a dropped one is caught before the rebuild starts.
The reasons for dropping travel with the decisions. Here, three changes left out, each with a note.
The result is an ordinary pull request, and a person merges it.

How it has held up

84 changes catalogued in one app; 48 of them could be previewed live in the tray

76 changes catalogued in a second app

At that size, reviewing the whole branch at once isn't realistic. With a catalogue, each decision is small: one change, one page, one reason.

Why it's worth the setup

Every change the agent makes is named, explained, traceable to its commits, and individually vetoable.

Review happens where the change is visible, in the running app instead of the diff.
Good work survives bad work. One unwanted change no longer sinks the other eighty.
The catalogue becomes an audit trail. Months later you can still see what the agent changed, why, and who approved it.
A person stays the merge gate. The agent proposes and rebuilds. I decide and merge.

Trying it yourself

Start with the catalogue alone. Ask the agent to record every change as an entry with an ID, a plain-language reason and its commits. That one file already makes review faster. Add the tray, the side-by-side servers and the rebuild step as the volume of agent work grows.

The screenshots on this page come from a small demo site you can click through.

Open the demo site Open its stable build

Wrenfield Library is made up. It has 17 catalogued changes and a working review tray, and the decisions you make there stay in your browser.

How this was made

This page, the demo site and everything in them were made with Claude Opus 5.5 in Claude Code.

From me: the workflow itself, the numbers from my two apps, and feedback during the build, such as showing the git diff on each change card and making dropped changes revert on the page.
From Claude Opus 5.5: the writing, the page design, the Wrenfield Library demo and its review tray, the mock code diffs, the example catalogue, and the screenshots, which it took with headless Chrome. It also clicked through the demo in a browser to check that it works.