The bottleneck moved from making to reviewing
Agents can produce components faster than any team can look at them. The new craft is building the checks that make review fast, automatic, and hard to skip.
The review plan for this site starts with a phase that fixes no product bugs at all. On 2026-10-21 a full-codebase review filed 136 GitHub issues, and the plan written to work through them begins with Phase 0, which makes the checks trustworthy, since every later phase relies on lint, typecheck and tests. Two items in that phase describe checks that had stopped telling the truth: lint that exited 1 on noise from agent worktrees and sync folders, and browser-backed test suites that skipped when a browser was missing instead of failing. A check that is always red teaches people to ignore red, and a check that skips quietly reports a green it has not earned, so the first job of a review loop at agent speed is making sure what it reports is true.
A screen used to take a week to build and an afternoon to review, and every process a design team runs (critique, QA, sign-off) was sized around that ratio. Agents cut the build to hours while the review took the same afternoon it always had. The queue of unreviewed output grows quietly until someone finds three slightly different versions of the same card in production and nobody can say who approved any of them, and the remedy is to move review into the system, so a person only looks at what a machine could not judge.
Output outruns attention
The uxdesign.cc guide to agentic design systems says agents can generate components faster than teams can review them, which causes drift and unclear ownership, and that tests confirm function without confirming visual fit, so designers have no closed review loop. Figma's post on design systems and MCP adds that only 32% of designers and developers trust AI-written code.
Checks that read the output for me
Moving review into the system means a check reads the output the way a reviewer would and reports what it found in words that tell the reader what to fix. VUI Checker, the Figma plugin I built to validate conformance with Verdant UI, caught a detached or overridden component that looked right by eye. A reviewer comparing the frame to the system sees the same pixels either way, and the plugin reads the instance and reports that it no longer follows the component, so the miss surfaces while the file is open and before anyone has built on it. A person would need to click into every instance to find that, and at agent volume nobody does.
Where a person still looks
Some questions have no automated answer. Whether a screen feels right, whether a spacing rhythm holds, and whether the thing should be built at all stay with people, and the uxdesign.cc guide notes that qualities like shadow weight are hard to encode in tokens. Protect that attention by making the human step cheap: a side-by-side render, a diff against the last approved state, and a short list of what to look at. A review that takes thirty seconds happens every time, and one that takes twenty minutes gets skipped. Every generated component needs a named owner as well, because unclear ownership is one of the two consequences the guide flags and naming a person costs nothing. When an agent gets the same thing wrong repeatedly, change the rule file, the token or the component that misled it; evaluating AI-generated UI covers judging a single output, and this is the same habit at volume.
Craft moves downstream
A growing share of design craft is the design of the checks: deciding what on-system means precisely enough to test, deciding which visual qualities deserve a human eye, and writing the failure message so whoever reads it knows what to fix.
Be the first to rate this article.
Let's work together.
Open to select projects and collaborations — design systems, accessibility, and AI-native product work.