GitHub announced on October 2, 2026 that teams can request a GitHub Copilot code review API review through REST and GraphQL, optionally selecting the review effort for each request. The feature is generally available on Copilot Pro, Pro+, Max, Business, and Enterprise plans. For QA teams, the useful shift is operational: an AI review can now be started from a CI workflow, release checklist, or internal quality portal instead of only from the pull-request UI.
What GitHub changed
According to GitHub’s changelog, supported REST and GraphQL APIs can request a Copilot review and set its effort level for that individual request. GitHub also confirmed that Default effort now resolves to Balanced for new and existing organizations and repositories that use Copilot code review; an explicitly selected Lite setting remains unchanged.
This is separate from September’s settings expansion. That update focused on where teams configure review preferences. The October 2 update adds an automation entry point, so a pipeline can deliberately request the depth it needs for a particular change.
A practical QA gate
Use the API as a review trigger, not as a merge decision. A sensible rollout is to request a review after unit, API, and browser suites finish, then collect the resulting comments as evidence for a human reviewer. Start with a narrow pilot: test-heavy pull requests, framework upgrades, or changes touching authentication and payments.
- Define when the workflow calls the Copilot review endpoint—for example, after required tests pass.
- Choose and record the requested effort level in the workflow log.
- Route findings to the pull request and require an owner to classify each one: fixed, accepted risk, duplicate, or false positive.
- Measure useful findings, review latency, and false-positive rate before making the gate broader.
Why this matters for QA engineers
Automation testers often need repeatable evidence that a change received the same quality checks each time. Per-request effort selection can make that policy visible: a low-risk documentation change can follow one path, while a test-helper, locator, retry, or access-control change can ask for a more deliberate review. The API does not prove correctness, and it does not replace test execution, exploratory testing, security review, or accountable approval. It gives teams another configurable signal to validate.
Validate the integration before relying on it
- Use a disposable repository and known seeded defects to verify that the request is made only at the intended workflow stage.
- Confirm permissions, failure behavior, and retry handling; a failed review request should be observable rather than silently skipped.
- Compare Lite, Balanced, and any available options against a fixed PR set. Do not assume a more intensive setting is automatically more useful for your codebase.
- Keep human ownership of triage and release decisions, especially when the review comments affect test coverage or security-sensitive behavior.
What to do next
Review the GitHub documentation for the exact REST or GraphQL operation and the required token permissions, then pilot one workflow with a small set of pull requests. Treat the GitHub Copilot code review API as a measurable QA control: define the trigger, preserve the review evidence, and decide based on observed outcomes—not on an agent’s recommendation alone.