Almost every system I work with has a way of telling me it succeeded. A script exits with code 0. A pipeline turns green. A dashboard shows a checkmark. An AI coding agent writes a tidy summary that ends with “the implementation is complete.”
None of those things is the result. Each one is a claim about the result, usually made by the same component that did the work. I treat them as evidence worth having, and then I go look at the thing itself.
That sounds obvious written down. In practice it is a lesson I keep relearning in slightly different forms, so I want to lay out the examples that taught it to me and the habits I use now.
A backup that ran cleanly and was still wrong
One of my longer-running projects is a backup system that copies selected high-value data to removable storage. It uses rsync with fairly detailed inclusion and exclusion rules, including regular expressions, and it keeps logs and sends notifications.
At one point the script ran without errors, the log looked reasonable, and files were showing up at the destination, including the hidden paths I had specifically set out to capture. By every signal the script itself produced, it worked.
When I inspected the destination more closely, some of those hidden paths had landed with the wrong destination semantics. The names were there. What sat at those names was not what the source meant. The path rules were being interpreted differently than I intended, and nothing about the exit code or the log would have told me.
What found it was unglamorous: reading the rsync behavior carefully, re-checking the include rules and regular expressions, and looking at the actual file types at the destination instead of settling for the fact that something existed there. A backup is not verified because it exits successfully. It is verified when the resulting state is correct, and the real test of that is whether you can recover from it.
An agent that said “done” to a black screen
I spend a lot of time testing AI coding agents on real projects, including local models running on my own hardware. One of my favorite test beds is an arcade-style browser game: HTML5 Canvas, vanilla JavaScript, Web Audio, sprites, a fixed-timestep game loop, and input handling.
A game is useful for this because it gives immediate visual evidence. The model can report:
The implementation is complete.
And the browser can answer with a black screen.
That gap is the whole lesson. The agent had created the files it planned to create, and from inside its own loop, file creation looked like completion. Whether the page rendered was a separate question it never asked. When I evaluate an agent now, most of my questions are variations of that one. Does it mistake file creation for completion? Does it inspect runtime behavior? Does it notice a black screen? Does it trust its own assumptions too easily?
The answer is not to distrust the model. It is to put the model in an environment where its claims get checked against something it did not write: a browser, a test run, a console log, a screenshot.
A cluster that passed the first request
The same pattern showed up on my two-node NVIDIA DGX Spark cluster. While I was chasing a deadlock in multi-node model serving, one configuration started cleanly, captured its CUDA graphs, and answered the first request. If my test had been “send one request and see if it comes back,” I would have called it fixed.
The second request hung. Generation throughput dropped to zero and never recovered. The real fix was a build of NVIDIA’s NCCL library compiled for the exact GPU architecture, and I only trusted it after repeated runs across different output lengths and concurrent requests with no deadlocks.
One successful request was evidence. It was nowhere near proof.
An upgrade where the version number was the wrong question
Infrastructure has its own version of this. During one Amazon EKS upgrade, the problem that mattered was not the upgrade itself. An Alertmanager workload could not schedule because its persistent volume and availability-zone placement did not line up with the workload.
The visible symptom was simple. The cause spanned Kubernetes scheduling, volume binding, EBS, and availability zones. A new cluster version number would not have revealed any of that. Checking that the workloads were actually running was the check that mattered.
Why success signals mislead
None of these systems were badly built. The signals were honest about what they measured. The trouble is that what they measured was narrower than what I cared about.
- Exit code 0 means the process did not report a failure. It does not mean the output is correct.
- A green pipeline means the checks someone wrote passed. It says nothing about the checks nobody wrote.
- A dashboard reports what the software believes, which may not be what the hardware is doing.
- An AI agent’s summary describes the agent’s own view of its work. It is the least independent evidence of all.
The common failure is letting the component being tested be the only component that decides whether the test passed.
What I do instead
None of these habits is sophisticated. They are just deliberate.
- Test the thing that will actually run. If it is a web application, open it in a browser. If it is a backup, restore from it or inspect the copied files. If it is a proxy, make a real request. If it is an AI agent, give it a real repository.
- Get a second opinion from a different layer. An application log plus a check from outside the application. A dashboard number plus a meter reading. An agent’s summary plus a screenshot.
- Test the second time, not just the first. Repeated requests, restarts, the run after a reboot. Plenty of failures only appear once state exists.
- Check the edges on purpose. Hidden files, permissions, path quoting, availability zones, stale configuration. The main path usually works. The edges are where “done” stops being true.
- Make automation explain itself. A script or webhook should leave enough evidence behind to show what it did, not just whether it thinks it succeeded.
What this means for a business
If you run a business on automation, reporting, or AI tools, you depend on these same signals whether you think about them or not. The nightly job that “ran.” The report that refreshed. The AI assistant that says it updated the records.
The question worth asking about each one is simple: when this says it worked, what independent evidence do we have? If the answer is “the tool told us,” that is where a check belongs. It is a large part of how I approach automation and AI agent work. Verification gets designed in from the start instead of being added after the first quiet failure.
A green status is evidence, and I am glad to have it. I just no longer confuse it with the result.