The pull request is the test-design source you're ignoring

This is part two of a series on moving QA from classic automation to AI-assisted. Part one argued that AI test generation is only as good as the context you feed it, and that the context is scattered across five systems. This post is about the single richest of those five — the one almost every test-design workflow ignores: the pull request.

Here's the mismatch. Test design usually starts from the ticket. But the ticket describes what was asked for, in the words of whoever wrote it, before the code existed. The pull request describes what actually shipped — the real files that changed, the real behavior, and, in its review thread, the exact edge cases the engineers who wrote it already worried about. If you're designing tests and you're not reading the PR, you're testing the plan instead of the change.

The diff tells you where to test

The most underused signal in QA is also the most precise: the diff. It's an exact map of the code that changed — which modules, which functions, which parameters, which branches. That map is the surface you actually need to cover. Everything else is unchanged and (presumably) already tested.

Without it, coverage decisions are guesswork. You either over-test — re-running huge regression suites "to be safe" because nobody knows what the blast radius really is — or you under-test, because the risky change lived in a helper three files away from where the feature "obviously" is, and nobody looked there.

The diff kills the guessing. A change touched the payment-retry path and a shared currency-formatting util? Those two zones are where your new cases go — and the currency util is now a regression risk for every feature that imports it, which the ticket would never have told you. Reading the diff turns "test the feature" into "test these specific changed surfaces and everything downstream of them." That's the difference between risk-based coverage and coverage theater.

The review thread is a free edge-case list

If the diff tells you where, the review thread tells you what. Code review is where engineers argue the hard cases out loud: "what happens on a retry?", "this is null if the user never onboarded", "does this handle the timezone rollover?", "we're not locking here — is that a race?". Every one of those comments is a test case someone already identified and wrote down for you.

This is the part that still surprises people: the highest-value edge cases for QA usually already exist, in prose, in the PR — they just never made the trip from "review comment" to "test case." Nobody's job was to carry them across. So they get resolved in the code, the thread gets marked done, and the institutional memory of "this is the tricky bit" evaporates the moment the PR merges.

PRs are a risk memory, not just a moment

Here's the part that compounds. A single PR helps you test one change. But the accumulated history of PRs and their reviews is something more valuable: a durable, queryable record of where risk has lived in your system over time.

Pulled into the same searchable context layer as everything else (the pattern from part one), PR history stops being a pile of closed tabs and becomes a risk-analysis tool. Which modules attract the most review friction? Where do the same classes of edge case keep recurring? When you're assessing release risk for an area, what's the change-and-incident history under it? When an AI agent drafts tests for a feature, what did reviewers flag the last three times this code was touched?

Classic automation throws all of that away — the review context dies with the merge. Preserving it turns each PR from a one-time signal into a growing, risk-based memory you can ground the next decision on. That's a large part of what makes AI-assisted QA actually trustworthy: not a cleverer model, but a longer, better-organized memory of where things have broken before.

Feeding it to the drafting — still gated

So the move, concretely: when designing tests (human or AI-assisted), don't start from the ticket alone. Auto-discover the pull request(s) linked to it — most issue trackers expose the linked PRs through their dev-status data, so this can be automatic — and feed the diff and the review thread into the drafting alongside the requirement.

The output changes character. Instead of generic, ticket-shaped cases, the drafts target the exact changed surfaces and cover the specific edge cases the reviewers named. It reads less like "tests someone generated" and more like "tests written by someone who actually read the PR."

Two guardrails, because this is real code near a real suite:

• The review is signal, not spec. Reviewers are often right, sometimes wrong, and occasionally arguing about something that got refactored away. Treat the thread as high-value input to verify, not gospel to encode.
• Generation is still a draft. Nothing reaches the test suite without the same guarded path — dry-run, a diffable plan, explicit human confirmation. Better context raises the hit rate; it never removes the review gate.

What it looks like in practice

Pattern-level, because the specifics are always under NDA: a ticket says "let users change their subscription tier." Fed just that, a model writes the obvious upgrade/downgrade cases. Fed the PR, it sees the diff touched a shared proration helper (so billing is now in the blast radius, not just the tier UI), and the review thread has a comment: "what if they change tier twice in the same billing cycle?" — a case the ticket never imagined. Now the useful drafts include the double-change-in-one-cycle case and a proration-helper regression check. Those are the cases that catch the incident.

Where this fits

If part one was "gather the context before you generate," this is the sharpest instance of it: the PR is where the real risk of a change is written down twice — once as the diff, once as the argument about it — and then usually thrown away. Wiring it into how tests get designed (and kept as risk history) is one of the highest-leverage moves in taking a team from classic automation to AI-assisted.

It's also, in my experience, the fastest way to make AI-drafted tests stop feeling like a toy. If your team is shipping behind PRs and still designing tests off tickets, that gap is where I'd start.