4.4 Verification: Never Trust, Always Check

"Never trust, always check" can sound exhausting. The practical response is to design verification: define done, automate repeatable checks, and reserve human review for behavior and judgment. Good design reduces repeated effort without making rigor free.

What you will learn

• Build a verification pyramid: what the agent checks, what tools check, what only you check.
• Write "done means" clauses that make verification automatic.
• Run a five-minute human acceptance pass that catches what machines miss.

Builder principle

Verification isn't the tax on speed. It is the speed — unverified work comes back, and rework is the slowest thing in the building.

The verification pyramid

Three layers, cheapest and most frequent at the bottom:

        ┌─────────────┐
        │   YOU        │  ← final acceptance: real device, real user behavior
        ├──────────────┤
        │   TOOLS      │  ← tests, builds, linters — pass/fail, no opinions
        ├──────────────┤
        │   THE AGENT  │  ← runs its own checks every loop turn, self-corrects
        └──────────────┘

Layer 1 — the agent. Every verify beat of the loop: it runs the code, reads errors, re-checks output. You maximize this layer with one habit — putting verification in the brief: the agent will then loop on failures automatically instead of reporting "done" hopefully.

Layer 2 — tools. Checks with binary answers: does the build succeed, do the tests pass, do the links resolve. Tools don't get tired and don't want to please you — which is exactly the personality you want in an inspector. (Chapter 9 wires these to run automatically via hooks; for now the agent runs them on request.)

Layer 3 — human acceptance. The irreplaceable five minutes: does this actually serve the human it's for? The reviewer may be you or an honestly credited delegate with the relevant access needs or visual perspective. Machines verify specified checks; people judge whether the result works for its users.

Writing "done means" clauses

The highest-leverage sentence in any brief. Compare:

Weak	Strong
"Make the site look good on phones"	"Done means: the main path works at 375px and at 200% zoom; content reflows without lost controls or two-direction scrolling"
"Fix the signup bug"	"Done means: a new user can sign up end-to-end; show me the passing test that proves it"
"Write the product descriptions"	"Done means: 5 descriptions, 40–60 words each, no repeated openings, each mentions the material"

The pattern: observable, countable, or testable. If a stranger couldn't referee whether "done" happened, the clause is a vibe, not a definition. Strong clauses do double duty — they aim the work and hand the agent its own checklist for the verify beat.

The human acceptance pass

Five minutes, after the agent and the tools are green, on anything real:

1. Fresh perspective: close the session summary. Approach the thing as its user — not as someone who knows what it's supposed to do. Use the interfaces and assistive technology available to you.
2. The happy path: do the main thing a user would do, start to finish. Actually do it — click it, submit it, read it out loud if it's writing.
3. One rude test: do something wrong on purpose. Submit the form empty. Resize to phone width. Click the button twice, fast. Real users are rude; be rude first.
4. The neighborhood check: did anything near the change break? The classic agent failure mode is fixing the target and grazing a bystander — glance at what surrounds the work.
5. The standard: would you show this to the person it's for, today? Not "is it perfect" — is it acceptable to ship? Yes → commit and push. No → one more loop turn with a specific gap named.

Accessible human-acceptance matrix

Use the rows that apply to the artifact. A single visual glance cannot replace them. Record the device or tool, the path attempted, the observed result, and any limitation or delegated check.

Perspective	Human check	Evidence to retain
Keyboard only	Starting at the address bar or application entry point, complete the main path and one failure path without a mouse. Confirm every control has a visible focus indicator, the order makes sense, and no keyboard trap appears.	Browser/device, path taken, pass or exact blocker
Screen reader	Complete the same paths with a screen reader. Confirm page title and headings orient the user; controls have useful names, roles, states, and errors; announcements occur in a meaningful order.	Screen reader/browser, path taken, short notes or an accessible recording
200% zoom and reflow	At 200% browser zoom, check the main and failure paths without losing content or controls. Confirm text reflows without two-direction scrolling except where the content genuinely requires it.	Viewport/zoom, path taken, pass or exact clipping/scroll issue
Contrast and non-color cues	Inspect text, controls, focus, errors, charts, and status. Confirm information is readable at required contrast and is never conveyed by color alone; use a contrast checker where applicable.	Tool/value checked and any non-color label, icon, pattern, or text cue
Visual presentation	Check spacing, cropping, hierarchy, and visual consistency. If you cannot assess a visual criterion yourself, ask a person who can and label the evidence delegated visual review rather than implying you observed it.	Reviewer, criterion, device/viewport, result, and delegation label

Accessibility is not one person's final inspection. Test with affected users when the stakes, audience, or novelty call for it; document who was represented and what remains untested.

🌱 No-code lane⚙️ Engineer lane

The rude test deserves special love in your lane: you do not need to read code to test behavior. Wrong input, keyboard-only use, zoom, weird sizes, fast activation, and an old phone are all observable checks. Use the matrix and record the evidence you actually gathered.

Your version of maximizing layers 1–2: make the agent write the test before or with the fix ("done means: a test that fails on the old code and passes now"), keep the suite fast enough that the agent actually runs it every turn, and treat "works on my machine" claims exactly as you would from a human — as a request to see CI. Chapter 9 turns all of this into hooks so it doesn't depend on anyone remembering.

When verification fails

The payoff moment — handle it as a loop turn, not a disappointment:

Verification failed: at 375px the gallery still scrolls horizontally.
Find the cause, fix it, and re-check the same done-means clause.

Specific failure, straight back into gather-act-verify. No blame, no essay. Systems, not moods.

Try it now

Design verification for your quick win, before its next session:

1. Write three strong "done means" clauses for its current state — observable, countable, or testable.
2. Run a session asking the agent to verify against them (not build — verify) and report evidence per clause.
3. Run the five-step acceptance pass and its accessible matrix, rude test included. Record any delegated visual check honestly.
4. Journal the gaps: what did the agent's pass miss that yours caught? That delta is why layer 3 exists.

Check your understanding

• Name the three pyramid layers and what each is uniquely good at.
• Turn this into a strong clause: "make the checkout work better."
• What is the rude test, and why is it the no-code lane's superpower?
• What five perspectives belong in the accessible human-acceptance matrix?
• How do you respond when verification fails — what does the message contain, and what doesn't it?