Field notesNote
FILED / Aug 4, 2026
- workflow
- testing
- review
The screenshots were useful. Opening them was the problem.
Automated Playwright screenshots were genuinely useful; the friction of reaching them from a phone is what made live previews the primary review surface.
At first, automatically capturing screenshots during browser tests felt like an obvious improvement to my workflow.
They gave me something concrete to inspect before merging a change into main. A vision agent could review them. I could bring them into ChatGPT and ask about spacing, hierarchy, wrapping, or some weird line that did not look right. They also gave the pull request a visual record instead of relying entirely on passing tests and a written description.
That was genuinely useful. The screenshots were doing their job.
The problem was how I had to reach them.
I do a lot of project review from my phone, often while I am away from my computer. To inspect a GitHub Actions artifact, I had to open the GitHub app, find the artifact link, get pushed into a browser, download a ZIP file, open my files, extract it, find the right image, and then start looking through the captures.
None of those steps was especially difficult. Together, they created enough friction that reviewing the screenshots started to feel like a chore.
That mattered because a review artifact only helps when somebody actually reviews it.
The turning point was realizing that I could usually open the pull request’s preview deployment instead. One link took me directly to the real interface running on my actual phone.
That was faster, but it was also better evidence for many of the questions I cared about.
I could scroll naturally. I could tap the controls. I could see whether the layout fit the real browser chrome and screen width. I could notice whether an expanded section appeared somewhere unexpected, whether focus moved properly, or whether an interaction felt confusing even though the static result looked fine.
A screenshot could show me what the interface looked like.
A preview could show me what using it felt like.
There was a tradeoff. Reviewing mainly from my phone meant losing the convenient, exact desktop captures the automated run had produced. I could switch my phone browser into desktop mode and get a rough approximation, but that was not the same as inspecting a true wide viewport.
So I did not decide that screenshots were bad or that previews replaced them completely.
Screenshots are still useful when a vision agent needs a stable image to inspect, when a precise desktop breakpoint matters, when I want a preserved before-and-after record, or when a failed browser test needs debugging evidence.
The change was making them deliberate instead of automatic.
The preview deployment became the primary human review surface. Screenshot artifacts became something to generate or upload when they answered a specific question, rather than something attached to every successful push because more evidence sounded inherently better.
The lesson was not really about Playwright or GitHub Actions.
It was that the format of the evidence has to fit the person reviewing it.
The automated screenshots were technically good evidence. But for someone reviewing primarily from a phone, they were wrapped in the wrong delivery system. A live preview removed that friction and made it easier to inspect the thing that would actually ship.
Good quality checks are not just checks that exist.
They need to be reachable, understandable, and practical enough that a real person will use them.
Related work
- RuneSpace case studyA mobile-first browser game with an old-school MMO influence and a blue-collar science-fiction world.
- ParkQuest live siteA family park passport for discovering parks, recording private visits, and earning server-controlled adventure progress.