Get another perspective on a change
AI code review examines a pull request and suggests possible problems for you to investigate. It can help draw attention to something a reviewer missed, but its suggestions can also be wrong or incomplete. Read the reasoning, check the relevant code and decide whether a change is needed.
You can use Pillion without enabling AI review. Learn the ordinary review process first. If your team wants automated feedback, a repository administrator can set it up with the steps below.
Choose a provider
A provider operates the AI service, a model is the system that analyses the code, and an API key gives Pillion permission to call that service. A provider key is separate from your Pillion access token. Your chosen service may charge for that usage.
Open repository Settings → AI review. Select a provider, choose a model if needed and enter your provider API key. For an OpenAI-compatible server, supply its model identifier and API base URL.
Select Save and check provider. When the repository has a default-branch commit and a runner is available, Pillion queues a small check of the provider setup. Follow its run link if the check fails.
If your organization has managed reviews available, you can select Pillion managed · Nebius instead. The available choices also respect your organization’s allowed-provider settings.
Enable reviews on your branches
A ruleset describes the review policy for selected branches. Open repository Settings → Rulesets, choose the branches to cover and enable AI review on the applicable ruleset. Pillion starts the review automatically for covered pull requests; you do not need to write a workflow file.
Decide separately whether AI review must pass before merging. Keep any required human approvals in the ruleset as well. Review findings are feedback to assess; a passing automated review does not establish that a change is correct.
Repository configuration
Use .pillion/review.yml on the base branch for review scope and behavior. Provider settings saved in the UI take precedence over provider configuration in that file. The file still controls the rest of the review behavior.
Keep provider keys in the settings form. They are encrypted when saved and are not shown again. Changing the provider or endpoint requires a new key; leaving the key blank while retaining the same provider and endpoint keeps the saved key.
Read results and troubleshoot
Review feedback appears on the pull request, with its execution details under Runs. Inspect the review’s run when it is queued, skipped or failed. Check the provider setup, organization policy and runner availability before retrying.
Treat each finding as a question to investigate. If it identifies a real problem, fix it on the pull request’s branch, commit and push as usual. If it misunderstands the code, explain that in the review discussion so the people reviewing the change have the context.
An attached runner used for AI review needs the matching forge-review binary available to forge-runner. Keep it updated with the service; the hosted runner image includes it.
Understand where code goes
The settings page’s Where the code goes panel shows the provider and endpoint. Review sends code context to that provider. Its processing terms and residency scope are separate from Pillion’s core repository storage.
Check this destination before enabling review for sensitive repositories. See AI features and Subprocessors for the published service information.