Before merging an AI-assisted change, write down what existing behavior could plausibly break, which automated suites cover it, and which paths need a manual check because no test covers them yet. Attach the filled-in template to the PR instead of trusting memory.
Why "It Passed CI" Isn't the Same as "Nothing Regressed"
Green CI tells you the tests that exist still pass. It says nothing about the behavior nobody wrote a test for. AI-assisted changes make this gap more dangerous, not less, because the model will happily touch a shared function, a default parameter, or a formatting helper that several unrelated features depend on — often without flagging that it did.
A regression test plan closes that gap by making scope explicit before the change ships. It's a short exercise: name what could break, decide how you'll know if it did, and write down what you checked. That record is what turns "I think it's fine" into "here's what I verified."
The Copy-Paste Template
Fill this in before merge, not after a bug report. Keep it short — if it takes longer to fill in than the change took to write, the change is probably too large for one PR.
## Regression Test Plan
### What changed
One sentence: what behavior is different after this diff?
### What could this touch that isn't obvious?
List shared functions, default parameters, formatting helpers, or config
this change reads or modifies, even if the PR "shouldn't" affect them.
### Automated coverage
- [ ] Existing suite(s) that cover this path: ___
- [ ] New/updated tests added for this change: ___
- [ ] Suite(s) run locally before requesting review: ___
### Manual checks (for paths with no test coverage)
- [ ] Check 1: ___
- [ ] Check 2: ___
- [ ] Check 3 (edge case): ___
### Sign-off
I ran the above and did not observe unexpected changes outside this
change's stated scope.
Finding the Non-Obvious Blast Radius
The "what could this touch that isn't obvious" section is the one people skip, and it's the one that matters most. AI tools are good at finding and reusing existing code — which is exactly why a one-line change to a shared date formatter, validation rule, or default config value can ripple into features the PR description never mentions.
- Does this touch a function used by more than one feature?
- Did a default value, config flag, or environment variable change?
- Could this change behavior for existing data, not just new data?
- Does anything downstream assume the old output shape or timing?
If the answer to any of these is "maybe," that's a manual check, not a guess.
Matching Plan Depth to Change Risk
Not every change needs the full template filled in with the same rigor. Use the plan as a sliding scale rather than an all-or-nothing gate.
- Low risk (isolated UI copy, internal tooling): "What changed" and one manual check is enough.
- Medium risk (shared components, non-critical services): full template as written above.
- High risk (shared utilities, auth, billing, data writes): full template, plus a second reviewer confirms the blast-radius section independently before merge.
Writing "ran existing tests" as the entire plan. That confirms old behavior didn't regress where tests already exist — it says nothing about the paths that were never covered, which is usually where AI-introduced regressions actually show up.
Conclusion
A regression test plan is not extra bureaucracy bolted onto AI-assisted work — it's the same due diligence experienced engineers already do informally, written down so it survives being reviewed by someone other than the author. Five minutes of explicit scoping beats an hour of debugging a "how did this break" incident next week.
Pair this with Testing with AI for how to write the tests themselves, AI Change Risk Matrix for deciding how much scrutiny a change needs, and The AI Change Budget for keeping the diff small enough that this plan stays short.