1
1 Comment

How do you verify a Copilot code change against the live UI?

CI tells us the code and automated tests passed. It does not prove that the intended deployment is live, the authenticated page renders correctly, or the changed journey works under a real browser session.

The pattern we are using is a small acceptance contract for the coding agent:

  1. Identify the exact build or commit.
  2. Use a named, authorized browser identity.
  3. Keep the task read-only unless a write action is explicitly approved.
  4. Check visible states in sequence instead of calling page load a success.
  5. Return screenshots, URLs, relevant console failures, and a PASS / FAIL / BLOCKED verdict.

Copilot keeps the repository context. BrowserAct provides the real-browser execution, session continuity, and evidence.

I wrote up the complete workflow here: https://www.browseract.com/blog/github-copilot-browser-automation

How are you currently closing the gap between a green CI run and a verified deployed UI?

on July 16, 2026
  1. 1

    The acceptance contract needs one more anchor: expected state must come from the same commit as the code, or screenshots can validate a stale assumption perfectly. I'd include the deployment identifier in the page or response headers, then verify one critical path plus its negative or error state under the named session. PASS should require both visible behavior and no new high-signal console or network failure.

Trending on Indie Hackers
I sent 43 cold emails with my own tool. 17 replied. 1 paid. Here’s the unofficial launch. User Avatar 160 comments I built for one user. Myself. User Avatar 72 comments Got our first paid customers from an unexpected channel User Avatar 30 comments I came up with a great idea for a solo Vibe Coding project, and I'm testing it out right now User Avatar 23 comments AI prices dropped 97% since 2023. So why are AI bills 3x higher? User Avatar 19 comments Day 4 — designing what happens when a survey DOESN'T work out User Avatar 16 comments