A developer on V2EX described a workflow I've lived through. His company won't let a bug or feature issue reach QA until the developer attaches two things: an interface test report and screenshots of the frontend interaction. So he wires up Cursor with a model and Chrome MCP, has the agent drive the browser, take screenshots, and assemble a text-and-image report to paste into the issue comment. It works. It also takes half an hour on anything non-trivial, and when he profiled where the time went, the answer was blunt: nearly all of it evaporates in MCP interaction. Every trivial browser action, a click, a field entry, a wait, costs one full round-trip between the agent and the MCP server.
The replies split into two camps, and both are right about different halves of the problem. One camp says swap the transport: try computer-use style drivers or a dedicated agent browser, one commenter claimed roughly a 10x speed edge over raw Chrome MCP. The other camp, and I think this is the deeper point, says stop running the test from scratch every time. As one put it, the optimal move is to have the AI generate a stable set of test code once, then run that, rather than paying the model tax on every execution. Convert unstable model behavior into stable code logic. The original poster pushed back honestly: he only needs to run this once, he's not QA, he just has to prove he ran his own code against the test environment before handing it off. Fair. But even a run-once workflow has a durable half and a throwaway half, and the trick is knowing which is which.
Where the honest line sits
Driving a real browser, rendering the actual frontend, and capturing screenshots of pixel-level interaction is the throwaway half in the sense that it has to happen on a machine with a browser and a session. That part does not move onto VicroCode, and I'm not going to pretend otherwise. There's no browser-automation or screenshot-capture capability on the platform to lean on, so if your acceptance criteria genuinely require visual proof of the rendered UI, that step stays where your Chrome and your MCP setup already live. Say so plainly in your own pipeline docs too, because the failure mode here is a tool that quietly claims to cover a step it can't.
What does rebuild cleanly is the other half: running the interface tests and assembling a formatted, shareable report. That's deterministic work. It's HTTP requests, assertions, a bit of data shaping, and some presentation. None of it needs an agent in the loop at execution time, and none of it needs a browser.
The part that becomes a hosted endpoint
Here's the shape I'd build. Write the interface tests in Python: hit each endpoint, assert on status codes and response bodies, capture request and response payloads, timings, and pass/fail. You can develop and run Python online so the whole thing lives where it will eventually run, no local environment drift between "works on my laptop" and "works in the report." This is exactly the code-generation task the V2EX thread was pointing at: let an AI coding assistant scaffold the test suite once, then keep running the stable artifact instead of re-improvising it every time. If you're new to structuring that kind of assistant-generated suite, the AI coding material is a reasonable starting point.
Store each run's results in a SQLite database. That gives you a real trail: which endpoints were checked, what came back, when, and whether it passed. It also means the "run once" case the OP cares about and the "run it every release" case someone else wants are the same code with a different trigger, not two separate scripts.
For the report itself, generate an HTML page from the stored results, and run HTML online so it's hosted at a stable URL. Now the thing you paste into the issue comment isn't a wall of inline text and dropped image links, it's one link to a formatted report page that renders the interface test results cleanly. Wrap the trigger as an API Endpoint so a single call runs the suite, writes to the database, and returns the report URL. That's the round-trip tax gone from the API half entirely: no agent, no MCP, one request.
Why this framing matters beyond one workflow
Two other threads in the same batch rhyme with this. One developer's Claude account got suspended overnight, and the top reply's advice was to stop depending on any single AI and instead lean on standardized process: fixed test cases, automated tests, hard code-level constraints. Another long post complained that companies now chase token consumption as if usage equals output, pushing people to re-run agents and regenerate code for metrics rather than results. Both land on the same instinct as the e2e thread. The value isn't in how many times you invoke a model. It's in converting the reliable part of your work into stable, hosted artifacts you own, so that a suspended account, a slow round-trip, or a token dashboard can't take your pipeline hostage.
So the split I'd commit to: keep the browser and screenshots where they must live, and don't oversell that they moved. Take the interface tests and the report, the genuinely durable half, and turn them into Python you run online, a SQLite trail, and an HTML report behind one endpoint. The 30 minutes doesn't vanish, the browser half still costs what it costs. But the half that was never supposed to be slow stops being slow, and you get a report link that's the same every release instead of a fresh improvisation each time. I haven't measured the time saved on this specific setup, so treat any speedup as unverified until you run it against your own environment.