The scope you grant at install decides whether an AI reviewer can block a merge

All four patterns in Graphite's guide run the same sequence. A pull request event fires. The review engine clones or fetches the diff along with project context. Static analysis runs first. Then the diff goes to an LLM that generates comments and fix proposals, and those are posted back through the GitHub API as line comments, status checks, or a request-changes review ^[6]. Downstream of that event, the four patterns diverge ^[7].

A dedicated webhook or external service stays decoupled and scales across many repositories, and because you host it, every pull request event has to round-trip to your service and back ^[8]. A GitHub Action is versioned with the repository it reviews and easy to configure, and it is bounded by Action runtime limits, per-minute cost, and handling secrets in workflow YAML ^[9]. A GitHub App or bot with review privileges can comment and approve changes automatically. The tradeoffs are careful permission management, API rate limits, and keeping false-positive comments low enough that reviewers keep reading them ^[10]. The hybrid, a webhook that triggers an Action or a serverless function, offloads the heavy work and has the most moving parts ^[11].

Of those four, only the App or bot is described as able to approve changes ^[19]. Merge gating follows from that and nothing else: an App with approval authority can gate on review status, and an Action that posts comments cannot ^[12]. The dev.to post puts the decision at install time, the day the app is granted scope. A team that wants every agent-generated change forced past a machine check before humans look needs the integration that owns status checks and merge protection ^[13].

Qodo's comparison of five GitHub review agents says "only one is built for enterprise-scale GitHub estates," and the one it names is Qodo ^[2]. The page publishes no method and no dataset ^[4]. The table gives every other tool a "No" on context depth, governance, and multi-repo awareness ^[3]. Four rivals across three axes is twelve "No" cells, all of them outside Qodo's own row ^[18].

The checks a team can run without a vendor's help are all in the same place. Does the tool install as an App, and what scopes does it ask for: write, or comment only ^[16]. Does it own a status check. Does it re-review only changed files rather than reanalyzing the whole repository each time ^[16]. The dev.to post makes the ownership argument too. The cheapest tool on paper is expensive if every repo owner has to wire a webhook or maintain a runner. An App install removes that work, but it moves permissions and rate limits onto your side of the contract. A self-hosted Action keeps it in-repo and adds to the CI bill ^[14]. For a team running hundreds of repositories, the question is whether the tool installs at all; for a single repository, an Action in the workflow file covers it ^[15].