I let AI agents check an app against its Figma design and the tickets. Here is the run.

What the agents found on three screens

Finding	Title	Expected	Actual
1F-04	Task circle border is 1 px, not 1.5 px	16x16 circle with a 1.5 px white border on all 4 task cards	Border is 1 px. Size, colour and position are correct, but the circle looks thinner on all 4 cards
2F-05	Search placeholder text starts about 3 px too far right	"Search for your task..." starts at x 72	Text starts at about x 75.5, about 3 px to the right (outside the ±1 px limit)
3F-06	Search bar border is 1 px, not 0.8 px	Border 0.8 px solid #979797	Border 1 px solid #979797, so the border looks a little thicker
4F-07	Design conflict: colour of the "Index" icon in the bottom bar	file.json says the icon is purple #8687E7. design/home.png shows it light grey #E5E5E5	The build uses light grey. The designer must decide which colour is correct. False alarm: my design file was wrong

Monday 5 October, 22:46 to 22:52, Sydney time. Three screens of a to-do app: login, task list, settings. The agents took 6 minutes 21 seconds and wrote 8 findings. 7 were real. 1 was a false alarm, and that one was my fault. Across the three screens there were 12 real problems. The agents found 7 of them and missed the only one a user would notice.

The run on the clockMonday 5 October 2026, Sydney time, from the run's own log

• Planner and reviewer
• Checkers, at the same time
• By-eye check

The by-eye check was done by my developer agent, not a person, before it read anything the QA agents wrote.

Why design QA is still a manual job in 2026

AI in software testing, six surveysPercent, 2025 and 2026, and my guess for 2027

• Survey
• My guess
• Gartner's path: 20% in 2025 to 70% in 2028

See the numbers

Year	Value	What it counts	Source and date
2025	20%	Enterprises with AI-augmented testing tools, early 2025 (70% expected by 2028)	Gartner, quoted by Keysight, 11 Nov 2025
2025	31%	Developers using AI agents	Stack Overflow, 2025 survey (blog, 30 Sep 2026)
2025	37%	Organisations with generative AI in production in quality engineering	World Quality Report 2025-26, 13 Nov 2025
2026	59%	Developers using AI agents, April 2026 pulse survey	Stack Overflow blog, 30 Sep 2026
2026	48%	Run AI agents in production	SmartBear, State of Software Quality and Testing 2026 (Q3 2026)
2026	76.8%	Testing professionals using AI	PractiTest, 2026 State of Testing Report
2027	53%	My guess: a straight line from Gartner's 20% (2025) to 70% (2028)	My guess

Gartner counted 20% of enterprises with AI-augmented testing tools early in 2025 and expects 70% by 2028. Stack Overflow's developers using AI agents went from 31% in 2025 to 59% in April 2026. My 2027 bar is a straight line between Gartner's two points, about 53%, and I would not bet money on it. The bars come from different surveys with different questions, so read the direction and ignore the exact height.

The design check itself is still done by eye: up to 82% of testers still test by hand day to day (Katalon, 2025). And only 21% of designers say developers build their designs pixel-perfect (CollabSoft, January 2025).

One number I do not use is "a bug found late costs 100 times more". The Register traced it in July 2021 to IBM training notes from 1981, and a 2016 study of 171 projects found no steady pattern. What I see on my own projects is simpler. A design bug found after hand-over pulls in the designer, the developer, the tester and the PM. Found during the build, it pulls in one developer.

The three inputs: the ticket, the Figma file, the running app

1 · The ticket (run/tickets/T1.md, part)

T1 — Login screen

As a returning user I want to log in with my username and password, so that I can see my tasks.

2. The Login button is disabled (the faded purple in the design) until both Username and Password have text. When both have text it turns full purple (Primary Color #8687E7) and can be pressed.

4. Wrong username or password: show the message "Incorrect username or password." in the Error colour (#FF4949), 12 px, under the Password field. The Password field is cleared and the Username stays.

I used a free Figma Community file, "UpTodo" by Amir Baghestani (CC BY 4.0), because I will not show client work. My developer agent wrote three tickets the way a PM writes them, with acceptance criteria. Some criteria describe things the design cannot show, like the wrong-password message and the empty search result "No tasks found". One builder agent built the three screens as a small web app in one pass of 5 minutes 37 seconds. I changed nothing in it afterwards. Whatever it got wrong stayed wrong.

On my own projects the ticket and the design are agreed before anything is built, in the blueprint step. A check like this needs something written down to check against.

The design values came from Figma's public viewer, decoded into a JSON file with the same fields the REST API returns. The free plan allows 20 REST calls a month for files and images, and a run with a login needs two.

From ticket text and Figma layers to a checklist

From the ticket

T1 AC2: the Login button is disabled until both fields have text

• L-16Button disabled when both fields are empty
• L-17Stays disabled with one field filled ticket only

T1 AC4: wrong password shows "Incorrect username or password." and clears the Password field

• L-20Wrong login shows the error text ticket only
• L-22Password empty, Username kept after a wrong login ticket only

From the Figma file (T1 AC1: the screen matches the Figma frame)

Layer "Login Screen" 2:12517

• L-01Page background #121212

Layer "Username Fuild" 2:12524

• L-07Username field 327x48, border 0.8 px #979797

Layer "Password Fuild" 2:12528, with "Ellipse 1" to "Ellipse 12", the grey dots

• L-11Password field look when empty: 12 grey dots, report what the build shows comes back later

A planner agent read the tickets and the design data and wrote one checklist per screen: 34 rows for login, 37 for the task list, 25 for settings. Every row names its source, a Figma layer or a ticket line. One row comes back later, L-11: "Password field look when empty. The design shows 12 grey dots. Report what the build shows." The planner also decided two things on its own: 1 pixel of tolerance, and no check of the phone status bar because a web page has none. Both are fair, and a person would still have asked the PM first.

Figma data, Playwright and a pixel diff: how the check ran

1. InputsTicket + Figma data + running app
2. Planner agentChecklist per screen
3. Three checkersPlaywright, screenshot, CSS values, page text, every state Checker: loginChecker: task listChecker: settings
4. Reviewer agentMerge, drop duplicates
5. Report8 findings
6. A person reads itAnd decides what matters

Three checker agents ran at the same time, one per screen, for 2 minutes 12 seconds. Each one opened the app in Playwright at 375 by 812 pixels, took screenshots, read the computed CSS values and the page text, clicked through every state its ticket named, and compared all of it with the design picture and data. A reviewer agent merged the three lists: 8 findings kept, 1 dropped. I did not use the Figma MCP server this time, so the agents never asked Figma for anything during the run.

• Different pixels (red, orange)
• Soft edges (yellow)
• Phone bars, not checked

0.38%login

0.51%task list

0.15%settings

Share of pixels that differ from the design, phone bars left out.

The pixel diff was the least useful of the three tools. Without the phone bars, 0.38% of the login pixels differ from the design, 0.51% on the task list and 0.15% on settings, and most of those pixels sit on the edges of letters. Every finding that mattered came from reading values.

Check type	How the agents checked it	Real findings	False alarms	Missed
Spacing and border width	computed CSS values	4 (F-03, F-04, F-05, F-06)	0	0
Icon drawing	zoomed side-by-side with the design PNG	2 (F-01, F-08)	0	1 (cap and flag icons on the task list, one problem)
Font and line height	computed CSS values	1 (F-02)	0	0
Colour	design data and PNG	0	1 (F-07, bad input)	2 (icons white at 87%, dropped by the reviewer; browser's white password dots)
State and look after an action	clicked every ticket state	0	0	2 (12 dots after a cleared password; orange clear "x" while typing)
Text copy	page text against Figma text	0	0	0
Behaviour from the ticket	clicked and typed in Playwright	14 of 14 criteria passed	0	0

The run, in 90 seconds

There was no screen recording of the whole run. The video is built only from the agents' own browser recordings and their timed transcripts, so it shows what happened and nothing staged.

What the AI design QA missed and what it got wrong

What the agents got wrong

Reported: Index icon colour, "the designer must decide". Cause: my decoded design file missed a colour override.

A checker said: icons are pure white, design is white at 87%. The reviewer dropped it. The checker was right.

What the agents missed

After a wrong password the field is cleared, but 12 grey dots still show. The only medium problem.

The agents' own screenshot. The orange "x" is the browser's clear button; the design has no orange.

White browser dots; the design shows small grey dots.

The borders were the agents' best catch. The builder's CSS says 0.8 px for the input borders and 1.5 px for the task circles. Chrome rounds border widths and draws 1 px. The code looked right, the screen was wrong, and only the computed value shows it. The by-eye check missed all three.

The miss that bothers me is the password field. The design shows 12 grey dots in the empty field as an example value, and the builder copied them as a placeholder. After a wrong password the field is cleared, as the ticket asks, but it still shows 12 dots, so a user thinks the old password is still in there. The planner wrote a checklist row for exactly this. The checker compared the field with the design picture, saw the same dots, and stopped. It never put the picture and the ticket line together. This was the only medium problem of the run.

Two more misses sit in the agents' own screenshots: an orange "x" in the search box while typing (the browser's own clear button, in a colour this design does not have) and the browser's white password dots. The checkers tested what each state does and never looked at how it looks.

One correct finding was thrown away. A checker reported that the settings icons are pure white where the design uses white at 87%. The reviewer called it soft edges in the PNG and dropped it. Figma's data says the checker was right.

The one false alarm was mine. My decoded design file left out a colour override on one icon, so the file and the picture disagreed. The agent wrote "the designer must decide" instead of calling it a bug, which was the right caution on bad input.

Agent QA vs a by-eye check: time, findings, cost

Agent team against the by-eye checkOne app, three screens, one run

• Agent team
• By-eye check (my developer agent, not a person)

QA run US$3.31 at API list price, builder US$1.46. Real spend A$0 (flat subscription).

For a baseline, my developer agent did the same check by eye, design next to app, tickets open, before it read anything the QA agents wrote. It is an AI agent, not a person, so its 4 minutes are not a person's minutes, and I did not time a person. By eye it found 6 real problems and missed 6, all small value differences like border widths. The agent team found 7 and missed 5. Both found the same 2 wrong icons. Together the two lists cover 11 of the 12. The one neither has is the icon brightness finding the reviewer dropped.

The QA run cost US$3.31 at API list price. I pay a flat subscription, so my real spend was zero. The builder cost another US$1.46. This is one app, three screens, one run, a web build, one model, and I would not draw a trend line from it. When I join a team as lead engineer this is the kind of check I set up in the first week. A first run usually has gaps like the ones below, and I fix them in the second run.

Design QA vs visual regression testing vs agents

Tool or method	Compares with Figma	Checks the ticket	Needs a baseline	A person decides	Price (public pages, Oct 2026)
Pixelay (Figma plugin, overlay on a live URL)	yes	no	no	yes, by eye	see site
Applitools Eyes Figma plugin	yes, Figma frames as baselines	no	the Figma frame	yes, in review	see site
Chromatic Storybook Connect	per component, linked stories	no	Storybook story	yes	see site
Uiprobe	yes, CSS values against Figma	no	no	yes	free tier 3 runs; Pro about US$39 a month
TestMu AI SmartUI (agent skill)	yes	no	no	yes, approves	see site
Quell	Figma flows, no visual diff	yes, from Jira or Linear tickets	no	yes	from US$19 a month
Figma AI design QA agent (beta, 20 May 2026)	design file only, never the app	no	no	yes	part of Figma
Agent team, this run	yes, data and picture	yes	no	yes, reads the report	US$3.31 at API list price for 3 screens

Figma's own AI design QA agent, in beta since 20 May 2026, checks the design file for spacing and design-system rules and never sees the built app. The ticket check is the part none of these tools do, and it is where the one medium problem in my run lived. It is also the first thing I look at when a team asks me to fix or finish an app whose screens do not match the design.

What I change next time

1. Give the checkers the real Figma values through the REST API or the Figma MCP server instead of my decoded file. That removes the false alarm and the dropped finding.
2. Tell each checker: for every state the ticket names, take a screenshot and compare how it looks as well as what it does.
3. Tell the reviewer it may not drop a finding without checking the design data itself.
4. Ask the planner to list its scope choices at the top of the report, so the PM sees "status bar not checked" before the findings.

The next run is the same app with these four changes. The number I want to move is 5 missed out of 12.