When AI moves from commenting to changing code: what changes in code review

GitHub introduces new options to apply Copilot code review feedback through Copilot cloud agent. An operational view on workflows, governance and controls for software teams.

From suggestion to fix: the operational shift

GitHub announced in its changelog an update to Copilot code review: the previous “Implement suggestion” button has been renamed “Fix with Copilot” and is now paired with a dialog that gives users more control over how suggestions are applied. According to GitHub, a developer working on a pull request can choose whether to apply the change directly to the current PR or open a new pull request against the branch, select the model to use and add further instructions. The new “Fix batch with Copilot” command also allows multiple review comments to be grouped and assigned to Copilot cloud agent.

On its own, this may look like a product experience refinement. For an organisation that builds software, however, the point is broader: AI is no longer limited to producing a comment or a textual proposal. It enters a workflow stage where it can generate code changes that may be applied to a repository. This shifts the discussion from individual productivity to process governance.

In traditional code review, the flow is relatively clear: a reviewer identifies an issue, the author changes the code, the team verifies the result. With AI agents embedded in the development platform, part of this step can be accelerated or automated. The potential benefit is reducing friction on repetitive fixes, small refactorings, style corrections, test updates or adjustments to internal conventions. The risk is treating the agent’s output as a neutral shortcut, while it actually becomes a new source of change inside the repository.

What teams should decide before enabling similar workflows

The first decision concerns scope. Not all repositories carry the same risk profile: an experimental internal library, a payment backend, a healthcare component or a regulated data pipeline should not follow the same intervention rules. Before enabling agentic functions in code review, teams should classify repositories by criticality, exposure, dependencies and business impact.

The second decision concerns how changes are integrated. The option described by GitHub — applying the fix to the existing PR or opening a new pull request — is not just a matter of convenience. Applying changes directly to a PR may be efficient, but it can make the boundary between human contribution and AI contribution less visible. Opening a separate PR adds steps, but improves traceability, review and auditability. For mission-critical code, the latter may be the more cautious default.

The third decision concerns instructions and models. If a tool allows model selection or additional instructions, teams should avoid free-form, inconsistent prompts. It is better to define prompt templates, repository guidelines, coding standards, testing rules and explicit limits: for example “do not change public APIs”, “do not modify data schemas without a migration”, “do not introduce new dependencies”, or “keep compatibility with the declared runtime version”.

Finally, responsibility must remain clear. A change proposed or applied by an agent does not remove the maintainer’s accountability. Merging must remain a controlled act, approved by authorised people or roles and supported by automated tests and checks. In practical terms: the agent can reduce manual effort, but it should not replace technical responsibility.

Minimum controls: testing, security, audit and permissions

The adoption of AI agents in the software development lifecycle should start from the controls already expected in modern delivery, not bypass them. Every AI-generated or AI-assisted change should pass through the same gates as human changes: builds, unit tests, integration tests, linting, type checking, dependency scanning, secret scanning and SAST checks where relevant.

A common mistake is to evaluate these tools only as delivery accelerators. In reality, they increase the need for observability over the process. Teams should be able to reconstruct who activated the agent, on which comments, with which instructions, which model was used if that information is available, which files were changed and which checks passed. This traceability matters for debugging, internal compliance, incident response and continuous improvement.

Permissions also require attention. An agent that can open pull requests, propose patches or act on branches should operate with least privilege. It should not be able to bypass branch protection, mandatory approvals, CI controls or commit-signing policies. In more regulated contexts, separating environments may be appropriate: experimentation on non-critical repositories, progressive rollout with pilot teams, then extension only after quality and risk have been measured.

There is also the issue of semantic security. A patch may pass tests and still introduce unwanted behaviour: weaker error handling, excessive logging of sensitive data, reduced validation, unnecessary dependencies or changes to authorisation controls. This is why code owners and security champions remain central, especially when comments are resolved in batches. The batch feature described by GitHub may improve efficiency, but it can also increase review surface: more changes at once require more discipline in checking coherence and impact.

Dedaloop insights

For Dedaloop, the point is not to adopt or reject tools such as Copilot cloud agent on principle. The point is to integrate them into a delivery system that is measurable, secure and aligned with the organisation’s risk profile.

In AI and automation projects, we help companies define usage policies, operational limits, monitoring and control criteria for copilots and agents in internal processes. This topic is addressed in our Benefit AI and automation service: https://www.dedaloop.it/en/services/benefit-ai/index.html

On the operational side, the effectiveness of these tools depends heavily on pipeline quality: reliable tests, CI/CD, observability, well-separated environments and repeatable controls. These are core aspects of our Cloud managed services & DevOps work: https://www.dedaloop.it/en/services/cloud-managed-devops/index.html

When adoption involves multiple teams, repositories and risk levels, clear IT governance is also required: who can enable what, which KPIs should be measured, how decisions should be documented and how to prevent AI from becoming shadow automation. We address these areas through Strategic IT advisory and governance: https://www.dedaloop.it/en/services/strategic-governance/index.html

The practical rule is simple: before increasing agent autonomy, increase the quality of controls. Only then can the move from suggestion to code change become a real advantage without losing traceability, security and accountability.

Approfondimenti Dedaloop

Fonti