Review an AI-assisted change set

1354. Lesson identity

Module

3.14 — Professional Git

Lesson

Review an AI-assisted change set

Academic type

Guided Build

Schema type

Practical

Order

2 of the module

Estimated time

45–60 minutes, including inspection and recovery planning

1355. Learning objective

After this lesson, you can inspect an AI-assisted diff, compare it with the requested boundary, identify unsafe or unrelated changes, evaluate the commit's evidence, and choose a safe recovery operation from the repository state.

1356. Why this matters

AI-assisted work can produce a technically plausible change that still violates the task boundary. A professional review checks more than whether the code looks reasonable: it checks scope, behavior, validation, and reversibility. This protects the production record and prevents an unclear commit from becoming the foundation for later work. The goal is not to distrust assistance; it is to make the final decision from inspectable evidence.

1357. Prior knowledge

You should have completed 3.14 L1 — History is part of the production record. You should be able to read a commit history, distinguish a focused commit from a mixed one, and describe a validation claim. You also need basic familiarity with working-tree changes, diffs, commits, and restoring or reverting work without accidentally discarding evidence.

1358. Core concept

A change set is acceptable only when its intent, boundary, implementation, evidence, and recovery path agree.

Review the change as a claim, not as a pile of modified files:

1. Intent: What was requested?
2. Boundary: What was allowed to change?
3. Implementation: What actually changed?
4. Evidence: What was checked, and what remains unknown?
5. Recovery: Given the repository state, what is the smallest safe operation if the claim fails?

An AI-generated explanation is context for review, not proof. The diff, project behavior, validation record, and history are the evidence.

1359. Mental model

The B-E-R review

Use this compact review sequence for every assisted change set:

A review result should end with one of four decisions:

• Accept: the scope and evidence are sufficient.
• Separate: a useful change is mixed with unrelated work; preserve and isolate the parts.
• Correct: the change belongs in scope but needs a targeted fix.
• Recover: the change is unsafe, unexplained, or outside the boundary; return to a known safe state through a deliberate operation.

Recovery depends on repository state

“Undo the change” is not a sufficient recovery instruction. First determine whether the affected work is uncommitted or committed, whether committed history has been shared, and whether any current work must be preserved.

Do not treat restoration, a corrective commit, a revert commit, and local history revision as interchangeable. The correct category follows from the state of the work and the need to preserve collaboration history.

1360. Concrete example

Suppose the requested task is: “Adjust the guard detection radius and update the related tuning note.” An assistant changes the detection value, renames a helper, adds a debug overlay, and formats several unrelated files.

The detection value and tuning note may be in scope. The helper rename requires review of its call sites. The debug overlay and broad formatting pass are boundary violations unless explicitly requested. “The game still runs” is not enough to accept the change.

Review it by:

• recording the requested boundary;
• inspecting every changed file and diff hunk;
• separating the intended tuning change from unrelated edits;
• checking affected call sites and the relevant detection scenario;
• choosing accept, separate, correct, or recover.

Worked recovery decision for the mixed change set

Assume the detection adjustment and helper rename are already in one shared commit, while the debug overlay and unrelated formatting remain uncommitted. The formatting includes a note you need to retain for a different task.

1. State: There is shared committed work plus mixed uncommitted work.
2. Boundary judgment: The tuning change may be retained after validation; the helper rename is still uncertain; the overlay and formatting are outside the current task.
3. Preservation: Save the unrelated note and record the current uncommitted diff before modifying anything. Do not let recovery of the shared commit overwrite those edits.
4. Operation: Restore only the unwanted uncommitted overlay and formatting regions after preserving the note. If review shows that the shared helper rename is unsafe, create a new corrective or revert commit that addresses that committed change; do not rewrite the shared history.
5. Post-operation checks: Confirm the preserved note still exists, inspect the working-tree diff, inspect the new history, review every helper call site, and rerun the detection scenario.

The choice changes if the questionable commit has not been shared: local history revision may be permitted by team policy, but a corrective commit remains appropriate when preserving an inspectable record is more important. In either case, preserve unrelated work first and validate the resulting state.

1361. AI-native workflow

Use AI as a review assistant, not as the authority that approves its own work.

1. Give the assistant the task boundary and ask it to summarize the intended files and behaviors.
2. Compare that summary with the actual changed-file list and diff.
3. Ask for assumptions, possible boundary violations, and unverified behaviors.
4. Verify the highest-risk claims yourself in the diff, project, or runtime.
5. Determine whether the work is uncommitted or committed, whether the commit was shared, and what must be preserved.
6. Record your decision and recovery operation in your own words.

Do not ask only, “Does this look good?” A useful prompt names the boundary and requests disagreement:

Review this change set against the stated task. List every changed file or behavior that appears outside scope. Separate evidence from assumptions, identify untested claims, and identify the repository-state facts needed before choosing a recovery operation. Do not approve the change.

The assistant's response is a candidate checklist. It does not replace inspection of the repository or the running project.

1362. Git workflow

For the guided review, work from a clean or deliberately documented starting point.

1. Identify the target commit or working-tree change set.
2. Inspect the changed-file summary before reading individual hunks.
3. Read the complete diff, including nearby context where behavior may be affected.
4. Compare the diff with the task boundary and commit message.
5. Inspect relevant call sites, configuration, and validation evidence.
6. Classify the repository state: uncommitted or committed, shared or unshared, and with or without work requiring preservation.
7. Decide whether to accept, separate, correct, or recover.
8. If recovery is required, name the exact safe operation category and affected paths or commits before acting.
9. Recheck the resulting history, working-tree state, preserved work, and relevant behavior.

Never use a destructive reset or deletion merely because an AI-assisted change is confusing. First preserve the evidence or establish a known safe reference. A recovery decision must describe what is retained, what is changed, why the operation matches the repository state, and how the result will be validated.

1363. Common mistake

The common mistake is reviewing the assistant's summary or the final runtime result instead of the complete diff. A change can pass a narrow test while introducing unrelated edits, changing an interface, weakening a boundary, or leaving no credible recovery path. Another mistake is using “revert” as a generic word for every undo action. Uncommitted edits, local commits, and shared commits require different decisions.

1364. Guided practice

Task: Review and classify an assisted change set

Use a small existing change set from your practice project, or create a deliberately mixed example with at least three changed files or three distinct diff regions. The requested task must have a narrow boundary, such as changing one tuning value and its documentation.

1. Write the task statement in one sentence and list the files or behaviors explicitly in scope.
2. Ask an AI assistant to summarize the intended change and identify possible risks. Save the response in your notes; do not treat it as approval.
3. Inspect the changed-file list and full diff independently.
4. Mark each changed file or diff region as in scope, requires investigation, or out of scope. For every item requiring investigation, write the missing evidence.
5. Check whether the commit message states one primary purpose and a clear validation claim.
6. Record whether each relevant change is uncommitted or committed, whether committed work has been shared, and what work must be preserved.
7. Select one decision: accept, separate, correct, or recover. Address both boundary and evidence.
8. Write a recovery specification containing:
   • the known safe reference;
   • the repository state that determines the choice;
   • the exact operation category and affected paths or commits;
   • the work and evidence that must be preserved;
   • the checks to run afterward.
9. If the change is safe to retain, describe the smallest focused commit that should remain. If it is not safe, do not perform a destructive operation without first preserving relevant work and evidence.

The required judgment is the classification of at least one ambiguous or mixed change and the selection of a recovery operation that matches its repository state. Do not classify every item as acceptable without explaining why.

1365. Validation / evidence

Your review is complete when you can point to all of the following:

• a written task boundary;
• a changed-file list and inspected diff;
• at least one explicit boundary judgment with evidence;
• a commit-quality assessment tied to purpose and validation;
• a decision to accept, separate, correct, or recover;
• a recorded distinction between uncommitted and committed work and, when relevant, shared and unshared history;
• a recovery specification naming preservation, operation, affected paths or commits, and post-operation checks.

A strong result distinguishes facts from assumptions. It does not claim that untested behavior is safe, use “revert” as a synonym for every recovery action, or rewrite shared history as a generic remedy.

1366. Key takeaways

• Review the actual diff, not only the AI explanation or runtime result.
• Scope is a technical property of a change set, not a matter of author intent alone.
• A focused commit needs one primary purpose and a credible validation claim.
• Recovery depends on repository state: uncommitted versus committed, shared versus unshared, and whether work must be preserved.
• Preserve evidence, choose the smallest safe operation, and verify both history and behavior afterward.
• AI can propose review questions; the developer remains responsible for the decision.

1367. Next lesson

Continue to A test must fail for the right reason / Un test debe fallar por la razón correcta.

1368. Knowledge check