A new screen should agree with the old one
On one software product, each account had a balance that the main app showed on its own screens. A new feature was added that showed the same balance in a new place.
One real account was checked in both places. The new feature said zero. The main app, for the same account at the same moment, showed a real balance.
Two places, one number
An AI traced the difference. The product kept that balance in two places: an older running total, and a newer record of every change. The main app’s screens added the two together. Every part of the new feature that read the balance looked only at the newer record.
For an account whose balance sat mostly in the older total, the new feature could show nothing at all. That is what happened here.
One detail made it easy to miss. The new feature’s actions that changed the balance were already correct, because they reused the product’s existing code, which handled both places. Only reading the balance was wrong.
Before fixing anything, a read-only query checked how widespread it was. It was not one account: many accounts still had part of their balance in the older total, and any of them could have been shown a number that was too low.
The fix added one shared function that returns the balance the same way the main app calculates it, and switched every read in the new feature to use it. New tests were added, and some of them fail when the fix is taken out, which shows they test the actual problem. Once the fix was live, the same real account was checked again, and this time the check passed.
Why this is easy to miss
Older products often store the same thing in more than one place. A newer system gets added, the older one is kept so nothing breaks, and the main screens are taught to combine them. That knowledge lives in the code for those screens, not in the name of any table.
In practice, when an AI builds a new feature that needs a number, it tends to read it from the most obvious place it finds, often the newest or cleanest-looking table. If the test data happens to keep everything in that one place, the tests pass and the gap stays hidden. The new feature can look finished and still disagree with the rest of the product.
Nothing errors. The new screen confidently shows a number. It is just not the number the product shows everywhere else.
The habit: ask where the existing screen gets it
Whenever a new feature shows a number the product already shows somewhere else, such as a balance, a total, a count or a status, ask your AI three things before it writes the code:
“Where does the existing screen get this number? Show me the exact code it calls, not a description. Is this number stored or calculated in more than one place, including older fields, newer tables, saved copies or another service? Will the new feature call the same code the existing screen uses? If not, tell me why.”
What you want to end up with:
- One source of the answer. The new feature should ask the same code the existing screen asks, rather than reading a table directly. If there is no shared function, have one made and point both at it.
- Every place the number lives, written down. If the AI finds an older field or a second store, that list belongs in your project notes, so the next feature does not rediscover it.
- Reading and changing checked separately. The code that shows a number and the code that changes it may be different. Ask about both.
How to check it worked
- Put the two side by side with a real account. Pick an account with real history, ideally one that existed before any change in how the number is stored. Open the existing screen and the new feature at the same time and compare, with nothing happening on the account in between, so a real change is not mistaken for a bug. They should match exactly.
- Ask for a test that would have caught it. The test should set up an account whose number sits in every place it can live, then check that the new feature shows the same total as the existing screen. Ask your AI to remove the fix temporarily, in a test or development copy of the product rather than the live one, and run the test again to show you it fails.
- Ask how many people it would affect. If the numbers disagree, ask for a read-only count of how many accounts are in the same position before deciding how urgent it is.
When two screens disagree about the same number, people tend to stop trusting both. Our guide has more on getting AI work checked by something other than the AI that wrote it.
The other reviewer’s take
Every post on this site is checked before it goes up by two reviewers that did not write it: a separate Claude reviewer and ChatGPT, from OpenAI. Below is what ChatGPT said about the first draft, quoted as it wrote it (any dashes are changed to commas, to match this site’s style), and Claude’s reply. Both reviewers then checked the final version, including this section.
ChatGPT, on the first draft (verdict: PASS):
Required changes: none
Suggestions:
For clearer regression evidence, suggest temporarily removing the fix in an isolated development or test environment, not from the live product.
Claude’s reply: Thank you, that is a good point and I took it. The draft told readers to ask their AI to remove the fix and run the test again, without saying where. Someone following that literally could undo a real fix in the live product. The second check now says to remove the fix temporarily, in a test or development copy of the product rather than the live one. That is the only change to the post. I do not disagree with anything here.