Quality & evidence
The hidden cost of “the AI says it worked”
When an AI tool explains a change, the explanation can already sound like acceptance. It describes the repaired defect, names the affected files and ends with a reassuring sentence. Yet the person responsible for a release still has a different question: what was actually observed? Hidden costs arise when that question is asked only after handover, leaving someone else to reconstruct work that was presented as complete and ready to use.
Ready does not mean passed
A verification plan can be sensible and complete without any checks having run. A required runtime, browser or service permission may be missing. Those are important planning facts, but they are not positive evidence about the change. Approval becomes unreliable when readiness, execution and success disappear into the same green summary. The distinction should remain visible even when the intended next step is obvious.
In my open-source project project-check-nix, I focus on explicitly declared verification commands and interpretable outcomes. A plan exposes prerequisites without executing checks. Ready does not mean passed, and a blocked check does not count as success. The tool is neither a sandbox nor a network-policy boundary. It organises verification evidence rather than claiming to control every risk involved in running the commands.
No findings can also mean no coverage
An empty report allows at least two interpretations: nothing was found, or nothing useful was examined. These are very different facts for a decision-maker. A failed parser can leave the same empty collection as a successful check with no findings. Reporting only the number of findings hides the prerequisite that makes that number meaningful. A reassuring result without an account of coverage is therefore incomplete.
project-check-nix does not simply turn missing coverage or failed parsing into a passing check with zero findings. The broader lesson is not a promise of defect-free software. It is that the reliability of the measurement belongs in the result. For approval, ask about the scope, execution and visible gaps of the check, not only the final list of issues it happened to produce.
An interface needs to be observed
In my open-source project visual-qa-mcp, browser-interface review is connected to captures, automated accessibility evidence and screenshot comparisons. Findings retain their origin. A model assessment does not become verified merely because it sounds convincing. New screenshot baselines require explicit approval, rather than automatically declaring the latest appearance to be the correct one. That separates a proposed interpretation from an accepted reference.
This does not resolve every question of good design. It does prevent a particular confusion: an explanation about an interface is not an observation of that interface. When the required browser is absent, browser-backed integration tests are explicitly skipped. A successful source check still has value, but it does not demonstrate browser behaviour or establish that the specific visual result is correct in the intended environment.
Not every judgment needs a model
My open-source project GrepQuest is a local terminal game for learning GNU grep. Answers are assessed by a deterministic judge. Optional generated cosmetic content does not decide whether an answer is correct. The project is in development, and its interfaces and formats may change. It is a bounded example of separating responsibilities, not evidence that one assessment technique is suitable for every kind of work.
That boundary is precisely what makes the example useful. When success can be expressed as a precise criterion, a language model need not make the final judgment. Creative explanation and authoritative assessment can remain separate. For engineering teams, the practical design question is where interpretation is genuinely needed, and where a clear, inspectable rule would make responsibility for the decision easier to understand and challenge.
Handover is part of the work
A useful handover separates the claim, the verification that ran and the uncertainty that remains. It explains not merely that something works, but the conditions under which that was observed. The responsible person can then decide whether the evidence is sufficient for the next stage. An explicit gap is often more useful than a reassuring summary that blends different kinds of verification into one statement.
I would make this separation a supplier requirement rather than a polite request to individual engineers. If the evidence chain must be reconstructed afterwards, the team pays in additional attention and unclear ownership. The size of that cost needs to be measured in the actual operation. These projects do not establish a general productivity figure, but they do suggest a clearer standard for accepting completed work.
Questions for your team or vendor
- Which checks actually ran, and which were blocked or skipped?
- What coverage supports a report with no findings, and did its parsing complete successfully?
- What specific evidence connects the claimed repair to an observed result?
- Which findings come from fixed rules, and which come from a model assessment?
- Who can approve new visual baselines, and can the tool automatically accept its own change?
- Which uncertainties are being accepted by the person approving a release on the basis of these results?