How to Review an AI Agent's Code Changes from Your iPhone
Starting a coding agent from your phone is easy. Reviewing what it did is where the workflow usually breaks down. `git diff` in a phone-sized terminal wraps every line, loses the +/- columns in a wall of colour, and makes it genuinely hard to tell a one-character change from a rewritten function. And review is the part that matters: the agent is fast, confident, and occasionally wrong in ways that read as plausible. Here is how to review properly on a small screen, and what to look for when the author is a machine.
Written by the GateShell team at Hefty Innovations
Step by step
- 1
Ask the agent what it changed before you look
Before opening a diff, ask the agent to summarise its own changes: which files, and why each one. This is not a substitute for reading the diff, it is a way of framing it: you are now checking a claim rather than reconstructing intent from scratch. It also surfaces the case where the agent touched something it was never asked to touch, which is much easier to notice in a one-line summary than in a hundred-line diff.
- 2
Open the git view instead of running git diff
In GateShell, open the git view for the connected server. Changed files are listed with their status rather than concatenated into one stream, so you can see the shape of the change, three files or thirty, before reading any of it. That count alone often tells you whether the agent did what you asked.
- 3
Read file by file, hunk by hunk
Tap a changed file to open the review sheet. Staged and unstaged changes are parsed into per-file, per-hunk diffs with real old and new line numbers, and addition and removal totals per file. This is the format that makes phone review possible: you are reading one bounded change at a time with the surrounding context, rather than scrolling a single undifferentiated stream. Very large diffs are truncated, and the sheet tells you when that has happened rather than quietly showing you part of the picture.
- 4
Look for the three things agents get wrong
First, scope: changes to files outside what you asked about. Second, deletions: agents remove code they judge redundant, and the judgment is sometimes based on not having read the caller. Third, silently weakened behaviour: an error path turned into a swallowed exception, a test assertion loosened to make a suite pass, a timeout raised rather than a race fixed. Additions are easy to skim and usually fine; it is the removals and the loosened conditions that deserve your attention on a small screen.
- 5
Check the tests actually ran, not just that they exist
If the agent says it added tests, look at whether they were executed and what they asserted. A test that passes because it asserts almost nothing is worse than no test, because it reads as coverage. Scroll back through the terminal, or ask the agent to run the suite again and show you the output, which is cheap to do from a phone and worth the extra minute.
- 6
Commit deliberately, or send it back
Once you are satisfied, stage and commit from the git view. If you are not, say so specifically. Pointing at the file and the hunk rather than giving general feedback produces a far better second attempt. The whole loop, including the correction, is well suited to a phone; it is only the reading that needs the right tool.
Frequently asked questions
Why not just run git diff in the terminal?+
You can, and for a two-line change it is fine. The problem is line wrapping: at phone width, a unified diff wraps continuously, which destroys the visual alignment that makes diffs readable and blurs the boundary between changed and unchanged lines. The parsed review sheet keeps each hunk bounded with its line numbers intact, which is what makes a real review possible rather than a skim.
Can I review changes the agent has not committed yet?+
Yes. Both staged and unstaged changes are reviewable, which is the normal state after an agent has been working. You do not need it to commit first, and it is generally better that it does not, so you are reviewing before anything enters history.
Is the diff review read-only?+
The review sheet itself is read-only by design, because it is for judging changes rather than editing them. You can stage and commit from the git view, and GateShell's file editor handles direct edits separately if you want to adjust something yourself rather than sending it back to the agent.
What happens with very large diffs?+
Output is bounded and the sheet discloses when a diff has been truncated. That is deliberate: silently showing part of a change while looking complete is the one failure mode a review tool must not have. For a genuinely large refactor, reviewing per file rather than as one diff is the better approach anyway.
Does this need the agent, or does it work with any changes?+
Any changes. The git view reads the repository state over your SSH connection, and it does not know or care whether a human, an agent, or a script made the changes. It is equally useful for reviewing what a colleague pushed before you pull it.
Try it in GateShell
GateShell is a zero-backend SSH client for iPhone, iPad, and Mac, with no vendor cloud, no accounts and no telemetry. Everything above works out of the box.
Guide reflects GateShell's shipped features as of September 2026. Steps assume basic familiarity with SSH and the command line; server-side commands may vary by distribution. All product names, logos, and brands are property of their respective owners.