A Test Plan Is How You Review Code You Didn't Write
Code review works because the reviewer has enough context to read a diff and reason about it: does this look right, does it handle the case I'm worried about, does it match how the rest of the system behaves. That model assumes there's time to read the diff carefully, and that the volume of change stays roughly human-paced. AI-assisted development breaks both assumptions. When a meaningful share of your changes are AI-generated, and arriving faster than a person can carefully read, "did I read this closely enough" stops being a reliable review mechanism on its own.
A real test plan is what replaces it, not as a nice-to-have QA artifact, but as the actual review mechanism when line-by-line reading doesn't scale. A test plan that's traceable back to requirements (this test exists because of that specific requirement), and forward to pass/fail criteria that are unambiguous, doesn't need a human to read every line of implementation to have confidence the system does what it's supposed to. The question shifts from "does this diff look right to me" to "does this change pass a plan that maps to what the system actually needs to do," which is a question you can answer with rigor regardless of who, or what, wrote the code.
What a real test plan actually requires
Requirement-based coverage, not just code paths, so passing tests actually means the system does the right thing, not just that every line executed once.
Explicit pass/fail criteria, unambiguous, not "seems to work," so a test's result doesn't require judgment to interpret.
Traceability in both directions, from requirement to test and from test back to requirement, so a gap in coverage is visible instead of assumed away.
Enough discipline to follow the plan, not treated as documentation nobody actually runs.
I've seen this in a number of different fields, with different ideas of criticality, but two common themes:
FDA-regulated medical imaging software. I spent a decade developing system requirements and test protocols for verification and validation here, where "we tested it and it seemed fine" isn't an acceptable standard and traceability from requirement to test case is a compliance requirement, not a nice-to-have.
Precision semiconductor manufacturing research instrumentation. I saw a different flavor of the same "we can't mess this up, even once" pressure: not a regulatory audit trail, but the fact that a single positioning error can destroy an expensive wafer or an irreplaceable experimental run.
Different failure mode, same underlying requirement: a test plan rigorous enough that passing it actually means something. Most teams don't need either level of formality. But the underlying idea holds at any scale, just applied with less paperwork.
That's the real argument for investing in test planning now. It's not about catching more bugs in general. It's about having a review mechanism that still works once the volume and speed of change outpaces what a person can read and judge line by line, which, if you're using AI coding tools seriously, is probably already true.
This note is about the plan itself, coverage tied to requirements, traceability, unambiguous pass/fail criteria. A companion note goes into the different levels a test plan actually needs to operate at, unit, integration, and system, since AI-assisted changes tend to fail at a different level than the ones a human-paced team is used to watching for.
If AI-assisted development has outpaced your team's ability to review it carefully, a stronger test plan is often the fastest way to close that gap without slowing down.