Find root cause, ownership, and regression risk

2211. Lesson identity

Module

5.8 — AI code review

Lesson

Find root cause, ownership, and regression risk

Academic type

Case Study

Schema type

case-study

Order

2

Estimated time

35–45 minutes, including practice

This lesson extends the previous acceptance review. A finding is not complete when it only describes what looks wrong; it becomes actionable when it connects the observed symptom to a likely cause, the contract owner, the affected regression surface, and a validation plan.

2212. Learning objective

After this lesson, you can classify a review finding with the five-case method and connect it to a likely root cause, the owner of the relevant contract, the regression risk, and a concrete validation need.

2213. Why this matters

A review that says “this may break something” does not yet tell a team what to inspect or who should resolve it. Root-cause reasoning prevents random edits, ownership reasoning routes the finding to the correct decision-maker, and regression analysis prevents a local fix from silently damaging an existing behavior. AI can help enumerate hypotheses, but it cannot establish causality or ownership without evidence.

2214. Prior knowledge

You should already be able to:

• compare a brief, an actual diff, and acceptance evidence;
• distinguish a blocking finding from an important or non-blocking observation;
• identify explicit contract boundaries and missing validation evidence;
• write a prioritized review with a concrete next action.

The previous lesson, 5.8 L1 — Review the change against the brief, established the acceptance decision that this lesson will investigate further.

2215. Core concept

Use five cases to move from an observation to an actionable review finding:

1. Observed case: What behavior or code fact is directly visible? Separate evidence from interpretation.
2. Cause case: What change, assumption, or missing guard could plausibly produce the observation? State this as a hypothesis until verified.
3. Ownership case: Which contract, state, or boundary is responsible for the behavior? Assign ownership to the relevant system or role, not merely to the file that happens to contain the code.
4. Regression case: Which existing behavior could change if this implementation remains or if the proposed fix is applied? Identify the surface and the failure mode.
5. Validation case: What inspection, test, trace, or comparison would confirm the cause and protect the affected behavior?

The method does not require certainty at the first pass. Its discipline is to label what is known, what is suspected, who controls the relevant contract, what may be affected, and what evidence would reduce uncertainty.

2216. Mental model

Use the Evidence → Hypothesis → Contract owner → Regression surface → Validation chain:

A useful review entry follows this pattern:

Finding: [observed fact]. Likely cause: [hypothesis, marked as unverified if necessary]. Owner: [contract or system owner]. Regression risk: [existing behavior and failure mode]. Validation: [check and expected result].

Do not confuse three different relationships:

• File ownership: where the code is located;
• Contract ownership: which system defines the behavior;
• Decision ownership: who can approve a contract change.

They may be the same, but they do not have to be.

2217. Concrete example

Consider this fictional review case:

A change adds a confirmation step before a destructive action. The brief requires the action to remain unavailable until confirmation, preserves the existing cancel path, and keeps the change local to the action screen.

The diff adds a local confirmation state but also changes a shared action helper. In one path, the confirmation flag is set before the asynchronous check finishes. The supplied evidence shows the confirmation screen but does not show cancellation, a rejected check, or a second attempt after the check fails.

Apply the five cases:

1. Observed: The flag is set before the asynchronous check resolves, and the evidence covers only the confirmation screen.
2. Cause hypothesis: The implementation treats “check started” as equivalent to “check passed.” This remains a hypothesis until the state transition and failure path are traced.
3. Ownership: The action screen owns the confirmation interaction, but the shared action helper owns the execution boundary. The helper change therefore requires review against the helper's existing contract; the screen owner cannot approve that boundary change alone unless the decision process allows it.
4. Regression risk: A rejected check may leave the action enabled, or a second attempt may reuse stale confirmation state. The shared helper may also alter cancellation behavior for other callers. These are risks, not confirmed regressions, until reproduced or disproved.
5. Validation: Trace the state transitions for success, rejection, cancellation, and a repeated attempt. Inspect or test at least one existing caller of the shared helper to verify that its cancellation behavior is unchanged.

A strong finding would not state “the helper is broken” without evidence. It would state what changed, why the change is a plausible cause, which contract is involved, what could regress, and which validation would establish the next decision.

2218. AI-native workflow

Use AI to widen the hypothesis set and organize evidence, not to declare a root cause:

1. Provide the brief, the review finding, the relevant diff, and the evidence available.
2. Ask the model to separate direct observations from causal hypotheses.
3. Ask it to list the state or contract boundaries implicated by the finding.
4. Ask for possible regression surfaces and a validation matrix, including what evidence would disprove each hypothesis.
5. Verify every proposed cause against the actual control flow, state transitions, and callers.
6. Identify contract ownership yourself, then write the review entry with confidence labels such as observed, likely, or unverified.

Do not prompt the model to “find the bug” without supplying the contract. Do not accept a plausible explanation as root cause merely because it sounds technically sophisticated. A useful AI response narrows the investigation; it does not replace it.

2219. Common mistake

The common mistake is assigning ownership to the file that changed and calling the first plausible explanation the root cause. A diff location is not necessarily the owner of the contract, and correlation is not causality. Another mistake is declaring a regression from the existence of shared code alone. Shared code increases the surface to inspect; it does not prove that another caller changed behavior. Record the risk, identify the affected behavior, and request validation before upgrading the claim.

2220. Guided practice

Use this fictional case. No project incident is implied or claimed.

Brief: Add a retry action for a failed load. The retry must apply only to the failed load, must preserve the existing cancel behavior, and must not change the shared navigation contract.

Review evidence:

• The diff adds a retry action to the screen.
• It resets the screen state before the retry request completes.
• It changes a shared navigation helper.
• The evidence shows a successful retry but does not show cancellation, a failed second retry, or another screen using the helper.

Write one review entry using all five cases:

• Observed: cite only what the evidence establishes.
• Cause: give one likely cause and mark it as a hypothesis unless the evidence proves it.
• Ownership: name the screen or shared contract involved and explain the distinction between file and contract ownership.
• Regression: identify one existing behavior at risk and describe a plausible failure mode.
• Validation: specify the smallest useful trace, test, or caller comparison and the expected result.

Then make one decision: request changes, block acceptance, or record the finding for follow-up. Base the decision on the previous lesson's acceptance criteria and on the strength of the available evidence. If the reset creates a demonstrated contract failure, blocking may be justified. If the evidence shows only plausible risk, state the uncertainty and request targeted validation rather than claiming a confirmed regression.

2221. Validation / evidence

Your submission is complete when it contains:

• one precise observation supported by the fictional evidence;
• a causal explanation clearly labeled as confirmed or hypothesized;
• a distinction between file ownership and contract ownership;
• one named regression surface with a plausible failure mode;
• a validation step that could confirm the cause and assess the regression risk;
• a decision whose severity matches the evidence rather than the number of concerns.

A strong submission does not invent an incident, repository history, or hidden implementation detail. It uses only the supplied case facts, labels uncertainty, and makes the next investigation reproducible.

2222. Key takeaways

• Start with the observed fact, then separate cause from evidence.
• Route findings by contract ownership, not automatically by changed file.
• Treat shared-code changes as regression surfaces to investigate, not as proof of regression.
• Define validation that can confirm the cause and protect existing behavior.
• Use AI to generate and structure hypotheses while retaining human responsibility for the review decision.

2223. Next lesson

Continue to 5.9 — AI-generated tests.

2224. Knowledge check