Summary: A September 10, 2026 GitHub walkthrough shows that Copilot app’s diff, terminal, and browser panels let users review agent changes, run the project, and test the UI in one place. The recommended checklist asks what changed, whether it runs, and whether it works. The article notes the material is beginner-oriented and does not cover large repos or non-web targets.
The hard part of agentic coding was never producing a change — it was confirming one. You receive a patch, then shuttle back and forth between the editor, the terminal, and the browser to settle three questions: what changed, does it run, and does it actually work. The walkthrough GitHub published on September 10, 2026, covering the Copilot app’s built-in panels, makes the case that all three jobs can now be handled in a single window.
The diff panel is where you stay in charge
Added, removed, and changed lines appear in the diff panel with green and red highlighting. On its own that is nothing new — every editor ships a diff view. The placement is what counts: the review surface sits beside the agent that produced the change, so accepting, leaving comments, or asking Copilot for a revision costs you no context switch.
GitHub frames this as keeping the human in the decision seat. That framing is the right one for anybody shipping agent-generated code, since the diff is the only artifact that reveals whether the agent did what you asked or something adjacent to it.
Running the project without leaving the session
The terminal panel executes commands inside the session. GitHub’s guidance for beginners is reassuring: mostly you are running the project’s own commands and reading the output, not authoring shell scripts from scratch. Commands can be run by hand, or wired into a script that a Run button exposes.
The worked example is a website: add a dev server script that opens the client folder and runs npm run dev, then click Run. Several terminal windows can stay open at once, which matters when one process is a long-running server and another is a one-off check.
If you build tools that execute code on a user’s behalf, the design lesson here is a familiar one — see our earlier post on what a hosted sandboxed shell changes for agentic tools for why execution context and review context should not sit far apart.
Browser preview closes the loop
For anything with a UI, the browser panel is the last mile. GitHub’s example opens the site and tests the new feature the way a user would. The Pick & Polish tool lets you select an element and adjust it with the agent, then re-run the dev server to see the fix.
This is the step most agent workflows skip. A diff can be clean and a build can pass while the feature is still wrong on screen. With preview inside the same app, the feedback goes back to the agent without a round trip through your memory of what you saw.
A checklist worth keeping
GitHub reduces the loop to three questions before you accept agent work: what’s changed, does it run, and does it actually work. That is a useful default for teams adopting coding agents, because it maps to three artifacts rather than three feelings.
The limitation is scope. The walkthrough is aimed at beginners and a web project; the supplied material doesn’t cover how the panels behave on larger repos, monorepos, or non-web targets. The terminal panel also assumes you’re comfortable reading command output, which is a real prerequisite, not a formality.
If you’re evaluating the app, start with the checklist on a small feature branch. Review the diff, run the project, check the browser, then accept and open a pull request from the same place. The value isn’t the individual panels — it’s that verification stops being a separate trip.