The patch-file version of the agent worked, but I was still running it the same way I always had — pointing it at one file, waiting for the patch, moving to the next. A senior dev's insight this time wasn't about the patch files themselves. It was pointing out that the per-file loop was still mine to run by hand, and there was no real reason it had to be.
From per-file requests to a full scan
I rebuilt the workflow so the agent scans an entire codebase on its own — checking every file against the same screen-reader-accessibility rules it already knew, and generating a patch file with a diff for each one that actually needed a change. I stopped being the thing standing between one file and the next.
The projected numbers
The standard estimate for this work by hand is 50 to 60 hours a system. Scanning the whole codebase and generating patch files on its own is projected to bring that down to about 5 hours a system, including reviewing the diffs — but that's still an estimate, not a measured result. We haven't run the full-scan version against an entire system yet; I hit token limits again, the same problem that slowed down the original version of this agent.
How we're planning to actually prove it
In a dev meeting, we talked through how to validate the improvement instead of just taking my word for it: run an existing ADA compliance tool against a system to get a baseline score, run the agent, then run the same tool again and measure the difference. That benchmark is the plan for the first real full-system test, once the token problem is solved.
What's still manual
The review step didn't go away, and I don't want it to. Every diff still gets read before it's applied — the same human-approval principle the first version was built around. What changes with a full scan is how much of the 50-to-60-hour estimate was spent waiting on me to point the agent at the next file, instead of on the part that actually needs a person: deciding whether the fix is right.