Skip to main content

Team acceptance rule for AI-agent changes

Use this page as a team rule for changes produced with an AI agent. It defines what the author must provide, what the reviewer must verify, and what blocks a merge.

A green build and a clean review report are evidence about the change. The author still owns the decision to submit it, and the reviewer owns the decision to accept it.

What the author must provide​

Before requesting review, the author should provide:

  • a short summary of the intended behavior;
  • the issue, requirement, or incident that the change addresses;
  • the files and components the change was allowed to touch;
  • the checks that actually ran, with their results;
  • known assumptions, limitations, and unverified scenarios;
  • a plain-language explanation of what changed, why it changed, and what could break if the change is reverted.

Store stable project requirements in Rules. Use Edit Scope when the task must stay within named files or directories.

What the reviewer must verify​

The reviewer should verify four things:

  1. Intent: the implementation matches the requirement and the plan.
  2. Boundaries: the diff contains only relevant files and no unexplained dependency or configuration changes.
  3. Evidence: the reported tests, build, inspections, or runtime checks actually ran and cover the stated scenario.
  4. Ownership: the author can explain the change without relying on the agent's summary.

Start with the full diff in Agent Changes. For a multi-file or risky change, run Auto Review as an independent check. Confirm every reported finding against the code and, when needed, against a runnable check.

Five questions before acceptance​

Ask the author to answer these questions in their own words:

  1. What behavior changed, and why was the change needed?
  2. Which assumptions did the implementation make?
  3. What does each new or changed test prove, and what does it leave untested?
  4. Which callers, consumers, data flows, or runtime paths can be affected?
  5. Which part of the change is still unclear or unverified?

If the author cannot answer, pause the merge. Reopen the diff, run the relevant scenario, and reduce the unknowns before another review.

What blocks a merge​

Block the merge when any of the following is true:

  • the task, expected behavior, or owner is unclear;
  • the diff includes unrelated files or changes outside the agreed scope;
  • the author cannot explain the implementation or its side effects;
  • a new dependency, permission, data path, or configuration change has no explicit justification;
  • the claimed test, build, inspection, or runtime check was not run;
  • the test passes without the fix when it is meant to prove a regression;
  • a confirmed review or security finding remains unresolved without an accepted risk decision;
  • rollback or recovery is unclear for a high-impact change.

The reviewer can request a smaller change when the diff is too large to understand within one review. Split by behavior or independently verifiable outcome rather than by arbitrary line count.

  1. Put stable project requirements in Rules.
  2. Set Edit Scope when the task must stay within named files or directories.
  3. Review every changed file in Agent Changes.
  4. Run the relevant test, build, or application through IDE run configurations.
  5. Run Auto Review for an independent check when the change is multi-file, risky, or hard to inspect manually.
  6. Confirm or reject each finding against the code and the executed checks.
  7. Accept the change only after the author and reviewer can account for the result.

Checks to run​

Choose checks that can disprove the change:

  • run the targeted test and confirm that it fails without the fix when testing a regression;
  • run the relevant build or test task through IDE run configurations;
  • reproduce the original scenario and inspect runtime state when static checks are insufficient;
  • run Auto Review for an independent diff check;
  • run vulnerability search when the change affects authentication, authorization, data handling, dependencies, or another security-sensitive boundary.

Record the exact command or run configuration and its result. "Tests passed" is incomplete when the reviewer cannot see which tests ran.

Project rule and acceptance exercise​

Use this exercise to turn the rule into observable Git evidence. It takes about ten minutes and works with a small documentation-only change.

  1. Add one scoped project Rule that requires one logical change, named files, a reproducible check, and the recorded result.

  2. Create a branch and make one small documentation-only change within the named scope.

  3. Review the changed paths and whitespace errors:

    git diff --name-only
    git diff --check

  4. Run the relevant test or build command and record the exact command and result.

  5. Fill in the change summary, related issue or n/a, verification result, assumptions, and unverified scenarios.

  6. Ask another person to compare the diff with the named scope and explain the change without using the agent's summary.

  7. Commit the Rule and the focused change.

Success criterion​

The exercise is complete when Git contains:

  • the scoped project Rule;
  • a diff limited to the stated task;
  • the exact verification command and result in the pull-request description or another committed review artifact;
  • a commit whose changed files match the declared scope;
  • a reviewer confirmation that the change can be explained without the agent's summary.

After the exercise, install Explyt from the JetBrains Marketplace if you want to apply the same flow to an AI-assisted change in a JetBrains IDE.

Public examples behind this rule​

The open-source Explyt Spring repository contains concrete examples of the process:

  • AGENTS.md requires one logical change, an issue reference, tests, and a statement of how the change was verified;
  • the pull-request template asks for Summary, Related issue, Type of change, How was this tested, tests, and documentation updates;
  • Coding Guard records the rules for explicit assumptions, minimal scope, reproducible tests, and verification at each step;
  • Orchestrated Code Review defines review-scope, review-packet, routing, finding-validation, and final-report artifacts;
  • CONTRIBUTING.md documents the branch, test, pull-request, review, and merge workflow.

These files prove that the process and templates are public and versioned. They do not prove that a particular pull request ran every review pass or validated every finding. That requires the completed test output, review artifacts, and pull-request history for that specific change.

After the merge​

For changes with operational risk, agree on what the team will watch after merge:

  • post-merge defects connected to the change;
  • change failure rate for the affected service or release;
  • mean time to recovery when the change causes an incident;
  • rollback frequency and time to restore service;
  • recurring review findings that point to a missing team rule or automated check.

Use these signals to improve Rules, tests, run configurations, and review criteria. Do not use them to rank developers by agent output or lines changed.

Copyable pull-request checklist​

## AI-assisted change acceptance

- [ ] I can explain what changed, why, and what breaks if it is reverted.
- [ ] The diff stays within the agreed files and behavior.
- [ ] I listed the assumptions and unverified scenarios.
- [ ] I recorded the tests, build, inspections, or runtime checks that ran.
- [ ] A regression test fails without the fix, where applicable.
- [ ] I reviewed the full diff in Agent Changes.
- [ ] Confirmed review or security findings are resolved or explicitly accepted.
- [ ] The reviewer knows what to monitor or how to roll back, where applicable.