In my last article, I described operating a distributed software-development workflow: agents implement stories, review changes, and coordinate through shared work records. A separate QA agent tests the product and sends defects back into the queue.
As agents change the code, users still need to accomplish what the software was built to help them do. The QA loop checks that behavior through the frontend: can someone still find the right controls, complete the task, recover from errors, and see the correct result after reloading?
That gives the development loop a user-facing check on its changes. The implementation can evolve, but the intended outcome remains the reference for testing.
Start with the person doing the work
We start by defining personas. A role alone is too thin. Two people with the same permissions can have different levels of experience, different devices, and different tolerance for hunting through a screen.
Our persona definitions include working context and behavioral tendencies. Someone processing a queue all day needs efficient keyboard interaction. Someone using the application occasionally may need clearer labels and a path that does not assume training. An interrupted user needs to return without losing work.
Those differences shape the scenarios. The test specifies the task, its starting point, what successful completion looks like, and which difficulties to look for. The persona gives the browser run a purpose beyond visiting pages.
Drive the application through its visible controls
We use Playwright MCP, which gives an agent browser tools for inspecting a page and interacting with it. The agent observes the rendered interface, types into fields, selects suggestions, clicks controls, and checks what changed. Playwright CLI is the fallback when MCP is unavailable.
The interaction rules matter. A test that jumps to a hidden URL or writes directly through an API can bypass the exact frontend problem it was meant to find. If the user cannot discover the next step through visible navigation, that is a finding.
Saving also needs verification. Our procedure requires navigating away and back, or reloading, then comparing the saved values. A success message is insufficient evidence that the work persisted. Where a workflow crosses roles, the next persona signs in and checks that the previous person's work is visible and correct.
Test changes and revisit existing workflows
There are two places this enters the development loop.
For a UI-visible change, the implementer must validate the relevant persona scenarios alongside the required automated tests. A new or materially changed feature needs corresponding scenario coverage. Changes to a task with an experience budget also require that budget to be measured again.
Separately, the QA runner revisits existing functionality through broader sweeps. For a distribution-stack sweep, its procedure builds verified source revisions and starts a local test deployment with synthetic data before driving the browser. The evidence must identify the build actually serving the application.
That distinction keeps a passing result attached to a particular build and workflow, rather than becoming a general claim that the frontend works.
Measure the effort, with a clear limit
A task can work and still demand too much effort. Our specification includes time and action budgets for common tasks, plus signals such as repeated data entry and dead ends.
The measurement procedure is concrete:
- Start from the persona's normal landing screen, not a deep link.
- Stop when the terminal confirmation is visible.
- Run the task twice and record the second run.
- Record time and discrete actions against the target, including on a pass.
These are simulated workflow measurements. Agent reasoning and browser-tool latency affect elapsed time; a persona does not reproduce human hesitation or familiarity. The measurements can flag friction worth investigating, but estimating a typical user's completion time requires comparison with representative people.
Feed confirmed defects back into implementation
The QA agent does not fix product code. Its job is to reproduce findings, check for existing stories, and produce an actionable defect report: expected behavior, actual behavior, visible reproduction steps, affected persona, build identity, evidence, and acceptance criteria.
Implementer bots can then pick up those stories through the normal development queue. Findings that require subjective judgment go to a human rather than becoming automatic defect tickets.
I still monitor the agents, unblock them, and check the work against the specification. This loop gives that supervision concrete material to inspect: the task attempted, the path taken, the result observed, and what remains untested.