AI code review is becoming more useful for a simple reason: it can now review against your team’s standards and delivery context, not only generic programming advice.
On 29 July 2026, GitHub made agent skills and Model Context Protocol (MCP) support in Copilot code review generally available. Teams can give reviews repository-specific guidance, invoke approved internal tools, and bring in read-only context from systems such as documentation, issue trackers and service catalogues. That creates a practical opportunity for businesses: automate the repetitive first pass of review while keeping engineers responsible for what merges.
The important question is not whether an AI can leave comments on a pull request. It is whether those comments reflect your architecture, security controls, accessibility obligations, definition of done and operating environment.
What Changed in July 2026?
GitHub’s 29 July release moved two Copilot code review capabilities from public preview to general availability for Copilot Pro, Pro+, Business and Enterprise users:
- Agent skills: teams can add a
SKILL.mdfile inside a skill-specific directory under.github/skills. A skill can provide repository or organisation-specific context and instructions, and can invoke approved internal tools during review. - MCP server connections: code review can retrieve relevant context from connected systems such as issue trackers, documentation platforms and service catalogues. GitHub states that MCP tool calls made by Copilot code review are limited to read-only.
- Attribution: review comments now indicate when an agent skill or MCP context contributed to the result, helping reviewers understand where the advice came from.
Earlier in July, GitHub also added a default firewall for Copilot code review, separate runner configuration, custom setup steps through .github/workflows/copilot-code-review.yml, and support for review guidance held in files including AGENTS.md, REVIEW.md, GEMINI.md and CLAUDE.md. One caveat matters: GitHub says the firewall is not currently supported for self-hosted runners.
These are product capabilities, not a quality guarantee. They make a better review system possible; the team still has to design that system well.
The Useful Pattern: Encode Standards Once, Apply Them Repeatedly
Most organisations already have review knowledge, but it is scattered across senior engineers, architecture documents, tickets and hard-won lessons. The practical opportunity is to turn suitable parts of that knowledge into explicit, testable review rules.
A repository-specific review skill might ask the reviewer to check:
- whether authentication and authorisation decisions happen server-side;
- whether new API endpoints include validation, error handling and audit logging;
- whether personal or sensitive data is excluded from application logs;
- whether database changes include a safe migration and rollback approach;
- whether user-interface changes meet the project’s accessibility requirements;
- whether Drupal or GovCMS work follows the project’s approved module, configuration and deployment patterns;
- whether a change includes the unit, integration or end-to-end tests required by its risk level.
That is much more valuable than asking an AI to “review this code”. It gives the system a defined job and gives the human reviewer a visible basis for assessing its comments.
A Practical Review Workflow
For most teams, we recommend treating AI review as an additional automated gate — not as the final approver.
- 1. Start with deterministic checks. Run formatting, linting, type checks, unit tests, dependency scanning, static analysis and secret detection first. Do not ask an AI to replace controls that conventional tooling can enforce reliably.
- 2. Add a narrow review skill. Begin with one high-value concern, such as API security, accessibility or migration safety. Keep the guidance concise enough that developers can inspect and maintain it.
- 3. Provide only the context required. Use read-only MCP access where external context is genuinely useful. A review may need the acceptance criteria for a ticket or the current service standard; it rarely needs broad access to every internal system.
- 4. Require evidence in comments. Useful review feedback should identify the affected file or behaviour, explain the risk, and suggest a verifiable correction. Vague comments create noise and train developers to ignore the reviewer.
- 5. Keep human approval. A qualified engineer remains accountable for architecture, business logic, security decisions and the merge itself.
- 6. Measure the result. Track accepted suggestions, false positives, escaped defects, review time and change-failure rate. More comments are not evidence of better review.
This extends the principle in our recent article, Where AI Actually Pays Off in Software Development: AI delivers the best return on bounded, verifiable work. Repository-aware code review is a strong example because it sits inside an existing pull-request, test and approval process.
What Belongs in a Review Skill — and What Does Not?
A good skill contains stable guidance that improves a reviewer’s judgement. It should be versioned with the code and changed through the same review process.
Good candidates include:
- project architecture boundaries and approved integration patterns;
- security and privacy checks specific to the application;
- testing expectations by change type or risk level;
- accessibility and content requirements;
- framework-specific conventions for React, Angular, Drupal or GovCMS;
- the evidence a reviewer should request before approving a change.
Poor candidates include:
- secrets, production credentials or sensitive personal information;
- large policy documents pasted without prioritisation;
- instructions that pretend preference is enforceable policy;
- rules that can be expressed more reliably as a linter, test or branch protection setting;
- permission for the reviewer to merge, deploy or modify external systems.
GitHub’s Visual Studio July update makes a related distinction explicit: organisation-level custom instructions are intended for shared preferences, not for enforcing policy. Genuine controls still belong in branch protection, identity and access management, CI/CD, security scanning and human approval.
Security and Governance Still Matter
Connecting an AI reviewer to more context can improve its judgement, but every connection also expands the system that must be governed. Before enabling an MCP server or internal tool, establish:
- Purpose: what review decision requires this data?
- Scope: which repositories, projects and records can it read?
- Identity: which service identity is used, and how is access revoked?
- Data handling: what information may be sent to the model or retained in logs?
- Network boundaries: which destinations are allowed, including differences for hosted and self-hosted runners?
- Auditability: can the team identify when external context influenced a comment?
- Fallback: what happens when the context service is unavailable or supplies stale information?
For Australian Government work, this should sit inside the agency’s broader governance rather than becoming a developer-only experiment. The Australian Government’s Policy for the responsible use of AI in government requires a coordinated approach to strategy, oversight, operations and use-case impact assessment. The DTA’s guidance for moving AI proof-of-concepts to scale also emphasises enterprise-ready infrastructure, robust governance, measurable outcomes and selecting technology for the problem rather than its novelty.
A Sensible 30-Day Pilot
You do not need to redesign the entire delivery process at once. A useful pilot can be deliberately small:
- Week 1: select one repository and analyse recent review defects, delays and recurring comments.
- Week 2: create one narrowly scoped skill, add missing deterministic checks, and test against historical pull requests.
- Week 3: enable it for a small development team with human approval mandatory and MCP access disabled unless clearly justified.
- Week 4: compare review time, useful findings, false positives and escaped issues against the baseline. Keep, revise or remove the skill based on evidence.
The outcome may be that one carefully maintained skill is valuable and ten generic ones are not. That is a successful pilot: the goal is a better delivery system, not maximum AI usage.
Working with NAITEC Digital
NAITEC Digital helps businesses and government teams introduce AI into real software delivery processes without weakening engineering controls. We can assess your current review and CI/CD workflow, identify suitable automation points, encode project-specific standards, and integrate the result with secure testing and approval gates.
We are a Newcastle, NSW software consultancy, a BuyICT registered supplier, and GovCMS/Drupal specialists on the Drupal Services Panel. Our work spans AI integration, custom software, React and Angular delivery as well as secure government digital platforms and GovCMS services.
If your team wants an AI reviewer that understands how you actually build — rather than another source of generic pull-request comments — talk to NAITEC Digital.
Frequently Asked Questions
Can AI code review replace a human reviewer?
No. It can automate a useful first pass, apply repeatable checks and surface risks, but a qualified engineer should remain responsible for business logic, architecture, security decisions and approval to merge.
What is an agent skill in GitHub Copilot code review?
An agent skill is repository or organisation-specific guidance stored in a SKILL.md file under .github/skills. It can give Copilot code review relevant standards, context and approved tool-based procedures for a particular type of review.
What does MCP add to code review?
Model Context Protocol connections can supply read-only context from approved external systems, such as issue trackers, documentation or service catalogues. That can help a review compare a change with acceptance criteria or internal standards, but access should remain narrowly scoped and governed.
Should policy be placed in AI custom instructions?
Custom instructions can explain standards and preferences, but they should not be treated as enforcement. Mandatory controls belong in tests, branch protection, security tools, access controls, CI/CD gates and human approval.
How should a business measure an AI code-review pilot?
Measure accepted and rejected suggestions, false positives, human review time, defects escaping review, and delivery outcomes such as change-failure rate. Comment volume by itself is not a meaningful success metric.
Can NAITEC Digital help implement AI-assisted code review?
Yes. NAITEC Digital can assess your repositories and delivery workflow, design a bounded pilot, create project-specific review guidance, strengthen automated checks and establish the security and governance needed for safe adoption. Contact us to discuss your development process.