A print shop dashboard gave us the clearest reason to retire our paid kit. Our repair command accepted a stylesheet change. The dashboard, queue and settings pages still worked. Both viewport sizes passed the independent action checks. Then we looked at the pages as a reader would. The stylesheet had hidden the section containing the main heading on every screen. The reviewer had left the hierarchy grade at C before and after the change. A capable person could have rejected the work by asking a simple question. What happened to the name of the page?
We built Unvibed for people whose agent-built apps already did something useful. Their invoice filters worked. Their booking forms saved a reservation. They wanted the interface to communicate the product as clearly as the implementation carried out the task. We thought a well-specified procedure could bridge that gap. We wrote the procedures, built an executable around them, and gave the ordinary coding agent a fair chance to beat both. We are keeping the results public because the failed attempts explain the service we now offer.
The portfolio exposed a design problem
Our first five examples looked like cousins. A coffee landing page, billing dashboard, chat tool, mobile feed and client portal all had cream backgrounds, serif headings, deep green and a rust accent. Seen individually, each screen looked more deliberate than its starting point. Put them side by side and a different story emerged. We had replaced one recognizable template with another. The portfolio mostly showed that someone liked the visual conventions of a small print studio.
A billing operator needs to scan amounts, distinguish paid from overdue invoices and decide whom to follow up with. A reader in a conversation needs to know which thread they are replying to and what information the answer refers to. A coffee buyer wants to understand what an 18 gram dose will produce. The same palette can serve all three. It takes a different arrangement of information to answer each question. Our recurring display type and large introductions occupied space where a useful piece of product evidence could have been.
We wrote eight named directions with different rules for type, density, components and motion. We rebuilt the five examples around distinct product tasks. We also wrote down forty observations about real interface patterns, with sources and credits. This gave the agent more concrete choices. It also gave us better questions to ask of its output. Opening the portfolio comparisons lets you inspect these agent-built demos at both widths. Their captures show edits to fictional apps. They tell you how those demos changed and say nothing about a customer’s conversion rate.
An instruction sheet had to beat a competent agent
Our early benchmark generated a page in one pass. On eighteen development pairs, the procedure won thirteen, tied or split four, and lost one. We had used that set to improve the procedure. On a fresh three-task confirmation set, there was one result of each kind. Neither set reproduced how a customer works in a repository. Real components share styles. A local fix can hide a heading on another route. A static picture also cannot tell us whether an apparently usable button still saves anything.
We started ten actual Next.js apps from the same sources on both sides. The first five came from our demos. The other five covered settlements, training, developer documentation, a marketplace and booking. We gave both editors the same opportunity to render desktop and phone views, inspect the result and try another repair. We changed which instruction kit they received. After editing, an independent observer exercised a named action on each app and captured the final screens.
A judge saw the two final designs without their treatment labels. It saw them again in the opposite order in a fresh call. It also saw the other nine products made under each condition so that a repeated house style would count against a design. Both calls had to favor the same side for a stable win. The instruction kit won once. The plain agent won six times. Three pairs were unresolved. The mean preference toward the kit was 3.35 on a seven-point scale, with four even. The result gave us little reason to charge for the procedures.
We put the whole repair loop on trial
We had another question. Perhaps the useful work was starting the app, capturing two widths, reading the audit and restoring a bad edit. A customer making one ordinary request might benefit from automating all of that. We turned the harness into a CLI and tested that specific comparison. One side got a single request to make the app look like a real product. The other ran the paid command with the same model on the same starting app. The paid command could choose a direction and take up to three repair rounds.
With gpt-6.1-sol, fix won four apps, lost four, and had two unresolved outcomes. Its mean was 3.95. Our decision rule, written in advance, required seven stable wins, at most two stable losses, a mean of at least 4.75 and twenty passing action checks. The loop did meet that last condition. Five runs restored the starting interface after a regression. In four of those, a previously graded dimension became Unverified or N/A. The command had lost comparable evidence, which could stop an edit even when nobody had established that the screen looked worse.
An actual regression could also slip through, as the three missing print shop headings showed. That was a separate three-route test, outside the ten comparison pairs. Inspecting its before and after views explained why the rubric was too weak for that decision. Existing controls still worked when their introductory section disappeared. The user returning from another page, however, lost a useful landmark. A browser script that tabs to the first control never has to ask where it is.
The smaller model mostly kept what it started with
For the final experiment we changed the editor on both sides to gpt-5.6-luna, an older lightweight model available in the same account. We kept the ten apps, the original screen sizes, the judge and the decision rule. This time fix won five pairs and lost five. Its mean was 3.90. The paid loop passed twenty of twenty fixed action checks. Bare passed ten of twenty. Read those two observations alongside the source changes. Bare edited all ten apps. Fix retained an edit in just one, the developer docs.
Six paid runs stopped with no verified next edit. Two reviewers attempted a prohibited tool. One editor proposed invalid JSX. One candidate regressed and was rolled back. The five pairwise wins included four cases where the judge preferred the unchanged starting interface. Where both weak outputs passed the fixed actions, the ordinary agent won every pair. Where the weak bare output missed an action, the paid side won every pair. A concrete behavior check influenced the evidence available to the judge, and a largely unchanged app had many opportunities to preserve its behavior.
We checked the meaning of a missed action, too. A booking script looked for a particular select control. In a separate replay, the tester could choose the available 14:00 time through equivalent controls and get a confirmation. We kept that observation out of the ballots and left the original counts intact. A failed selector describes exactly what the automated observer could do. It takes another check to establish what a customer could do. One weak bare booking request also hit its seven-minute limit. Its single permitted retry supplied the scored result.
Could the loop make a lighter agent as good as a stronger one?
Two separate within-model scores cannot answer that question. We compared the exact lightweight paid screenshots directly with the archived strong bare screenshots, including the strong agent’s broken documentation app. The strong bare agent was preferred on seven apps. Weak paid was preferred on three. The mean toward weak paid was 3.25. All three exceptions came where the strong bare action script failed. Its portal and booking tasks worked through equivalent controls on a second check. Its documentation page really did fail to compile.
Taking just that docs pair out of the recorded totals leaves two lightweight paid wins, seven strong bare wins and a mean of 2.83 toward weak paid. We published the full ten. There was one generation per arm per app and a single judge family. We did not run a human preference panel or a controlled trial of designers. The benchmark includes the paired renders and ballots. The full report with the final model table keeps the different comparisons separate and explains what was exercised and judged.
What the designer takes responsibility for
On a rescue, a designer has to decide what the screen is for before asking an agent to change it. In the print shop example, that means naming the next production decision, keeping the queue heading visible and retaining the job facts an operator compares. We can give an agent a narrowly specified change, look at the rendered result on the original fixture, and reject it when a useful landmark disappears. The person making that decision can explain which problem was worth fixing and which working parts were worth keeping.
That responsibility changes the delivery itself. A customer can open a PR and see one screen’s change beside its original state. A Lovable or Bolt user can apply the corresponding prompts to a duplicate and compare real captures. DESIGN.md records the choices that matter when somebody extends the product later. On a six-screen job we also deliver instructions for the next coding agent. The designer signs off on the working flow, the visual hierarchy and the handoff. Our experiments motivated that arrangement. They did not measure a performance advantage for a human-reviewed service.
We retired the paid kit. If you have a working app and want a place to start, the free audit gives you the screen, the grade, the reason and the checks the reviewer could not verify. Take one finding to the actual product. Try the action on a phone. Ask what information you needed to make the next decision. That is a better starting brief for a rescue than a request to make everything look finished.