Send AI PR Review Inline Comments to GitHub

A pull request with 14 changed files does not need another generic bot summary. It needs comments on the exact line where a retry loop can duplicate a charge, where a permission check is missing, or where a migration will lock a production table. AI PR review inline comments to GitHub turn an agent's analysis into work the author can inspect, discuss, resolve, and prove.

That distinction matters when AI agents are writing meaningful portions of a change. A review that lives only in a chat window, terminal transcript, or detached dashboard loses the code context that makes it useful. GitHub pull requests are where engineering teams already make decisions. Put the evidence there.

Why inline comments are the useful unit of AI review

A review-level summary can tell an author that a PR has three concerns. It cannot reliably show which condition is unsafe, what execution path triggers the issue, or whether a proposed fix applies to the current diff. Inline comments anchor the review to a file, a line, a side of the diff, and a specific commit.

That anchor changes the interaction. Instead of reading, "Potential authorization issue in the API," an author sees a comment on apps/api/src/routes/export.ts:84: "projectId is read from the request body before membership is verified. A user with access to one project can supply another project ID here. Derive it from the authorized resource or validate membership before calling createExport." The author has enough information to evaluate the claim without reconstructing the reviewer’s path through the repository.

For an AI reviewer, this also forces discipline. The agent must tie each finding to code that exists in the submitted diff. It cannot hide weak reasoning behind a broad warning. If it cannot identify a relevant line, it may still leave a PR-level note, but that should be the exception for cross-cutting concerns such as an incomplete rollout plan or a missing operational decision.

What GitHub needs to place a comment correctly

Posting a comment is easy. Posting it on the right line of a moving pull request is the engineering problem.

GitHub review comments are attached to a pull request and a commit SHA. For a changed line, the reviewer also needs the file path, the diff side (LEFT for removed code or RIGHT for added code), and the line number as represented in the pull request diff. Multi-line comments need valid start and end positions. An agent that uses line numbers from a local working tree without checking the PR diff can produce misplaced comments or fail to publish them at all.

A reliable workflow begins by fetching the current PR head SHA and changed-file patches. The agent reviews that immutable snapshot, records each finding against the diff, and submits the comments against the same SHA. If a new commit lands while review is running, the system should not silently attach old analysis to new code. It should mark the review stale, rebase its context on the new head, or ask for a rerun.

The comment body needs structure, not theater. A useful format usually contains the severity, the concrete behavior, the trigger, and a focused recommendation. For example:

High - This catch block converts a failed idempotency lookup into a new payment attempt. During a transient Redis outage, the same webhook can charge twice. Return a retryable error instead of continuing when the lookup fails.

That is better than a vague claim that the code "may have edge cases." It gives the author a test case and a decision to make.

Build a review workflow that survives agent handoffs

The strongest AI review loop starts before the agent reads a diff. A PR is not just changed code. It is the implementation of an intended outcome, usually defined somewhere else.

Take PAY-1842, a Jira ticket to add idempotent Stripe webhook processing. The ticket contains acceptance criteria, a linked Sentry issue shows duplicate-charge reports, and the PR is #482 in acme/payments-service. A context-aware workflow carries those inputs into the review session. The agent can then test the diff against the actual job: duplicate delivery, transient cache failure, concurrent processing, and observability for failed attempts.

Without that context, an AI reviewer may produce correct but low-value style feedback while missing the failure mode the ticket exists to fix. More comments do not mean more coverage.

The execution sequence should be visible:

1. A ticket or PR event identifies the repository, branch, acceptance criteria, and linked evidence.
2. The reviewer loads the current diff, relevant repository instructions, targeted tests, and recent implementation history.
3. It writes inline findings only where it can make a specific, defensible claim.
4. GitHub receives a pending review, followed by a submitted review state such as comment, approve, or request changes.
5. The author responds, pushes a fix, or explains an intentional trade-off. The next review runs against the new head SHA.
6. Status returns to the originating ticket and team thread with the PR number, check result, and remaining action.

The list is not bureaucracy. It creates a traceable chain from requirement to code to review to resolution. When the original developer is offline, the next person does not need to ask what the agent knew, which revision it inspected, or why it raised a concern.

Calibrate comment volume before people mute the bot

Inline feedback has a cost. Ten accurate comments on naming, formatting, and minor abstractions can bury one comment about data loss. Teams need a comment policy, not simply a capable model.

Start by separating blocking findings from advisory observations. Security boundary failures, correctness bugs, data integrity risks, broken acceptance criteria, and test failures deserve high-priority treatment. Maintainability feedback can be useful, but it should be limited to changes that materially reduce future risk. Style belongs in linters, formatters, or existing repository conventions.

Confidence should affect behavior as well. A high-confidence bug with a reproducible path can request changes. A plausible concern that depends on an external contract should be framed as a question and linked to the relevant code path, not presented as certainty. The agent should never approve a PR merely because it found no obvious issue. Approval means the configured review scope completed, required checks are known, and no blocking concern remains within that scope.

It also depends on the repository. A small internal admin tool may tolerate broad advisory notes. A payments service, identity provider, or schema migration needs a narrower, higher-signal bar. Tune rules by directory, service ownership, language, and risk level instead of applying one global prompt to every pull request.

Keep humans in control of the GitHub state transition

An AI agent can generate a patch, run tests, inspect a PR, and post its analysis. It should not erase the decision boundary between analysis and merge authority.

GitHub provides useful states for that boundary. A comment review can surface non-blocking guidance. A request-changes review can stop a risky diff until an owner responds. An approval can be allowed for low-risk paths only when team policy permits it. Required human approvals, CODEOWNERS rules, branch protection, and CI checks remain the controls that protect the main branch.

This matters most outside a desktop workflow. A staff engineer might receive a mobile notification that #482 has one high-severity review comment and all tests are green. They should be able to open the exact diff, approve a safe correction, redirect the agent with a precise instruction, or pause the task. They should not have to reopen a laptop and rebuild the session context just to answer a review question.

CodeAgent Mobile is built around that continuity: preserve the ticket, repository, agent history, diff, review state, and next action across devices. The goal is not autonomous merging. It is keeping accountable work moving when the person responsible is away from the editor.

Measure whether the review is improving delivery

Do not judge AI PR review by comment count. Track how often inline comments lead to accepted changes, how many are marked incorrect or irrelevant, median time from comment to resolution, and escaped defects in categories the reviewer was expected to catch. Review these metrics by repository and rule set.

A low acceptance rate may mean the agent lacks repository context, is reviewing generated files, or is configured to comment on issues already covered by static analysis. A long resolution time may indicate that comments identify real problems but fail to propose a testable next step. Those are workflow defects, not reasons to add a larger prompt.

The useful end state is simple: every meaningful AI finding appears where the code decision happens, every comment is tied to the reviewed revision, and every unresolved concern has an owner. That gives AI agents room to move quickly while keeping the pull request as the shared record of what changed, why it changed, and who accepted the risk.