I have shipped agent-written code I could not defend in a standup. More than once. The pattern is the same each time. The diff looked reasonable, the agent’s prose sounded confident, I merged, and a real user filed a ticket later that pointed straight at something the diff would have shown me if I had read it twice. The agent is not the failure mode. The review is.
The GitHub Copilot app is a quiet attempt to fix the review. It does not make the model smarter. It puts the three pieces of evidence side by side: the diff, the terminal, the running app. Run button in the middle. After a week of bouncing between editor, terminal, and Chrome every time an agent finished a task, that change in layout mattered more than the underlying model.
I care about one question here. Does this app actually move review quality forward, or is it just different window dressing for the same shortcuts I have always taken?
The shortcut the app is trying to retire
The shortcut is: read the diff, assume the rest, merge. It is fast. It is also the most common reason AI-written code lands bugs that the tests did not catch. The diff tells you what changed. The terminal tells you whether it runs. The browser tells you whether it actually works for a user. Skipping the third step is where most production bugs come from. Nobody catches them because the test suite is green and the diff looked fine.
The app’s bet is that the shortcut happens because the third step is annoying. The diff is in your editor. The terminal is one keystroke away. The browser is two windows and a localhost:3000 away. By the time you finish bouncing, you have lost the thread of what you were verifying. The app collapses those three surfaces into one window, so the loop happens without losing context.
That is a workflow fix, not a model upgrade. It is also the right fix, because the model is already fast enough.
When one window actually helps, and when it does not
The one-window layout earns its keep when your project boots fast and your dev cycle is short. A plain website, a small Node service, a Python script that starts in two seconds. You change a file, you click Run, the server is up, the browser panel shows the page, you click the thing, you see the result. Whole loop, under a minute.
The one-window layout does not earn its keep when your stack needs Docker, a remote database, and a staging server to do anything meaningful. The browser panel will load, but it will load a 500 page because the database is somewhere else. You will spend more time wiring the local environment than you ever save on tab switching. In that case, you are better off with a heavier review on a deployed environment than a slick review on a broken local one.
Honest test: if npm run dev (or your equivalent) works in under ten seconds with no manual steps, the panels will save you real time. If it does not, fix that first. The panels amplify whatever dev setup you already have.
What to actually do in the diff, in order
The diff panel is where you stay in control, if you actually use it. Most reviewers do not. They glance at the green and red, they accept, they move on. That is the shortcut.
A useful order for reading a diff:
- File names first. Six files changed for what should be a one-line tweak is a red flag, full stop. Ask before you read.
- Style choices you would not have made yourself. Variable renames, comment rewrites, formatting churn. None are wrong on their own, all of them are a hint the agent is doing more than you asked.
- Surprises. A config file you did not request. A new dependency. A renamed test fixture. None are dealbreakers, all are worth flagging.
- Logic that touches a downstream caller. Renamed function? Grep for the old name. Changed return type? Find every caller. Tests do not catch these, the diff does.
A small habit that compounds: leave a comment the moment something feels off, instead of accepting and moving on. If you do not say it now, you will forget what bothered you in three minutes.
What to run before you hit accept
Code that compiles is not code that works. The terminal panel is the part that catches the lies the diff told you. A few commands are worth running every time, even when your test suite is green:
- The linter. Different mistakes than the test suite.
- The typechecker. Different mistakes still.
- The actual command a user would run. If your CLI is the deliverable, run the CLI. If your route is the deliverable, hit the route.
The terminal panel gives you output attached to the session, scrollable back through history, errors next to the code that produced them. That is what it buys you over an external Terminal window. Less time reconstructing what happened, more time fixing what happened.
The catch, again, is project setup. Brittle dev script, ten manual steps, mysterious env vars the README mentions once. None of that is the panel’s fault. None of that is the panel’s fix. Fix the dev script before you fix the review process. The two compound.
What clicking through catches that nothing else does
The browser panel is where you find out whether the change works for a real person. Tests pass, linter is clean, but the button is off-center on mobile, or the modal does not close on Escape, or the new dropdown is unreadable on a high-contrast theme. None of those are caught by a unit test. All of them are caught by a human clicking through.
The feature inside the panel worth knowing is Pick and Polish. You click an element on the page, you describe what you want changed, the agent makes the edit. Useful for layout and styling tweaks where describing the change is faster than coding it. Skip it for logic changes where a diff and a test run tell you more. Always reload after the change, never trust the in-place preview. Re-run the dev script before you accept, so you know nothing else broke.
For the obvious “does this look right and does the button work” check, nothing in your stack is faster. The browser panel will not catch performance regressions, accessibility issues, or mobile-only edge cases. None of those are obvious from a desktop click-through.
The cheap habit that fixes most of it
If you take one thing from this article, take this: do not accept the diff until you have run the code. Not “looked at the tests.” Run the code. Putting the terminal in the same window as the diff makes that friction zero, which is the whole point. Cost of running it is one click. Cost of skipping it is a bug you will debug later when you have forgotten what the agent did.
The three-panel layout is a tool for enforcing a habit. If you already run the code before you accept, you do not need the tool. If you do not, the tool makes the habit cheap enough that you might actually keep it. That is the only honest way to evaluate whether to adopt it.
You can build the same review loop in VS Code with split panes, an integrated terminal, and a Live Server extension. The Copilot app hands it to you pre-wired. Either works. The loop is what matters, not the window.
Trade-offs
The Copilot app is yet another tool to learn. Anyone already living in VS Code with their own terminal and preview setup does not strictly need it. Anyone starting from scratch, or anyone who wants a focused workspace for agent tasks, gets a real win out of it. Anyone who has already wired the loop in their editor can safely skip the app.
The panels only earn their keep when the project runs locally. A stack that needs Docker, a remote database, and a staging server will not get the full benefit of the browser panel. Expect to spend twenty minutes on the dev script, or the Run button will not be useful.
Building the loop once, in whatever tool you like, is where you actually earn your salary. Stop merging code you cannot defend in a standup.
What to try this week
Pick a small project you actually use, not a fresh demo. Run one real task end to end. Add a feature, fix a known wart, change a layout. Walk through every step in the same window before you accept anything. Count how many tabs you would normally have open for the same task. If the count drops and you trust the result more, keep using the layout. If the count stays the same and the layout feels like one more tool to manage, drop it. Either result is informative.
The point is the habit, not the software.