How Tag1 Reviews Code with AI covered the tools Tag1 built to put AI into the PR review process. This post shows the pattern: AI drafts your whole review into GitHub pending reviews or GitLab draft notes, and you decide, line by line, what gets published under your name.

Where AI Fits in Code Review

AI is good at the unglamorous parts of review: actually reading every line of a large diff, knowing the obscure API pitfalls no single reviewer carries in their head, checking the change against the rest of the codebase for consistency, and asking every "what if this input is empty" question without getting bored. What it can't tell you is which of its twenty comments actually matter.

There are two ways to put that to work, and they're not in competition. The first is the one most people have seen: a bot that reads the pull request and posts its review straight to it. That's a good fit for CI and merge gating. Tag1's own ai-pr-review runs on every push, combining deterministic scanners with AI reviewers, and can gate merges on what it finds: a leaked credential, a known CVE, a phpstan error, or a logic bug an agent caught.

The second way is quieter, and easy to overlook. Both GitHub and GitLab have a staging layer for reviews: comments you write that nobody else can see until you press submit. GitHub calls it a pending review; GitLab calls them draft notes ("Start a review"). Point your AI at that layer instead of at the publish button and you get the machine's thoroughness with a person still accountable for every published word. That's what this post is about, and it's what you want when the review goes out under your name, especially when you're the gate a client is paying to stand between their code and their production site. There, the reviewer of record should be someone who read the change and chose to sign it.

The Workflow

The workflow has four steps:

  1. AI reads the PR and writes review comments into a pending review, under your account, visible only to you.
  2. You open the PR in the normal web UI, and edit, delete, or add comments like you always do.
  3. Optionally, ask the AI to look at your edited pending review and flag anything you missed or got wrong. Repeat.
  4. You press submit. Every published word is one you chose to publish, under your name. You can wire this up yourself, which is what the rest of this post covers. If you'd rather start from something prebuilt, Greg Chaix's comprehensive-review already packages the pattern: it runs the review locally and can stage its findings as a draft review for you to edit and submit.

GitHub: Pending Reviews

When you comment via "Start a review" in the Files changed tab, GitHub holds the comments in a pending review — they're "pending and only visible to you," per GitHub's docs, until you submit as Comment, Approve, or Request changes. The same states exist in the REST API: create a review without an event and it lands in PENDING; a second call to .../reviews/{review_id}/events submits it; DELETE abandons it. Each user gets one pending review per PR. GitHub doesn't seem to document this anywhere, but the API enforces it with a 422 error: "User can only have one pending review per pull request."

The detail that matters is that if the AI authenticates with your token, the pending review it creates is yours. It shows up in your browser as your own draft, fully editable.

One approach for integrating AI into human-owned reviews is the official GitHub MCP server, which wraps everything in purpose-built tools. One command connects it to Claude Code (create a Personal Access Token (PAT) with repo scope first):

claude mcp add --transport http github https://api.githubcopilot.com/mcp \
  -H "Authorization: Bearer YOUR_GITHUB_PAT"

This exposes the purpose-built tools: pull_request_review_write to create, submit, or delete a review, and add_comment_to_pending_review to add inline comments to your latest pending review. Then, prompt with something like:

Review PR #123 in tag1/example. Read the full diff. Start a pending review and add inline comments only for real problems: correctness, security, performance. Prefix each with Critical/Minor/Nit. Do NOT submit the review; I'll edit and submit it myself.

Because the agent runs as you, a second round works too: "I've edited the pending review. Read it back, tell me what I misjudged, and add pending comments for anything I missed."

The gh CLI is the more dependable approach. There's currently no native pending-review command for gh pr (no gh pr review --draft), but gh api can do it in a single call with nothing extra to install, and when Claude Code prompts you to approve the call it shows the full comment text in a readable form which the MCP doesn't.

# Create a pending review with inline comments (no "event" = stays pending)
gh api repos/tag1/example/pulls/123/reviews --input - <<'EOF'
{
  "body": "First pass by Claude; edited by Jeremy.",
  "comments": [
    { "path": "src/Form/SettingsForm.php", "line": 87, "side": "RIGHT",
      "body": "Critical: user input is concatenated into the query; use a placeholder." }
  ]
}
EOF

You then edit and submit in the web UI. The one thing gh api can't do is append comments to a review you've already started: the REST endpoint only accepts comments at creation time, and the append path needs GraphQL, as discussed in the GitHub community. That's the case where the MCP server has an advantage, since it does the GraphQL for you.

GitLab and Drupal: Draft Notes

For those of us in the Drupal ecosystem, most contribution happens through GitLab merge requests on git.drupalcode.org. Fortunately this uses the same pattern, but with different names.

In the UI, Start a review / Add to review keeps comments unpublished and visible only to you until you submit (with Approve, Comment, or Request changes). This is a Free-tier feature, so it works on any GitLab deployment.

The GitLap API calls them draft notes. To use them, you first need to point glab at the right instance (create a personal access token with api scope in your GitLab profile settings). Swap git.drupalcode.org for your own GitLab host (gitlab.com or your self-managed instance).

glab auth login --hostname git.drupalcode.org

Inline comments need diff SHAs, which come from the merge request itself. Run these inside your clone of the project:

# Get the SHAs the position object needs
glab api projects/:id/merge_requests/42 | jq .diff_refs
 
# AI (or you) stages an inline comment; nobody else sees it
glab api projects/:id/merge_requests/42/draft_notes --input - <<'EOF'
{
  "note": "Minor: this hook is missing a cache tag for the config entity.",
  "position": {
    "position_type": "text",
    "new_path": "src/EventSubscriber/CacheSubscriber.php",
    "new_line": 54,
    "base_sha": "<diff_refs.base_sha>",
    "head_sha": "<diff_refs.head_sha>",
    "start_sha": "<diff_refs.start_sha>"
  }
}
EOF
 
# Later, YOU publish, or just click "Submit review" in the UI
glab api -X POST projects/:id/merge_requests/42/draft_notes/bulk_publish

GitLab's official MCP server (beta, Premium/Ultimate) can read MR diffs and pipelines but doesn't expose draft notes yet, per its tool list, so on GitLab the dependable recipe is to let the agent read the MR however it likes, but have it stage comments through glab api .../draft_notes. Drop the commands above into your project's CLAUDE.md and Claude Code handles the SHAs and line positions itself.

Two Rules

Two simple rules guide the workflow. First, tell the AI explicitly, every time, that it must never submit, approve, or publish anything; staging comments is its entire job. Second, run it with your own credentials, because draft comments are only editable by their author, and the author should be you.

The AI delivers the efficiency: it reads every line of the diff in minutes and never gets bored or distracted. You deliver the quality: your judgment decides what's real, what matters, and how to say it to a colleague, and the AI's optional second pass over your edits catches what you missed. Because nobody else sees the pull request until you've read it, shaped it, and chosen to sign it, you stay in control of the review from first comment to submit button. You're not choosing between doing reviews faster and doing them well. Done this way, AI helps you achieve both.