The hard part of agentic coding was never generating a change. It was verifying one. You’d get a patch, then bounce between editor, terminal, and browser to answer three questions: what changed, does it run, and does it actually work. GitHub’s September 10, 2026 walkthrough of the Copilot app’s built-in panels argues those three jobs can now happen in one window.
The diff panel is where you stay in charge
The diff panel shows added, removed, and changed lines with green and red highlighting. That’s not novel on its own — every editor has a diff view. What matters is the placement: the review surface sits next to the agent that produced the change, so you can accept, leave comments, or ask Copilot for a revision without context-switching.
GitHub frames this as keeping the human in the decision seat. That’s the right framing for anyone shipping agent-generated code, because the diff is the only artifact that tells you whether the agent did what you asked or something adjacent to it.
Running the project without leaving the session
The terminal panel lets you execute commands inside the session. GitHub’s guidance for beginners is reassuring: you’re mostly running the project’s own commands and reading output, not authoring shell scripts from scratch. You can run commands by hand or wire them into a script exposed through a Run button.
The worked example is a website: add a dev server script that opens the client folder and runs npm run dev, then click Run. Multiple 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’re building tools that execute code on a user’s behalf, the design lesson here is familiar — see our earlier post on what a hosted sandboxed shell changes for agentic tools for why execution context and review context should not be 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 as 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. Having preview in the same app means 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 accepting agent work: what’s changed, does it run, and does it actually work. That’s 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.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.