Reviewing AI Agent Changes with Local Arc

When an AI coding agent finishes a chunk of work, the usual review surface is either a terminal diff or a hastily-opened PR. Neither is great: terminal diffs scroll past quickly and don't carry inline comments, and pushing a PR every iteration is heavy when the code may go through five rounds before it's worth a remote review.

Local Arc sits in that gap. It captures any git diff into a local, browser-reviewable ticket — Phabricator-style — that both a person and an agent can read and write to. No remote service, no PR churn.

The Loop

The workflow I've settled on:

1. The agent finishes a change and runs local-arc diff with a title and a short description of what it did.
2. I open the ticket in the browser and leave inline comments on whatever needs another pass.
3. The agent reads the comments out of the local JSON sidecar, fixes the code, and replies to each comment as it lands.
4. The agent runs local-arc diff <range> --update T123456 to refresh the same ticket. Comments stay anchored to their lines, earlier revisions are preserved.

That's it — a tight local review loop with the same affordances Phabricator gives you remotely.

Agent Creates the Ticket

I let the agent open the diff itself. After it's done writing code, the agent runs something like:

local-arc diff HEAD~3 \
  --title "Split layout grid: support 1:2:2:1 panes" \
  --description "Rewrites movePaneInGrid to keep nested splits instead of flattening. New tests cover the 1:2:2:1 → 3:1:2 transitions."

The title and description show up at the top of the ticket, alongside the file tree and activity feed.

The "Activity" section is where comments land. Each one links back to the file and line it was attached to, so I can scroll the comment list and jump straight to context.

I Leave Inline Comments

Click any line in the diff, type a comment, save. The viewer supports side-by-side and unified modes, file filtering, and on-demand context expansion around changed blocks when the reference snapshots are available.

Comments are stored in diff.patch.comments.json next to the patch. Nothing fancy — a flat JSON file with line ranges, text, and a role field.

Agent Reads and Replies

The handoff back is the part that makes this feel like a real review. The agent reads diff.patch.comments.json, addresses each comment in the working tree, then posts a reply through the local comment API with role: "claude" (or codex, or whatever name fits) so it's obvious who said what:

{
  "parentId": "comment-id",
  "text": "Fixed — moved the check into expectSamePaneSet and added a regression test at line 72.",
  "role": "claude"
}

After it's done, local-arc diff HEAD~3 --update T153871 rewrites the ticket's current patch while preserving the comment thread and archiving the previous revision under revisions/1/. Inline comment ranges are remapped best-effort against the new file contents, so a comment on "line 41 of the test file" usually still points at the right code after the agent's edits.

Why It Works

A few things make this loop tighter than the PR-per-iteration alternative:

• No remote round-trip. The whole thing lives in /tmp/local-arc/T******/. The agent doesn't need network access or a GitHub token to participate.
• Same artifact across revisions. Updating a ticket keeps the comments anchored. You can scroll back through revisions to see what the agent changed in response to each round of feedback.
• Structured, not chat. Comments are tied to specific lines, not buried in a scrollback. The agent has a clear list of things to address rather than a wall of conversation.
• Role attribution. The role field makes it obvious which entries came from the human and which came from the agent, even when both are leaving comments and replies.

The result is something close to a real code review, but local, fast, and disposable. When the change is finally ready to leave the laptop, I send the actual PR — but by that point the back-and-forth has already happened in a place that doesn't pollute the upstream history.