You can now review a single test; today is the layer above it, the questions that decide whether AI-assisted work ships at all.
When an AI-assisted change lands in front of me, I do not start from “is the build green”. Green is the floor, not the proof. I start from five questions, and I will not approve the work until I have a real answer to each:
- What actually changed? Not the summary the agent wrote. The diff. Which files, which behaviour, which data path. If you cannot tell me what changed in one honest paragraph, neither of us understands it well enough to ship it.
- What is the risk? Where can this break, who gets hurt, and what is the worst version of that? A payment-flow change and a copy tweak do not deserve the same scrutiny. Name the blast radius before you decide how hard to look.
- What evidence proves it works? A test that would have failed before this change and passes now, a screenshot from a real environment, a checked API response. “It passed” is only evidence if the test could have failed.
- What evidence proves the adjacent behaviour did not break? This is the one AI work skips almost every time. The change fixed its target and quietly moved something three steps away. What proves the neighbouring flow, the shared component, the downstream report still does what it did yesterday?
- What will we monitor after release? For anything you cannot prove before it ships: what production signal will tell you it went wrong, who owns watching it, and what is the rollback?
None of these are AI questions. They are what a good tester has always asked at the edge of a release. What AI changed is the volume arriving at that edge, which is exactly why writing the five down and running every change through them beats holding them loosely in your head.
What stays a human call
However good the tooling from the past nine days gets, six calls do not move:
- Whether the UI is right on a real device.
- Whether the end-to-end flow makes sense to a real person.
- What the real risk of shipping is, and who is affected if we ship anyway.
- Whether a passing test is a passing feature.
- What belongs in the suite and what does not.
- Whether to say no to a release. Sometimes the answer is not tonight, and somebody with judgment has to say it out loud.
The Monday checklist
Run this on the next AI-assisted change that crosses your desk:
- Read the diff, not the summary. Can I describe what changed in one honest paragraph?
- Write the one-line risk note. Where can this break, and who gets hurt when it does?
- Find the proof it works. A test that would have failed before this change and passes now.
- Find the proof nothing else broke. The adjacent flow, the shared component, the downstream report.
- Check the evidence is real, not green. Does anything here only pass because the assertion proves nothing?
- Confirm it was checked where it runs. Real environment, real device, real data.
- Name the monitor for what you cannot prove. The signal, the owner, the rollback.
- Decide out loud. “Ship, with this evidence” or “not yet, because of this gap”. Either is fine. Silence is not.
If a change clears every box, ship it and feel good about it. If it does not, you have just done the most valuable thing a tester can do on an AI-assisted team: you caught the almost-right before a user did.
The decision itself deserves a proper home, not a chat message that scrolls away. My release summary template is the shape I use: what was tested, what was found, what is outstanding, and the recommendation, stated plainly. The full argument for this whole way of working is QA is the control layer for AI-assisted development.
Try this today
Copy the checklist somewhere you will actually see it, then run it once, today, on any recent change, AI-assisted or not. The first run takes ten minutes. By the third it is reflex, and that reflex is what makes everything else in this course safe to use at speed.
Tomorrow: the capstone. You run the whole loop end to end, and collect your certificate.