There is a bug class that does not look like a bug. Nothing crashes. No error appears. Two parts of your product simply give the same question two different answers, and a person has to decide which one to believe.
That decision is the damage.
Being wrong once is a mistake people forgive. Being inconsistent teaches them that nothing you show them can be relied on without checking.
Why it does not get caught
Most testing asks whether a screen is correct. Very little testing asks whether two screens agree, because agreement is nobody's feature. Each one was built by someone who was confident their own numbers were right, and both of them were right by their own reckoning.
The split usually comes from somewhere ordinary:
- One view reads live records, the other reads a summary written earlier.
- One filters out incomplete entries, the other counts them.
- One rounds at the end, the other rounds at each step.
- One was updated when the rules changed, the other was not.
None of those is a defect in isolation. Each is a reasonable local decision. The inconsistency only exists in the space between the two, and nobody owns that space.
Why it costs more than being wrong
A plainly wrong number gets reported, fixed, and forgotten. People are used to software having bugs, and a fix is proof that someone is paying attention.
A contradiction works differently. The person cannot tell which side is broken, so the safe conclusion is that both sides might be. From then on, every number in the product carries a small question mark. They start checking. Once they are checking your output against something else, the thing they are checking against is doing the real work, and you have become an extra step.
That shift is quiet and it does not show up as a complaint. It shows up as people slowly using the feature less.
AI makes this sharper
A generated answer arrives in full sentences, with the confidence of prose. If your dashboard says one thing and your assistant says another, the assistant sounds more authoritative even when it is the one working from stale or differently filtered data.
Worse, a language model will not flag the discrepancy. It has no way of knowing what the other screen displayed. It will explain its own answer fluently and at length, which makes the contradiction feel less like a data problem and more like one of the two being untrustworthy.
So the moment you add a conversational surface on top of an existing product, you have doubled the number of places an answer can come from without adding any mechanism that keeps them aligned.
One source, or one owner
The fix is not more testing. It is deciding, per question, where the answer comes from.
| Question the product answers | Bad shape | Good shape |
|---|---|---|
| How long was this session | Each screen computes it | One function every screen calls |
| What counts as complete | Defined in two places | Defined once, imported twice |
| What did this cost | Recomputed in the report | Stored at the time it happened |
The pattern is the same each time: one definition, one place, everything else reads from it. When a number is genuinely expensive and has to be cached, then the cache is the answer everywhere, including in the live view, rather than the live view quietly doing its own better math.
The rule that survives contact with a real codebase is narrow. Any figure a person might see twice gets one owner.
How to find yours
You do not need an audit. Pick the three numbers your users care about most, and list every place each one appears: the main screen, the summary email, the export, the chat answer, the notification. For each list, ask one question. Are these all reading the same thing, or are they each computing it?
Where they compute, you have a future contradiction waiting for a rules change. It has probably already happened and nobody reported it, because the person who noticed just assumed they had misread something.
What to take away
- Treat agreement between screens as a feature with an owner, not as something that happens by itself.
- Give every user-visible number one definition in one place, and make everything else read from it.
- Before adding an AI surface to an existing product, list what it can answer that another screen already answers, and wire both to the same source.
Consistency is not polish that comes after the real work. It is the thing that makes the real work believable. The AI does the busywork, you still make the calls.