An AI reviewer leaves six comments on a pull request. Two identify a genuine problem, three misunderstand the code and one suggests a tidy refactor. Who decides which comments matter, and what evidence is needed before merging?
That is the useful question for a small product team adding AI code review to GitHub. The review should help someone make a better decision about a change. A long comment thread is not the result you are trying to buy.
This guide shows a practical workflow using an illustrative customer-account check. It is for teams already using pull requests, including founders working with an internal team or an outside development partner. The example is fictional, not a finding from an Ekyon client repository.
How AI code review works on GitHub
GitHub Copilot and third-party tools can inspect pull request changes and produce review feedback. With Copilot, first check the current code review availability and configuration. Access depends on plans and organizational policies. Some organization members without individual licenses can use it when the relevant owner enables the required settings and paid usage.
For a first trial:
- Confirm that the tool is approved to access the repository, including any confidential code. Review its permissions and data terms.
- Open a focused pull request with a description of the intended behavior and the tests run.
- Request the AI reviewer using the supported review control. For Copilot, follow GitHub's requesting a code review instructions.
- Read its comments alongside the diff and test results. Assign a person to investigate relevant findings.
- After changes, verify the updated commit and obtain the review your team requires before merging.
Automatic review can be useful after the team understands the feedback. Start with a few representative changes, rather than applying a new required workflow everywhere before seeing how it behaves.
A worked example: can one customer read another customer's invoice?
Suppose a pull request changes an invoice endpoint. The author has added a successful sign-in check. The endpoint then loads an invoice using an identifier from the request.
The important business rule is: a signed-in customer must only read invoices that their account is allowed to access. Authentication alone does not establish that permission.
This is the kind of object-level authorization concern described by OWASP's API security guidance. The review needs to examine the access decision, not just whether a login helper was called.
| Review step | Evidence to look for |
|---|---|
| Explain the rule | The PR description names who may read an invoice and any authorized administrative exception. |
| Follow the request | Identify where the invoice identifier and the customer's account context come from. |
| Check the access decision | Confirm that server-side authorization checks the requested record against the authenticated actor's permissions. A client-supplied account field is not sufficient evidence. |
| Exercise the failure case | In an authorized test environment, customer A must not receive customer B's invoice. Check the response and the returned data. |
| Preserve the valid case | A customer with the appropriate permission can still read their own invoice. Cover authorized administrative behavior separately if it exists. |
| Verify the repair | Run the relevant tests against the revised commit and have the responsible reviewer inspect the access path. |
An AI reviewer might identify the missing check. It might also miss a shared middleware rule, misunderstand an administrative exception or propose a change that breaks an allowed use case. The human reviewer must resolve the question using the actual application and its requirements.
A useful finding says which path is affected, what assumption fails and how the team can verify it. “Improve security here” gives the author too little to act on.
Give the reviewer context it can use
A focused review request can accompany the PR description or the tool's supported repository instructions:
Review the changed invoice endpoint and its authorization path.
Intended rule: a customer can read only invoices their account
is permitted to access. Administrative access has its own rule.
For each finding, identify the file and behavior, the failed
assumption, and a test that would confirm or reject the concern.
Distinguish evidence from missing context. Do not invent results
for checks you have not run.
This is an example instruction, not a claim that a particular reviewer will follow it perfectly. Include the relevant permissions model, migrations or dependent code when the review surface supports them. Keep real credentials and customer records out of prompts and test fixtures.
When evaluating feedback, record whether a finding was confirmed, rejected with a reason or left unresolved. If a suggestion changes behavior, verify that behavior. Accepting a generated patch does not establish that it is correct.
Keep merge controls separate from review comments
Decide what must be true before a change reaches the release branch. GitHub's protected branch documentation explains supported review requirements, status checks and bypass behavior. Availability varies with repository visibility and plan.
For a team relying on AI-assisted development, a useful starting policy is:
| Control | Practical decision |
|---|---|
| Required checks | Name the relevant tests, type checks or build jobs. Confirm they run against the commit being merged. |
| Human responsibility | Name who reviews changes to permissions, billing, migrations and other important behavior. Use owner review requirements where supported and appropriate. |
| Review freshness | Decide when a new commit needs another review. Avoid treating approval of an earlier diff as evidence for later changes. |
| Exceptions | Identify who can bypass the normal path, why an exception is allowed and how it is recorded. |
GitHub's current code review documentation also describes optional Copilot approvals in public preview. Their ability to satisfy required approval settings depends on configuration. Our recommendation is to retain accountable human review for important product and access-control decisions, even when the platform permits other arrangements.
Checks provide evidence within their coverage. They do not prove that every behavior is correct or that a release has no vulnerabilities.
Secret and dependency checks have their own requirements
AI review is not a replacement for appropriate repository security checks. Before making a security feature part of your policy, confirm that it is available and enabled for the repository.
GitHub's secret-scanning setup documentation explains eligibility. For organization-owned private and internal repositories, access can depend on GitHub Secret Protection and the organization's plan. Do not assume every private repository has the same controls as a public repository.
Scanning can flag supported patterns; a clean result does not prove that no secret exists. Treat a confirmed exposed credential as a remediation task, including revocation or rotation through the appropriate owner. Dependency alerts likewise need someone to assess relevance and implement a suitable repair. A bot comment alone does not resolve either issue.
Measure whether AI review is helping
For a small trial, use a short review log. Record the PR, confirmed useful findings, rejected findings, unresolved concerns and the follow-up work. Ask the people doing the reviews whether the tool helps them find and resolve meaningful problems.
Comment count is a poor substitute for that evidence. A quieter review that identifies one reproducible permission bug can be more useful than many speculative style comments. Avoid claiming a percentage improvement in review speed or defect detection without your own comparable data.
When the question is larger than the pull request
A PR review is most useful when the intended change and its surrounding requirements are understood. A launch or handover can raise different questions: how permissions work across the application, where sensitive data flows, how the system is deployed and which dependencies or operational gaps need attention.
Those questions may justify a separately scoped code audit. Bring the stack, repository boundaries and the decision you need to make. We agree the review scope and access first, then report evidence, limitations and a prioritized repair plan. An audit does not certify that a system is free of vulnerabilities, and implementation work is separately agreed.
For a practical starting brief, use our code audit services checklist. Keep ordinary PR review in place while assessing the wider codebase.
Need an independent view before a launch or handover?
Share your stack and the decision you need to make. We will discuss a scoped code review and the evidence it should produce. Do not send credentials or production data with the first enquiry.
Frequently Asked Questions
Yes. GitHub Copilot and third-party tools can provide review feedback. Check current plan availability, organizational policies, repository permissions and billing before enabling a tool. The supported setup and review controls depend on the product.
That is a team policy decision, not a safety guarantee from the tool. GitHub documents optional Copilot approvals whose treatment depends on configuration. Ekyon recommends accountable human review for important product logic, permissions and release decisions, alongside relevant tests.
A useful finding identifies the affected behavior, explains the concern using evidence and gives a way to verify it. A reviewer should resolve missing context, test proposed changes and record why a finding was confirmed or rejected.
No universal availability should be assumed. Check GitHub's current documentation for the repository type, account and product. Organization-owned private and internal repositories can require GitHub Secret Protection and an eligible plan.
Consider a separately scoped audit when launch or handover questions extend beyond one change, such as cross-application permissions, sensitive data flows, dependencies and deployment. Scope, access and limitations should be agreed first; neither an audit nor a clean PR review proves an application has no vulnerabilities.
Sources and review date
Feature statements were checked against the linked GitHub documentation on October 22, 2026. The authorization example is an illustrative review exercise. Product availability, preview behavior and account settings can change, so check the current documentation before applying a repository policy.
Want a senior review of your codebase?
Ekyon audits AI-built and fast-shipped products for security, architecture, maintainability, and launch risk.
