Nothing errored. That was the problem.
Some of the worst bugs don’t crash anything.
On one software product, a meaningful number of invited users couldn’t get in. No error logs. No alerts. There turned out to be several ways a person could end up stuck, but the biggest one was simple: invitation links expired after a set number of days, which was a perfectly sensible rule. The problem was that when a link expired, nothing told anyone. The person clicking the link saw a dead end. The people who sent the invitation saw nothing at all. From the inside, everything looked healthy.
It took a deliberate audit, someone asking “how many invited people never actually signed in, and why?”, to surface it.
The fix wasn’t to change the expiry rule. The rule was fine. The fix was to make the expiry visible: tell the person their link had expired and how to get a new one, and show the admin who was stuck. The bug was never the rule. The bug was the silence.
Silent failures are common in AI-written code
In AI-written code, a pattern shows up again and again: software built to never crash. Crashing looks bad. So when something goes wrong in a way the code didn’t plan for, the code catches the problem and moves on quietly. The app stays up. The user sees something, or nothing. And the failure disappears from every place you’d normally look for it.
A few shapes this takes:
The swallowed error. Saving a record fails, the error is caught and ignored, and the screen says “saved.”
The quiet limit. A user asks for more than an allowed amount, and the system silently reduces it to the limit instead of telling them. They think they got what they asked for.
The invisible expiry. A link, a trial, a token, or a session ends, and the user lands on a blank or generic page with no explanation.
The skipped step. A background job that should send an email or update a record fails on one item and simply moves on to the next, with no record that it skipped anything.
Each of these can pass its tests and show green on a dashboard. Any of them can mean a real person having a bad day that nobody on your side sees.
How to hunt for them
Normal testing asks, “Does this work?” Hunting silent failures asks a different question: “If this fails, who finds out, and how?”
Ask it about every important path in your product. Signing in. Paying. Saving. Sending. If the honest answer is “nobody, and they wouldn’t,” you’ve found a silent failure, even if it has never happened yet.
Then look at your data the way an auditor would. Many dashboards are set up to count successes. An audit counts the people who should have done something and didn’t:
- Invited, but never signed in.
- Started checkout, never finished.
- Requested something, never got a response.
- Scheduled to receive an email, no record it was delivered.
Some gaps are normal human behavior. Some are silent failures wearing its clothes. You won’t know which until you look.
Fix the class, not the instance
When you find one silent failure, resist fixing just that one. The invitation problem above wasn’t really about invitations. It was about a habit: things that expire or get limited without anyone being told. Once you see that, the next question is where else the same habit lives. Password resets? Trial periods? Spending limits?
This is where a fresh reviewer earns its keep. In practice, the AI that built a feature tends to see its feature working. A reviewer told to look for errors that are caught and silently ignored, and to check what happens when a step fails halfway, has a much better chance of noticing the silence. Our free review skill asks questions like these every time you run it.
The one-line habit
Add this to how you instruct your AI builder:
“Nothing fails silently. If something goes wrong, the person affected is told what happened and what to do, and we have a record of it.”
It won’t catch everything. But it turns a whole category of invisible problems into visible ones, and visible problems are the kind you can fix.
More on the approach in our plain-English guide.