A website change can compile successfully and still fail in the editor. It can look right on the public page and break inside an iframe. I want an agent to check the place where the problem happens, because a green build cannot answer every question about a working website.
In May 2026, my WordPress work included fixing a MutationObserver crash when an editor iframe did not yet have a document body. That is a concrete reason to test the editor lifecycle as well as the finished page. The source change is useful evidence; it is not a substitute for trying the interaction.
Reproduce before editing
Ask Claude or Codex to record the route, the action and the observed failure. For an editor fault, that might mean opening a draft, inserting the relevant block and watching for a console error. Keep the example small enough to repeat after each change.
If the assistant cannot access the editor, it should say so and still inspect the code paths it can reach. A missing login or unavailable environment is a testing limitation, not a passing result.
Choose checks that answer different questions
- A syntax check catches invalid code.
- A build checks that the source can produce the expected assets.
- A focused behavioural check catches the failure you reproduced.
- A browser check shows whether the person can complete the action.
- A public URL check confirms the deployed version is actually served.
These checks overlap, but they are not interchangeable. For a visual change, inspect a screenshot and the layout itself. For a link or form, perform the interaction. For server-rendered content, inspect the initial HTML as well as what JavaScript eventually draws.
Use realistic page states
I would ask for a narrow and a wide viewport, a fresh load and a return visit where caching matters. On a shared component, choose representative pages from each layout family. Check the empty or loading state if that is part of the change.
Reproduce the editor error, fix its cause and check the same block in the editor and on the public page. Include a narrow viewport. Report console errors attributable to the change, the checks that passed and any checks you could not run.
A browser automation tool can make those actions repeatable. It still needs assertions that mean something: the control is visible, the expected text appears, or the request completes. A script that merely opens the page proves much less.
Keep the evidence proportionate
A small wording change rarely needs an elaborate new test suite. An editor crash or broken checkout deserves stronger verification. I prefer the smallest set of checks that demonstrates the behaviour and catches a plausible regression.
Save the useful result with the task: a screenshot, a concise observation or a test output. Then repeat the relevant public check after deployment. That final step is covered in the deployment guide.