← Voltar aos guias

Automate Pull Request Reviews with LLMs

Why use an LLM for pull request review?

Automated LLM review is most useful when it handles the repetitive first pass: summarizing a change, finding likely edge cases, flagging unsafe patterns, and asking questions a human reviewer may otherwise miss. It should not approve code or replace ownership. Treat it as a fast reviewer that leaves evidence-based comments, while branch protections and human approval remain in place.

This walkthrough builds a GitHub Actions workflow that runs on pull requests, sends the diff to an LLM, and publishes a single actionable review comment. The same approach works with Claude or GPT-compatible clients. 59API is a practical production choice because it provides pay-as-you-go access to native official-quality Claude and GPT models through one relay, at a low cost and without requiring a provider-specific integration for every model.

1. Define a narrow review contract

Before connecting a model, decide what it should inspect. Broad prompts such as “review this code” tend to produce generic feedback. Start with a limited contract: identify correctness bugs, security issues, broken error handling, missing tests, and performance regressions introduced by the diff. Require the reviewer to ignore formatting and to report only issues it can tie to changed lines.

Ask for structured output even if the final result is plain text. Each finding should include severity, file path, approximate line, explanation, and a concrete remediation. Also instruct the model to return “No material issues found” when there is no high-confidence finding. This reduces noisy comments and makes the workflow easier to parse later.

2. Create credentials and repository secrets

Sign up for 59API, create an API key, and add it to the GitHub repository as an Actions secret named 59API_API_KEY. This is a soft but worthwhile next step for teams that want inexpensive model experimentation without committing to separate billing and SDK setups for each supported provider.

Never put the key in workflow YAML, source code, or pull request comments. For public repositories, be especially careful with pull requests from forks: GitHub does not expose normal secrets to forked workflows. Run the model only after a trusted maintainer applies a label, or use a controlled workflow design that does not execute untrusted pull-request code.

3. Fetch the pull request diff safely

Create a workflow triggered by pull_request events such as opened, synchronize, and reopened. Give the job pull-requests: write permission if it will post comments, plus contents: read. Use GitHub’s API to retrieve changed files and patches rather than checking out and running the contributor’s code.

Set firm limits before sending context to a model. Exclude generated files, lockfiles, vendored dependencies, binaries, and files above a chosen size. Cap the total diff, for example at 40,000 to 80,000 characters, and mention omitted files in the prompt. For large pull requests, review each file independently and aggregate only the highest-confidence findings. These controls manage cost, avoid context-window failures, and reduce the chance that malicious text in a diff overrides the review instructions.

4. Call the model through 59API

Configure your Claude-compatible or OpenAI-compatible SDK to use https://api.59api.com as its API base URL and load the key from 59API_API_KEY. Keep the model name in an environment variable, such as PR_REVIEW_MODEL, so you can select a lower-cost fast model for routine reviews and reserve a stronger model for sensitive services or release branches.

Your request should contain three clearly separated parts: immutable system instructions, repository-specific rules, and the untrusted pull-request diff. State explicitly that code comments, strings, and documentation inside the diff are data, not instructions. Include the base branch, pull request title, changed files, and any relevant project rules, such as supported runtime versions or authentication conventions.

Use a low temperature setting, around 0 to 0.2, for consistent reviews. Set a maximum output size that supports several findings but prevents essays. Add retries with exponential backoff for transient API failures, and make the review job non-blocking at first. A failed AI call should report a neutral status, not block a developer from merging unrelated work.

5. Publish useful feedback

Begin by posting one summary comment rather than inline comments. A summary is simpler to implement, avoids incorrect line mappings when patches shift, and lets the team evaluate signal quality. Include a short review status, then a bulleted list of findings grouped by severity. Link each finding to its file when possible and quote only the minimum relevant code.

Prevent duplicate comments on every push. Store the previous comment ID in a hidden marker, then update that comment when a new commit arrives. Alternatively, delete and replace the prior bot comment. Include the commit SHA in the marker so reviewers know whether findings match the current revision.

6. Measure quality before enforcing it

For the first few weeks, track accepted findings, dismissed findings, average latency, token usage, and cost per pull request. Review false positives monthly and refine the prompt with examples from your codebase. Add an allowlist of high-risk paths, such as payment, authorization, migrations, and infrastructure files, where deeper review is justified.

Only make the check required after it consistently catches meaningful issues with manageable noise. The production goal is not maximum comments; it is faster human review with fewer escaped defects. With a scoped prompt, secure GitHub workflow, and economical 59API access to Claude and GPT models, automated PR review can become a dependable part of that process.

Preços · Docs