If You Ship Faster, Someone Still Has to Click

We’ve gotten very good at shipping features fast.

Planning agents read the Jira ticket. Implementation agents write the code. Test agents run the suite. Review agents check the diff. Git agents push the branch. The whole pipeline runs in under 30 minutes, with me doing roughly nothing except approving the PR.

But there was always a step I hadn’t automated: clicking through the actual UI on a real PRE environment and checking that the feature works.

Someone still had to do the monkey work. Login. Navigate. Click. Fill the form. Toggle the switch. Check the list. Click delete. Make sure nothing broke.

Session 13 was about shipping PRs autonomously. Session 28 was about a different question: can an agent do the QA?

The answer surprised me.

The Feature

FEAT-418 was a meaningful feature: adding default values to configuration entries, with a 3-state property system (“use default” / “custom value” / “no default available”) and delete protection for entries actively in use.

After the implementation landed in PRE, it needed to be tested. Not unit tested — we had those. I mean tested like a human tests: navigate to the configuration page, create a new entry, verify the defaults appear, toggle the “use default” switch, check the description text, try to delete something that’s in use and confirm it’s blocked, delete something that’s not in use and confirm it works, check the browser console for errors.

The kind of testing that developers are technically capable of doing and thoroughly hate doing.

I wrote a QA checklist. Then I handed it to an agent.

307 Interactions

The agent opened Chrome. It navigated to the PRE environment. It hit the login page and paused — credentials are credentials, so I typed them in. Two-factor auth: same deal, I handled it. Then I stepped back.

What happened over the next 42 minutes was one of the stranger things I’ve watched.

The agent worked through the checklist methodically. It read the page structure, identified the relevant table and buttons, clicked “Create New Entry,” filled in the configuration form, saved it, then navigated back to the list to verify the new entry appeared. It found the “Use Default” toggle, clicked it, verified the behavior changed. It checked the property description field. It attempted to delete an entry flagged as in-use and verified the delete was blocked. It found an entry not in use and verified the delete succeeded.

At some point it stopped clicking UI elements entirely and ran JavaScript.

const response = await fetch('/api/config/entries');
const data = await response.json();
return data.entries.filter(e => e.hasDefaults);

The evaluate_script tool lets you execute arbitrary JavaScript in the page context. The agent used it to call backend APIs directly, inspect session state, and verify what the backend actually stored — not just what the UI was rendering.

9 features on the checklist. 9 passed. Zero console errors.

307 browser interactions in total.

The Model That Works

Here’s how the workflow actually runs:

Step 1: Write the checklist. This is still human work, and it should be. You know what the feature is supposed to do. Write the test cases in plain language — “create an entry with defaults, verify defaults appear in the list” is enough.

Step 2: Hand it to the agent. The agent gets the checklist and a Chrome MCP connection. It starts from the beginning and works through each item sequentially.

Step 3: Assist where needed. Login credentials, two-factor authentication, anything requiring real secrets stays with you. The agent will pause and ask. You handle those moments, then step back.

Step 4: Review the report. The agent outputs what passed, what failed, any anomalies noticed along the way. Design inconsistencies, unexpected error messages, console warnings — things a human would catch while clicking around.

The part I didn’t expect: the agent notices things that aren’t on the checklist. While verifying delete protection, it caught an edge case in the pagination behavior that wasn’t in the test cases. It flagged it anyway.

Why This Matters More Than It Seems

Fast pipelines create pressure.

When you can go from ticket to PR in 30 minutes, the bottleneck isn’t development anymore. It’s everything after. Code review. QA sign-off. Deployment approvals. The human processes that don’t scale the same way the coding process does.

If you ship 5x faster but QA is still manual, you don’t have a 5x faster pipeline — you have 5x more QA backlog. Features pile up. The PRE environment gets crowded with unverified changes. The humans doing the clicking get overwhelmed and start cutting corners.

Agentic development without agentic QA is incomplete. You’ve removed the bottleneck from one place and created it somewhere else.

The question isn’t “can we ship faster?” — we’ve answered that. The question is “are we willing to commit to the same speed across the whole lifecycle?”

The Parallel Future

Here’s where it gets interesting.

Browser QA with a single agent is useful. It removes the clicking work from a human. But one agent is still sequential — it works through your checklist the same way one human would.

Ten agents with ten browser sessions is something different.

Ten agents hitting your PRE environment simultaneously isn’t just 10x faster QA — it’s a load test. It’s race condition detection. It’s the difference between “does this work when one person uses it” and “does this work when real traffic hits it.”

Feature flags with staggered rollout? Have 5 agents test with the flag on and 5 with it off, simultaneously, both interacting with the same backend. Create and delete operations running in parallel on the same resources. Session handling under concurrent load. The kinds of bugs that only surface when multiple users are doing things at the same time — now systematically tested before the feature ships.

The single-agent model I used in Session 28 already works today. The multi-agent swarm is where this goes next.

What Didn’t Work Perfectly

Here’s where it got rough.

MCP permissions are default-deny. The first time the agent tried to fill a form, it couldn’t — fill, type_text, and press_key weren’t in the allowed tools list. I had to manually add 13 Chrome DevTools MCP tools to the settings file before form interactions worked. One-time setup cost, but a real surprise if you’re not expecting it.

DOM reads on large tables are expensive. The data table had 1496 rows. The agent’s full DOM capture of that page was enormous — thousands of tokens, eating context fast. We worked around it with evaluate_script to query data directly instead of parsing the DOM. Design around this when setting up your QA workflow: avoid full-page DOM reads where possible, use JavaScript queries for data verification.

One browser, one agent. The Chrome DevTools MCP is single-threaded per browser instance. For the parallel swarm model, you’d need separate browser contexts — not a technical blocker, just an architecture consideration when you scale up.

The Boring Work, Reassigned

Here’s the frame I keep coming back to: QA is important work, and it’s also often boring work. It’s clicking through the same paths after every deployment, verifying the same things, catching regressions before they reach users.

That boringness isn’t a sign the work doesn’t matter. It’s a sign it’s a good candidate for automation.

The goal isn’t to eliminate QA. It’s to give people back the part that requires judgment. Exploratory testing. Edge case design. The weird scenarios only an experienced human would think to try. Let the agent do the checklist. Let the human do the thinking.

The collaboration model works like this: you write the checklist, you handle the secrets, you review the report. The agent does everything in between. It’s less “agent replaces QA” and more “agent removes the boring parts so QA can do the interesting parts.”

One More Thing

Session 13 answered: what does it look like when the pipeline becomes a coworker?

Session 28 answered something different: what does it look like when the coworker does the clicking?

A lot like you’d expect. Methodical. Thorough. Occasionally surprising in the best way.

307 interactions. 42 minutes. 9/9 passed. Zero complaints about clicking through the same UI again.

If you’re building a fast pipeline and QA is still the manual step — that’s the next one to automate.