Local AI Code Review: Anchoring AI Feedback to the Diff

In traditional code review workflows, developers often have to switch back and forth between the code hosting platform, AI question-and-answer tools, and the local editor. They first inspect changed files, then copy code snippets to an AI tool, and afterward reorganize the generated feedback into review comments. This process is not only inefficient, but also prone to missing context, feedback that is detached from specific code locations, and review results that are difficult to track.

A more suitable implementation for engineering teams is to connect a local intelligent coding agent directly to the merge request review workflow. The desktop application is responsible for fetching changes, organizing context, and presenting results. The local agent is responsible for analyzing code. The developer retains the final decision. This architecture does not aim to replace the reviewer with AI. Instead, it places AI judgment next to the code diff so that every piece of feedback can be checked, discussed, and handled.

1. Overall Workflow: Build Context Only Around the Current Change

This type of application typically does not require the user to pull the entire repository. It first reads the metadata of the target merge request from the code hosting platform and identifies the files involved in the change. It then copies or downloads those files into a temporary working directory and invokes the intelligent coding agent already installed on the local machine to perform the review.

A typical workflow can be abstracted as follows:

1. The user enters the merge request URL.
2. The application reads the base branch, target branch, and changed file list.
3. The application prepares only the files relevant to the current change.
4. The application reads the review rules file from the base branch.
5. The local intelligent coding agent analyzes the diff and related context.
6. The application parses review conclusions, risk levels, and code locations.
7. The results are displayed side by side with the diff.
8. The user processes each piece of feedback and publishes comments to the code hosting platform when necessary.

This approach has two clear benefits. First, the review scope is more precise, reducing interference from unrelated code in the model’s judgment. Second, the data handling process is easier to control. The application does not need to maintain a long-lived complete repository copy, nor does it need to send all project content to a remote service.

2. The Value of Local Invocation: Reducing Credential Spread

If developers have already configured an intelligent coding agent and the command-line tool for the code hosting platform on their local machines, the desktop application can reuse those local capabilities directly instead of building a new account system or storing additional access credentials.

The application itself is better suited to the role of an orchestrator:

• Preparing inputs;
• Launching local commands;
• Collecting standard output and error information;
• Parsing structured results;
• Mapping results back to specific code lines.

Credentials remain managed by the existing tools. This reduces the risk of the application storing sensitive tokens and also reduces repeated login and permission configuration. However, “not storing credentials” does not mean there is no security responsibility at all. The application may still come into contact with changed code, review rules, and generated results, so it needs to address issues such as temporary directory permissions, log content, crash dumps, and interprocess communication.

Recommended security measures include:

• Using random names for temporary directories and setting minimum access permissions;
• Cleaning up caches and intermediate files promptly after review;
• Avoiding writing source code and access tokens into debug logs;
• Strictly escaping external command arguments;
• Validating the format of agent output to avoid mistaking arbitrary text for comment instructions;
• Clearly informing users which content will be sent to the local agent or the code hosting platform.

3. Keep Feedback Attached to the Diff, Not a Generic Report

The most common problem with intelligent review is producing a summary that looks complete but is difficult to act on. For example, the model may point out that “there may be a concurrency issue here” without specifying the file, line number, trigger conditions, and direction for a fix. Placing feedback directly next to the diff can significantly improve this.

Each piece of review feedback should contain at least the following information:

• File path;
• Relevant code line or line range;
• Issue type;
• Risk level;
• Cause of the issue;
• Suggested modification;
• Whether the merge should be blocked immediately.

Code location is especially important. Location is not decorative information; it is the foundation for making feedback verifiable. Developers can jump directly from a comment to the changed line, check whether the model misread the context, and then decide whether to accept, reject, or defer the issue.

The interface can group review feedback into several categories:

• Defects: issues that may cause incorrect results, abnormal behavior, or data corruption;
• Security: issues involving permissions, input validation, sensitive information, and boundary bypasses;
• Performance: issues that may introduce unnecessary computation, queries, or resource usage;
• Maintainability: issues affecting readability, extensibility, or future troubleshooting;
• Conventions: violations of project conventions that do not necessarily affect runtime results.

Categories help prevent all suggestions from being treated as equally severe, and they also make it easier for teams to track review quality over time.

4. Risk Scoring Should Be Explainable, Not a Replacement for Judgment

The application can calculate a risk score from 0 to 100 for each merge request to help reviewers prioritize attention. However, the risk score should not become the sole basis for automatic approval or automatic rejection.

A relatively robust design is to first calculate a base score from objective characteristics of the diff, and then allow the intelligent agent to make adjustments within a limited range. For example, the base score can consider:

• The number of changed files;
• The number of added and deleted code lines;
• Whether permission, authentication, or data access logic is modified;
• Whether database schemas, configuration, and deployment scripts are involved;
• Whether public interfaces are modified;
• Whether tests are missing;
• Whether high-complexity or highly coupled code is included.

The intelligent agent can make limited corrections to the base score based on semantic judgment, but it must also provide the rationale and associate it with specific files and code lines. This uses the model’s understanding of business semantics while avoiding a risk score determined entirely by unexplainable generated output.

Risk scoring should also provide confidence or explanatory text. For example:

Base risk: medium. The change involves public interfaces and exception handling logic.
Reason for increase: a new parameter lacks boundary validation, and the relevant location is on a changed line in a specific file.
Reason for no increase: existing tests cover the main success path.

This kind of expression is more valuable than displaying a number alone, because developers can understand where the score comes from.

5. Review Rules Must Come from the Base Branch

Project rules are key to whether AI review works consistently. Common rules include code style, testing requirements, error handling conventions, log redaction requirements, and restrictions on changes to specific directories.

To prevent a merge request from influencing its own review by modifying rule files, rules should be read from the base branch rather than from the branch under review. The application can define several general rule files to recognize, such as review notes in the project root directory, intelligent coding agent instructions, or team convention files.

The rule loading process should follow these principles:

1. The rule source is fixed to the base branch.
2. Rule files with the same name in the branch under review do not override base rules.
3. Rule files need size and format limits.
4. Rule content should be consistent with repository permission boundaries.
5. Conflicting rules should have a clear priority.

In addition, the agent should not receive only rule files, nor should it be forced to read the entire repository. A more reasonable context combination is: base branch rules, changed files, necessary adjacent code, and interface or test files that are genuinely related to the change. The more precise the context, the easier it is to verify the review conclusion.

6. Boundaries of Automation: Only Routine Feedback Should Be Auto-Processed

When human review resources are limited, a limited automation mode can be added. For example, the system can pre-process only feedback that is low-risk, clearly formatted, and does not require business judgment, while returning security, data consistency, permissions, and public interface changes to human reviewers.

However, the automation mode must meet several prerequisites:

• It runs only while the desktop application is running;
• It does not automatically publish external comments by default;
• It keeps a record of every automated action;
• It allows users to pause or revoke actions at any time;
• High-risk merge requests are automatically downgraded to manual review;
• Automation is forcibly disabled when sensitive directories are involved.

It is especially important to note that when comments are published automatically, they are usually created under the current user’s identity. This means the behavior may affect team collaboration records, personal permission audits, and organizational compliance requirements. Therefore, before enabling automation, users should confirm the rules of the local agent, the code hosting platform, and the organization regarding automatically generated content.

7. Recommended Adoption Path

When a team uses this type of application for the first time, it should not enable fully automated review for all projects immediately. A more prudent sequence is:

In the first phase, perform local analysis only and do not publish any comments, so that false positive and false negative rates can be observed.

In the second phase, allow users to confirm feedback item by item before publishing, and track which types of suggestions are most often accepted or rejected.

In the third phase, establish automatic processing conditions for low-risk checks with clear rules, while retaining manual confirmation for high-risk paths.

In the fourth phase, periodically review risk scores, comment quality, and rule hit rates, and update project review conventions.

Ultimately, the core value of this type of application is not “letting AI automatically review all code.” It is establishing a transparent, traceable, and intervenable collaboration chain: code changes are prepared by the local environment, the intelligent agent provides analysis, the interface displays evidence, the developer makes the decision, and the code hosting platform keeps the final record. Only when every step has clear boundaries can AI truly become an assistant for code review rather than a new source of uncontrolled risk.