Critique, Quality Gates, and Limits

This is the closing module, and it carries the part of the workflow that most teams skip: the structured review between a plausible first draft and the decision to ship. The earlier modules made the input better — clearer briefs, a harness that carries the durable rules, artifacts the agent can actually read. None of that removes the need for review; it just makes the review worth doing, because the draft arriving at the gate is close enough to be improved rather than discarded.

Frame the module around one claim and keep returning to it: critique is where the quality comes from. Agents produce output that is plausible by default, and plausible is precisely what makes unreviewed work dangerous — it reads as finished while carrying invented props, generic patterns, missing states, and quiet scope creep. The gates exist to catch those before a stakeholder does.

Flag the structure up front. The first half of the module is technique: visual QA, critique dimensions, executable checks, anti-slop rules, and the failure modes they catch. The second half is honesty and closure: what agents still cannot do, the ship checklist, the return to the Module 1 exercise, and where the curriculum goes from here. Both halves matter; a team that learns the techniques without the limits oversells the workflow and gets burned.

The core argument here comes straight from the visual QA article: a type check and a code review cannot see hierarchy, rhythm, density, or a layout that collapses at phone width. The diff looks reasonable, the page loads, and the design has still failed. Visual QA closes that gap by giving the agent — and the human reading its findings — actual evidence: screenshots at fixed viewport widths, an accessibility snapshot of the rendered page, the output of automated checks, and a short restatement of what the page was supposed to do.

Two disciplines carry most of the value. First, fix the widths and never change them between runs; the moment every review uses different viewports, findings stop being comparable and the second review cannot tell you whether the first fix worked. Second, require every finding to name its evidence — the file, the viewport, the axe rule. Findings that cannot name evidence are either judgments, which is fine if labeled, or guesses, which get sent back. That single rule is what separates a fix-ready report from another vague to-do list.

Name the boundary explicitly: visual QA is a review activity, not a license to change the UI. Capable agents will helpfully fix their own findings the moment they produce them, and at that point taste decisions are being made silently inside a diff. The findings get prioritized, a human approves the fix plan, and only then does anything change. Mention also the practical caution from the article — full-page screenshots pasted into chat are extremely token-expensive; keep evidence on disk and let the agent read files or crops.

This table is the working core of structured critique. The failure mode it prevents is the vibe check: ask an agent for general feedback and you get general taste language — clean, modern, needs polish — which nobody can act on. Naming the dimensions turns the critique into inspection: for each dimension there is a question to answer and evidence that settles it.

Walk one or two rows properly rather than all five quickly. Hierarchy is the highest-value one, because it is the dimension agents most often get subtly wrong — the components are right, the order of emphasis is not. States is the one agents most often simply omit; the happy path gets built and the empty, error, and disabled states quietly do not exist until someone asks. Accessibility is the row where automated evidence and human judgment have to share the work: axe settles contrast and labels, a keyboard walkthrough settles whether the focus order makes sense.

Two rules from the critique-loops article belong on top of this table. First, severity by user impact: blocker, important, polish, question — and never by how easy the fix looks, because that is how trivial cosmetic fixes crowd out cheap but important ones. Second, separate observable mismatch from design judgment. A missing aria-current is a mismatch; whether the display type scale earns its cost on small phones is a judgment call that goes to a human. A review that contains only one kind has usually been filtered; the honest mix, clearly labeled, is what a designer can act on. Finally, the dimensions should flex with the artifact — a checkout flow adds trust and recovery, a dashboard adds scan path and table behavior. The table is a starting set, not a universal checklist.

The principle is leverage: a correction you make in conversation fixes one run; a correction you encode as a check fixes every run after it. The categories on the slide map to real tooling rather than aspiration. Token audits are simple searches — raw hex values, rgb and hsl literals, arbitrary spacing values, semantic-token bypasses — and this site runs exactly that as a script. Type checks catch the single most common implementation failure in agent output: an invented prop or a variant the component never had. Structural verify scripts enforce the boring contract — required fields present, naming conventions followed, files in the right place. Accessibility audits run axe-core or pa11y against the rendered route, which catches contrast, missing labels, and landmark problems mechanically.

The order of operations matters as much as the checks themselves: the agent runs them on its own output before a human reviews anything. That changes what arrives at the review gate. Instead of spending your attention noticing a hardcoded color, you spend it on whether the hierarchy serves the job — the thing only you can judge.

Be equally clear about what executable checks cannot do. A clean axe report is a floor, not a ceiling — it cannot tell you whether the focus order makes sense or the alt text is useful. A passing token audit cannot tell you the design is any good; it can only tell you it is consistent with the system. Each gate catches what it encodes, and only the human catches the rest. That sentence is the bridge to the next two slides.

Define slop precisely, because the word gets used as a sneer and it is more useful as a diagnosis: slop is the centre of the training distribution arriving in your product. Purple gradients, generic SaaS hero layouts, emoji bullets, marketing bands with invented calls-to-action — these are not random errors, they are the most statistically common answers to underspecified requests. That is exactly why they respond to rules: the agent is not failing to follow your direction, it is filling the gaps you left with the public web's average.

The practical move is to name the patterns your team keeps rejecting and write them into the harness as explicit prohibitions — no gradient backgrounds, no emoji in interface copy, no marketing-style bands on product pages, no calls-to-action that do not exist in the product. Naming matters: a rule that says avoid generic design does nothing, while a rule that names the pattern gives the agent something it can actually check itself against. The Module 1 worked example showed this concretely — the unbriefed run produced a marketing band with a gradient and an invented CTA precisely because nothing said not to.

Then push as many of these rules as possible from prose into checks. A no-raw-colors rule can be a token audit. A contrast rule can be an axe assertion. A no-emoji rule can be a lint pattern. The ones that stay prose — tone, layout genre — still earn their place in the harness, because the agent reads them on every run and your reviewers stop having to repeat them. This is the anti-slop layer of the quality-gate pipeline on the next diagram.

This table is the module's argument made operational: recurring failures are not reasons to distrust the workflow, they are inputs to it. Each row names a failure that shows up repeatedly in real agent output and the gate that catches it at its cheapest point.

A few rows deserve commentary. Invented props is the canonical example of why the agent runs the type check on itself — the failure is invisible in review because the code reads plausibly, and trivially visible to the compiler. Quiet scope creep is the one that surprises people: the agent helpfully refactors a neighbouring component, renames a prop for consistency, or restyles a screen it was never asked to touch, and the diff balloons. The catch is procedural, not technical — the plan review states the scope, and the diff review flags any file outside it. Token and system drift is the audit story from the design-system audits article: drift is usually quiet, it starts as one raw color or one copied component, and an agent-run audit finds it across the whole surface faster than any human sweep.

Close on the meta-pattern in the highlight: mechanical failures belong to executable gates, judgment failures belong to critique, and scope failures belong to the plan review from Module 2. If a failure keeps recurring and no gate catches it, that is not bad luck — it is a missing rule, which is the subject of the harness-update slide coming shortly.

Walk the pipeline left to right and name the ownership of each stage, because the colors on the diagram carry the argument. Generation is agent-run and produces something plausible — which is the problem the rest of the pipeline exists to solve. The executable checks are the automated gate: token audit, type check, lint, accessibility audit, all run by the agent on its own output, identical on every pass. Visual QA is agent-run but human-read: the agent captures screenshots at fixed widths, compares them against the stated intent, and writes prioritized findings; a person reads them before anything changes. Structured critique is human-led — the named dimensions from earlier in the module, with severity by user impact and judgment calls separated from mismatches.

The harness update is the stage teams skip and the one that compounds. When the same finding shows up twice, it stops being feedback and becomes a rule — in the harness as prose, or better, as another executable check. The dashed line back to generation is the point of the whole diagram: each loop through the pipeline should make the next loop's first draft better, because the harness got stricter. A team whose critique never reaches the harness gives the same feedback forever.

The ship decision stays human, full stop, and it is worth saying why even when every check passes: the checks verify what was encoded, and nobody has encoded whether this is the right thing to ship. That judgment is the accountability the Module 1 'what stays human' slide promised would not transfer.

Resist the temptation to soften this slide, because the credibility of the whole course rests on it. The limits listed are not edge cases; they are structural, and the workflow taught in this course is shaped around them rather than in denial of them.

Take them in turn. Ambiguity: an agent does not flag a vague brief and wait — it fills the gap with the statistically most common answer and presents it with full confidence, which is exactly the slop mechanism from earlier. Organisational politics: the context that decides many design calls — who owns this surface, what failed last year, which stakeholder needs to be consulted before the navigation changes — never appears in the repository, so the agent cannot weigh it. Novel taste: agents are interpolation machines; they produce competent versions of things that exist, and a genuinely new direction still has to come from a person with a point of view. Long-horizon consistency: quality drifts over long sessions and across sessions, which is precisely why the harness exists — it is the memory the agent does not have. And knowing when to stop: the screenshot-iteration plateau from the visual QA work is a small example of a general truth — improvement flattens after a few rounds, and past that point more iterations produce churn, not quality.

The field is moving — canvases opening to agents, design systems becoming machine-readable contracts — but the public evidence says the human-approval ceiling is holding: agents propagate and verify; humans approve, decide, and own taste. Plan on that division continuing, and treat anyone selling full autonomy on these dimensions with suspicion.

This is the artifact participants should leave the course with, so present it as a starting point to edit rather than a standard to obey. The seven items deliberately mirror the pipeline: the first two are the automated and agent-run gates, the middle three are the human review, the sixth is the harness update, and the last is the decision. If a team's checklist diverges from their pipeline, one of the two is fiction.

A few items reward emphasis. No open P0 or P1 is the stopping condition borrowed from the visual QA workflow — polish-level findings can ship as logged debt, hierarchy and task blockers cannot. Judgment calls logged with an owner is the anti-pattern guard: the alternative is the agent quietly resolving taste questions inside a fix pass, which is how a product's design direction changes without anyone deciding it should. Scope held is the cheap defence against quiet creep — a one-line check of which files changed against what the brief named.

The sixth item is the one that makes the checklist compound rather than just gate: every shipped piece of work should leave the harness slightly stricter than it found it. And the last item is deliberately phrased as a person deciding, not a status flipping — it is the accountability thread that runs from Module 1 to here. Encourage teams to keep the list to roughly this length; checklists that grow past a screen stop being run.

This slide closes the loop the diagram drew with its dashed line. Module 4 built the harness; this slide is about what keeps it true. The operating rule is simple enough to be memorable: twice is the threshold. The first time you give a piece of feedback, it is critique. The second time, it is a missing rule — write it into the harness, or better, turn it into a check the audit runs. Teams that skip this step experience the most demoralising version of agent work: giving the same feedback forever, to a collaborator that genuinely cannot remember it.

Two refinements keep the practice honest. Record approved exceptions alongside the rules — the design-system audit work makes this point sharply, because an audit that does not know a variation was intentional will keep flagging it, and eventually someone 'fixes' a deliberate decision. And prune as deliberately as you add: a harness that accumulates stale rules, contradictions, and restated documentation stops being trusted, by the agent and by the team. The instruction file is a design system for agent behaviour, and like any design system it rots without maintenance.

The last bullet is the cultural one: a decision that lives only in a conversation is a decision the next session never heard. Conversations are where decisions get made; the harness, the DESIGN.md, and the checks are where they get kept. That is also the honest answer to the long-horizon consistency limit from two slides ago — the consistency does not come from the model, it comes from the file.

This exercise is the course's full circle, so frame it that way. In Module 1 participants sketched a task on paper before they had touched an agent — the brief, the gates they would hold, what could go wrong. In Module 3 they wrote the brief properly and ran it. This retrospective takes that same artifact and pushes it through the full pipeline: executable checks, visual QA at fixed widths, structured critique with evidence and severity, a harness update, and a personal ship checklist.

The deliverables to insist on are the comparison and the checklist. The comparison against the Module 1 page is where the learning becomes visible: most participants find their original sketch named the right gates but wildly underestimated how much of the quality work could be made executable, and overestimated how much the agent would get right unprompted. The personal ship checklist matters because the one in this module is a default, not a doctrine — editing it forces a decision about what their context actually requires. The constraint of changing no more than three items is deliberate: it keeps the checklist short and the editing honest.

If running this live, the discussion question that produces the best conversation is the harness item: what single rule or check, added today, would have saved the most correction across the whole course's exercises? The answers tend to be small, specific, and immediately reusable — which is exactly the habit the course is trying to leave behind.

Keep this slide practical: the goal is to route people to the right next course, not to advertise all of them. The honest framing is that this course taught the loop and the next courses each deepen one part of it. Claude Code for Designers is the tool-depth course — for people who picked their platform and now want fluency: session habits, skills, MCP connections to canvases and browsers, and the daily mechanics this course deliberately stayed above. Design Systems for Agents goes deep on the harness side: tokens, component inventories, anti-patterns, and audits — the work of making a design system legible to machines, which the field-notes article argues is the lowest-regret investment a team can make this year because it pays off under every version of where the tooling goes. Agentic Prototyping is the speed course: prototype-first workflows that get from a brief to something testable in a session, kept deliberately separate from production code.

The selection heuristic in the highlight works in practice: pick by the nearest bottleneck. If the agent sessions themselves feel clumsy, take the platform course. If output keeps drifting from the system, take the design-systems course. If the team's problem is getting ideas in front of users fast enough, take the prototyping course.

Close with the reassurance that matters given how fast the platform layer churns: everything from this course — the brief, the harness, the critique dimensions, the gates — is written to the open-standards layer and travels with you regardless of which course, or which platform, comes next.

Recap the module first, then zoom out to the course. The module's argument in one line: agent output becomes good through review, and review becomes cheap through structure — evidence instead of opinion, named dimensions instead of vibes, executable checks instead of repeated corrections, and a harness that absorbs every lesson so it never has to be taught twice. The limits slide is part of the summary, not a footnote: the gates exist precisely because ambiguity, politics, novel taste, and long-horizon consistency do not transfer to the agent.

Then close the course. Module 1 gave the vocabulary and the loop; Module 2 slowed the loop to working speed; Module 3 made the brief carry intent; Module 4 built the harness that carries everything durable; Module 5 chose the artifacts and tools the loop runs on; and this module added the gates that decide what ships. The thread through all six is the same division of labour: the agent runs production, and the human holds the brief, the critique, and the decision — which is also where the value of the job is moving.

If participants did the exercises, the artifacts they should leave with are concrete: a brief template they have used, a harness file they have started, a critique rubric with named dimensions, and a ship checklist they have edited into their own. Point them at the next courses, and at the school's articles for the workflows this course could only gesture at — visual QA, design-system audits, and the field notes on where the tooling is heading.