Who verifies what the agents built?

A pull request arrives complete and plausible, and it's larger than there is time to read properly. Every one of us has felt this in our own week.

Generation got faster and review didn't. I don't read the distance between them as a productivity statistic. It's a gap, and defects fall into it.

Accessibility defects fall into the gap

They fall into it more than most defects do.

A wrong contrast pair doesn't break a test, and a focus style that was never written doesn't throw an error. An aria-label invented from a guess announces itself with total confidence.

A reviewer skimming a two-thousand-line diff has no reason to stop on it, because it looks exactly like the code around it. So the reviewer isn't the person who finds it.

It's found by someone with low vision who can't read the result, or a keyboard user who loses their place, or a screen reader user told something untrue about a control.

That is the 2021 argument again on new ground: exclusion is the default outcome of unexamined defaults. We now have a machine that produces defaults at a rate our review practices were never designed to absorb.

The obvious answer is to slow generation down. I don't believe that works, and I don't believe anyone will do it. So I'd leave generation at the speed it is, and make verification cheap, visible and explicitly somebody's job.

That somebody can't usefully be the agent that did the work. An agent grading its own homework gives us a second opinion from the same source, and I don't count that as a check.

That's the design principle I built atomic-cockpit (opens in a new tab) around. It's a control surface for running many agents across several projects at once, built on Atomic, the open-source agent runner.

You say what you want built and an agent writes a plan. Nothing happens until a person approves it. Then it hires the agents the job actually needs, so a small job gets a small team.

They build and they talk to each other. Then a different agent, one that did not write the code, verifies the result against the checks attached to the plan.

A checker working from a plan it did not write is a real check, and without that separation we're paying to agree with ourselves.

The case study (opens in a new tab) documents a run rather than a demo. It had nine checks, all passing, verified by an agent that did not write the code and then reviewed by a person.

It took fourteen minutes from approval to proof, and it cost one dollar ninety-eight.

Those are measurements, and they're the only claims I'll make here. Does this setup produce more accessible software than the alternative? I don't know. That run doesn't establish it and I haven't measured it.

The cost is the line I find interesting. Two dollars is small enough that "try it and see" has changed.

It's also large enough that running fifty carelessly is a real number, and we tend to hold only one of those at a time.

That run also surfaced a defect in one of the cockpit's own tabs (of course it did), and the defect stayed in the write-up. A tool that only ever shows success is being marketed, and nobody is testing it.

Every demo any of us has watched was a run somebody chose, and the useful information is in the runs they didn't choose.

A check worth trusting has three properties

None of this requires the same tooling. When I decide whether to trust a check, I look for three properties, and most of what we call review has only one.

The first is independence, meaning the checker did not produce the thing. Agents make this easy where humans make it expensive, because a second reviewer used to cost a salary and now costs pennies.

The second is a prior definition of success. Checks written before the work started get run. Checks remembered at the end get skipped when the diff is large, which is when they matter most.

The third is that a person can follow it. If nobody can inspect a verification, it's only a claim. The cockpit's roster and message board exist so that one person can see what a team of agents actually did.

Accessibility checks fail the second property more than any other. They're almost never in the definition of done, so they're almost never in the review.

• Separate the verifier from the author. Use a different agent, a different person or a checklist written before the work started. Anything will do, as long as it isn't the thing that produced the output.
• Attach checks to the plan, not the review, and put accessibility on that list by name. Contrast, focus order, accessible names, behavior at 375 pixels. They don't fail loudly, so if they aren't on the list they aren't in the review.
• Keep the approval gate, especially when it annoys you. It's friction, and it's also the only moment when someone with context sees the plan before tokens start moving.
• Publish the run that went wrong. That is cheap if we decide it in advance and expensive if we decide it under pressure.

The conventions for how generated work gets verified are being set now, while they're soft. Most of the people setting them haven't been asked who gets excluded when nobody checks.

On that last list item, the screenshots in the case study were taken every two seconds while the run happened, rather than staged afterwards. There's a commit in the history titled "describe the screenshots accurately instead of retouching them."