The contact form looked successful.
While repairing the cemetery application, I found that email delivery could fail even though the handler returned HTTP 200. A missing dependency showed up in production. The response still looked fine.
That mattered because a family’s message needed to reach the board. Getting a successful response from the form wasn’t enough. I also found an authentication-state assignment that worked locally and failed on the deployed worker.
I had to look at the deployed application.
The local checks hadn’t caught either problem. Production telemetry did. I needed to follow the request far enough to see whether the thing people cared about had actually happened.
I still use tests. They caught other defects and made the repairs easier to check. But after this, I wasn’t going to treat a green build or a successful deployment as proof that someone’s email arrived.
One of my checks was the problem.
In the AI workflow I used, each worker had a defined job and a command to check it. When I used that process to build the original version of this site, one page failed twice. The page was right. My check was wrong.
Extracting text around an emphasis tag added a space beside punctuation. I’d made the comparison strict about that space, so it rejected correct writing. I changed it to compare word sequences. It still caught missing or changed content without failing on harmless formatting.
I have to understand what a pass proves.
AI can write the code and help me check it. I still have to decide what the application needs to do, what a useful test looks like, and what the test leaves out.
When a check fails, I read the output before trying again. Sometimes the code needs fixing. Sometimes my instructions or my check caused the problem. The part I keep coming back to is simple: I need to see the result people will actually depend on.