How to Use an AI Coding Agent Without Losing Git Review Control

AI coding agents can edit several files, run commands, and create commits quickly. This workflow keeps those changes inside the same Git review boundary you would use for a human contribution. The concrete result is either a bounded, reviewed change on a dedicated branch or a rejected attempt that never enters the main branch.

You will create a controlled review path for one agent task: capture a clean baseline, isolate the work, define its allowed scope, inspect the complete diff, run the repository's own checks, and accept only the intended change. The recorded example used a disposable repository and one change to src/slugify.mjs.

Agent controls help, but they are not proof that a change is correct. Cline documents IDE approvals and checkpoints in its IDE guide and checkpoint guide. Aider separately documents its Git behavior and lint and test integration. Treat those controls as useful boundaries while keeping Git diffs and repository checks as the acceptance evidence.

• Git installed, with the target directory recognized as a Git repository.
• A repository-specific task with clear acceptance criteria.
• The project's actual formatter, lint, type-check, build, and test commands.
• Permission to create a local branch or linked worktree.
• An AI coding agent configured without production secrets in prompts.

Do not begin from an unexplained dirty worktree. Existing changes may belong to another task or person.

1. Record a clean starting state — git-review-01-baseline. Run:

The expected result is a visible branch name with no unexpected modified, staged, or untracked paths. Save this output as checkpoint 1. In the recorded run, the command exited successfully on main, reported no unexpected paths, and captured the starting revision. If changes appear, stop and establish ownership; do not discard, stash, or commit unknown work merely to make the status empty.

1. Isolate the task — git-review-02-isolate. From a clean worktree, create a branch that follows your repository's naming convention:

If another checkout must remain active, use a linked worktree instead:

Replace the placeholders deliberately. The expected result is a dedicated task branch with unrelated active work outside its boundary. The recorded run created ai/slugify-review and confirmed a clean status.

1. Define the edit boundary — git-review-03-boundary. Give the agent the exact outcome, allowed paths, forbidden paths, permitted verification commands, acceptance criteria, and commit policy before the first edit. The expected result is an explicit, restatable task with no production secrets or unrelated scope. In the recorded example, only src/slugify.mjs was allowed, three other paths were forbidden, npm test and git diff --check were authorized, and no commit was allowed. Cursor's review documentation and Kiro's spec workflow describe product-level review or task controls; use those controls without confusing them with behavioral verification.

1. Inspect every changed path — git-review-04-diff. After the agent stops, run:

If commits were created, also inspect them:

The expected result is that every changed file belongs to the task and the full diff contains no unexplained generated files, secrets, dependency changes, or configuration changes. git diff --check should report no conflict markers or configured whitespace errors, but it does not validate behavior. This is checkpoint 2: compare the changed-path list with the allowed scope. The recorded diff changed one permitted file, with five insertions and one deletion, and reported no whitespace errors.

1. Run repository-owned checks — git-review-05-verify. Run the exact commands already owned by the repository, in its documented order. Depending on the project, that may include formatting, linting, type checking, compilation, targeted tests, broader tests, or a build. Do not substitute generic commands from another project. The expected result is that every required command exits successfully and covers the changed behavior. Any command that generates changes sends the workflow back to step 4. In the recorded run, npm test passed the targeted slug normalization test with zero failures. Record the exact commands and results as checkpoint 3; an agent's success message is not equivalent evidence.

1. Accept the behavior and commit boundary — git-review-06-accept. Compare the running behavior with the original acceptance criteria, then inspect the proposed commit boundary. One task should not conceal unrelated cleanup, and a generated commit message should describe the actual change. If the change is uncommitted, stage only intended paths or hunks through the repository's normal process. If commits already exist, inspect them before pushing or merging. The expected result is a branch containing only the accepted capability, with the diff, test results, and history telling the same story. The recorded functional check converted Agent Review to agent-review, staged only src/slugify.mjs, changed no forbidden path, and created no commit.

Checkpoint 1 confirms that later changes can be compared with a known clean baseline. Checkpoint 2 confirms that the actual changed paths match the declared task boundary. Checkpoint 3 records the repository-owned commands and their exit results. Finally, compare the behavior with the acceptance criteria and inspect the staged or committed diff. Acceptance requires all four views—baseline, scope, checks, and behavior—to agree.

• The starting worktree is already dirty. The likely cause is unfinished or unrelated work. Identify its owner, preserve it through the team's normal process, or create a separate linked worktree from a known commit.
• Aider committed pre-existing changes. Aider's Git documentation describes handling for dirty files and automatic commits. Inspect the commit and configuration before continuing; avoid a destructive reset when the changes may be valuable or shared.
• Cline changed too much before inspection. The task or approval boundary was too broad. Inspect the checkpoint diff before restoring anything, then narrow the task or reduce auto-approval for the next attempt.
• git diff is empty although files changed. The agent may have committed the edits, or you may be in another worktree. Check status, recent log, git show HEAD, the current branch, and the current worktree.
• Tests pass but the diff looks wrong. The tests do not authorize unrelated files, architecture drift, or exposed secrets. Reject or revise the change until both behavioral evidence and scope are acceptable.
• git diff --check passes but the build fails. This is consistent: the command detects conflict markers and configured whitespace errors, not compilation or runtime failures. Fix the behavioral or structural problem and rerun the appropriate checks.

The six steps above were executed in a disposable local repository with one bounded source-file change. That run demonstrated a clean baseline, an isolated branch, an explicit path boundary, a complete diff, one passing test, a staged commit boundary, and a successful functional check. It does not prove that every agent, hook, hosted service, or repository policy behaves identically.

Your repository may require signed commits, protected branches, hooks, pull-request checks, security scans, or different commands. Those rules take precedence. Checkpoint systems do not replace Git history, and automatic commits do not prove that hooks or tests ran.

For follow-up comparisons, visit the AI Code Generator hub and the pages for Cline, Aider, Cursor, and Kiro.