{"slug": "smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it", "title": "Smash Stories: The Bug That Whispered for Two Weeks Before I Heard It", "summary": "A developer building an AI agent that controls Android phones using Gemma 4 discovered that the agent was misreading financial data 20% of the time due to a single bad assumption: treating OCR output as ground truth. The bug went unnoticed for two weeks because no crashes or exceptions occurred. The developer fixed it by implementing a three-layer verification system including format validation, double-read confirmation, and range validation.", "body_md": "*This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.*\n\nMy AI agent was misreading financial data 1 in 5 times. No crashes. No exceptions. Just quiet, dangerous wrong numbers.\n\nSome bugs scream. Null pointer exceptions. Segmentation faults. Crash logs that light up your screen like a Christmas tree.\n\nThis one whispered.\n\n**The Setup**\n\nI'm building an AI agent that controls Android phones using Gemma 4. Natural language commands get parsed into structured JSON, translated into ADB instructions, and executed on-device. No cloud. No API keys. Just a phone that does what you tell it.\n\nBy Day 16, I'd hit a milestone: the agent completed its first multi-app workflow. \"Copy my bank balance and send it to Mom on WhatsApp.\"\n\nThree apps. Banking → WhatsApp. Seven steps. Success.\n\nI celebrated. Shipped the code. Published the build log. Went to sleep feeling like an engineer.\n\nThen I tested it again the next morning. And again. And again.\n\n**The Whisper**\n\nOut of 50 test runs, the balance was wrong 10 times. Twenty percent.\n\nThe agent wasn't crashing. No exceptions were thrown. The logs showed success. But \"₦15,000\" was quietly becoming \"₦15.000\" or \"₦15,00\" or \"₦15000.\" A currency symbol mistaken for a digit. A comma parsed as a decimal. A zero dropped from the end.\n\nThe wrong number was being sent to Mom. And I had no idea for two weeks because nothing was failing loudly enough to make me look.\n\n**The Root Cause**\n\nI traced the problem to a single bad assumption: I was treating OCR output as ground truth.\n\nBanking apps scored F on my accessibility audit. Zero UI labels. The agent had to rely entirely on optical character recognition to read anything on screen. And banking apps are a hostile environment for OCR:\n\nOne screenshot. One OCR pass. One number stored in memory. No verification. No double-check. No sanity check. I had built a pipeline that trusted a single, unreliable data source with financial information.\n\n**The Fix: Defense in Depth**\n\nI didn't try to make the OCR better. Tesseract and ML Kit are what they are. Instead, I built a three-layer verification system that treats every financial number as unverified until proven otherwise.\n\n**Layer 1: Format Validation**\n\nBefore a number is accepted, it must match a valid currency pattern. The regex checks for currency symbols (₦, $, £, €) followed by properly formatted digits. Anything that doesn't match gets rejected instantly.\n\n```\npython\npattern = r'[₦$£€]?\\s?\\d{1,3}(?:,\\d{3})*(?:\\.\\d{2})?'\nmatches = re.findall(pattern, extracted_text)\nif not matches:\n    return False, \"\", \"No currency values found\"\n\nThis alone catches about half the errors garbled text, partial reads, and non-numeric data that OCR sometimes returns.\n\nLayer 2: Double-Read Confirmation\n\nThe agent captures two separate screenshots and runs OCR on both independently. If the numbers match, the value is accepted with high confidence. If they differ, a third screenshot is captured and the best-of-three wins.\n\n# Read twice\ntext1 = extract_text(screenshot1)\ntext2 = extract_text(screenshot2)\n\nnum1 = extract_number(text1)\nnum2 = extract_number(text2)\n\nif num1 == num2:\n    return True, num1, \"High confidence\"\n\n# Tiebreaker\ntext3 = extract_text(screenshot3)\nnum3 = extract_number(text3)\n\nif num1 == num3:\n    return True, num1, \"Medium confidence (2/3)\"\nelif num2 == num3:\n    return True, num2, \"Medium confidence (2/3)\"\n\nThis catches transient OCR errors—pixel-level variations between screenshots that produce different readings. The cost is 4-6 extra seconds per financial read. The benefit is catching errors that would otherwise silently corrupt data.\n\nLayer 3: Range Validation\n\nEven a correctly formatted, double-confirmed number can be nonsensical. A balance of \"₦0\" might mean an empty account—or it might mean the OCR failed completely and returned nothing. A balance of \"₦999,999,999,999\" is almost certainly an error.\n\nif 1 <= value <= 1_000_000_000:\n    return True\nelse:\n    return False  # Suspicious. Re-read.\n\nThis catches the edge cases—numbers that pass format and double-read checks but are clearly wrong in context.\n\nThe Celebration\n\nAfter implementing all three layers, I re-ran the 50-test battery. The error rate dropped from 20% to 6%. For the specific \"₦15,000\" test case, 20 out of 20 reads were correct with double-read confirmation.\n\nThe agent now succeeds 19 times out of 20 on multi-app financial tasks. The one failure is a timeout (banking app loads slowly on an old device), not a misread. And critically, when verification fails, the agent now knows it failed. It reports low confidence and aborts the task instead of silently sending wrong data.\n\nWhat This Taught Me\n\nThe bug wasn't in the OCR engine. It was in my architecture. I had built a system that trusted a single, unreliable data source with financial information. That wasn't a Tesseract problem. That was a design problem.\n\nThe fix wasn't a better model. It was a better process. Three cheap, fast checks that together create confidence where no single check could. Defense in depth applied to data integrity.\n\nThis changed how I think about every feature I build. I now ask: \"If this component silently returns wrong data, will I know? If not, where's the verification?\"\n\nThe Code\n\nThe full verification system is open source on GitHub:\n\n👉 github.com/Dexter2344/phone-agent\n\nvision.py contains the verify_financial_data() function. agent.py calls it before storing any financial value in task memory.\n\nThe Build Log\n\nI've been documenting this project publicly for 17 days on Dev.to. Every breakthrough, every dead end, every \"why is this broken\" debugging session at 1 AM.\n\nThis bug was Day 17. The one that almost shipped. The one that whispered.\n\nIt's not the loudest bug I've ever caught. But it's the one that taught me the most.\n\nThis is my entry for the Dev.to Smash Stories contest. The Gemma 4 model powers the agent's command parsing and reasoning. The verification layer is my own work.\n```\n\n", "url": "https://wpnews.pro/news/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it", "canonical_source": "https://dev.to/okeke_chukwudubem_5f3bf49/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it-405n", "published_at": "2026-07-18 18:51:38+00:00", "updated_at": "2026-07-18 19:28:36.858975+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools"], "entities": ["Gemma 4", "Tesseract", "ML Kit", "Sentry"], "alternates": {"html": "https://wpnews.pro/news/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it", "markdown": "https://wpnews.pro/news/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it.md", "text": "https://wpnews.pro/news/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it.txt", "jsonld": "https://wpnews.pro/news/smash-stories-the-bug-that-whispered-for-two-weeks-before-i-heard-it.jsonld"}}