A website change is easier to accept when the reviewer can see how to remove it. A saved screenshot does not provide that option. It records what the page looked like, while leaving the code, content and behavior needed to reproduce it somewhere else. An AI assistant can deliver a convincing improvement and still leave the owner without a usable way back.
Consider a fictional repair workshop page listing a lamp session on November 14 and a bicycle session on November 21. The requested change adds a date filter. The original page shows both events, and that unfiltered list must remain available in a saved baseline. This is a disposable local exercise, with invented events and no registration service, customer records or deployment behind it.
The acceptance question has two parts. Does the filter help a visitor find the bicycle session without breaking the rest of the page? Can the maintainer restore the original list if the change is rejected? Those questions deserve separate evidence. A candidate can pass the first while failing the second, particularly when the assistant edits the only available copy.
Start with a baseline that another person can identify. Preserve the source files, the synthetic event data and the instructions needed to open the page. If the example uses dependencies, include their declared versions and lockfile. Record the revision and the expected behavior: both workshops appear in the original order, and the information-request link remains available. The baseline should describe something reproducible rather than something remembered.
Version control helps keep those identities explicit. Git's worktree documentation describes multiple working trees attached to one repository, allowing separate checkouts. That makes a baseline checkout beside a candidate a useful review arrangement. It does not establish that either checkout runs correctly. Opening the intended revision and repeating the task still belongs to the reviewer.
Keep the request narrow enough that its reversal has a clear boundary. Add the date control, the filtering behavior and an empty-result message. Preserve the event content, ordering and information-request link. Changing the typography, replacing the build setup and rewriting the form can each be reasonable work, but bundling them into this patch makes the decision harder. The reviewer should be able to connect every changed file to the requested filter.
Ask the assistant to produce the diff and a release card alongside the candidate. The card names the baseline, candidate revision, requested behavior, checks, unknowns and reversal procedure. It also names the person who accepts the work. This is useful even when the candidate will never leave the local machine: the next reviewer should not have to reconstruct the request from a chat history.
The worked checks begin with the ordinary route. Open the baseline and expect both workshops. Open the candidate with no filter selected and expect the same list. Select November 21 and expect only the bicycle session. Select November 28 and expect a clear empty-result message. Clear the filter and expect both original events again. Keep expected results separate from observations until each action has actually happened.
Discussion Topic:
Which part of your rollback plan is least certain: the baseline, the reversal steps, or the recovery check?
The neighboring path matters too. Follow the information-request link from the original list and from a filtered result. Check that keyboard focus can reach the date control and the clear action. If the filter hides everything, the visitor still needs a visible route back. These checks connect the new behavior to the task the page already supported; they do not turn a small filter review into a claim of complete accessibility coverage.
Now rehearse the reversal in a disposable copy. For this example, restoring the saved baseline means returning to a page with both workshops and no date control. Open that restored page and repeat the original task, including the information-request link. Compare the restored source against the saved baseline as well. Matching bytes and a completed task answer different questions, and both belong on the card.
A Git revert is one possible reversal mechanism. The official documentation explains that it records new commits reversing changes introduced by earlier commits. It also requires a clean working tree and describes how conflicts can interrupt the operation. The important instruction is therefore more specific than “revert if needed”: identify the change to reverse, protect unrelated work and stop if the result requires unresolved decisions.
A successful command is still only part of the evidence. The restored page might load stale assets, use different fixture data or point at the wrong local directory. Record which page was opened and what the reviewer observed. In the proposed exercise, recovery passes only when the original two-event list and its information-request route work again. A screenshot of two cards supports appearance; it cannot establish that the link completes the intended action.
There is a reasonable objection to this amount of ceremony for a tiny page. A filter can take less time to implement than its review record takes to write. The answer is to keep the record proportionate. A short card and one rehearsed reversal can be enough for a self-contained demonstration. The discipline becomes expensive when the team leaves recovery undefined until several unrelated changes have accumulated.
The limits need equal clarity. This example changes local presentation over fixed data. It does not migrate a database, send a message or modify a remote account. In a system with those effects, restoring earlier source would not by itself undo records already written or messages already delivered. The recovery plan would need to account for those effects explicitly, and a reviewer could reasonably reject the change until that plan existed.
The assistant can help prepare the baseline inventory, propose the focused checks and explain the diff. It should not convert a plausible reversal procedure into a claim that recovery was tested. Use plain states on the release card: proposed, performed, failed or pending. If the candidate works but nobody has exercised the reversal, the card should say exactly that. The maintainer can then decide whether the missing evidence blocks acceptance.
The final decision belongs to a person looking at the identified candidate and its recorded limits. Accepting this local filter would not authorize deploying a website, changing a service or extending the experiment to live data. Those are separate decisions with different consequences. Keep the original page available until the reviewer has evidence that returning to it is an action they can perform, not a promise they have to trust.
If this was useful, forward it to one engineer who needs less noise in their feed.