Notification badges look simple.
New message → increase count
Read message → decrease count
That’s it… right?
That’s what I thought.
So I created a small challenge on VibeCode Arena to test this.
And things got interesting very quickly.
🚨 The Problem
At first glance, the logic works:
- Add notifications
- Mark them as read
- Count unread messages
Everything seems correct.
But real-world systems are not that simple.
⚠️ What Can Go Wrong?
In real applications:
• Some notifications may not have a read property
• Invalid indexes can break the system
• Duplicate notifications can inflate the count
• UI and backend can go out of sync
And suddenly:
👉 Users see wrong unread counts
👉 Notifications behave inconsistently
👉 User experience breaks
🧠 What I Observed
When AI models tried this challenge:
- Some handled basic counting logic
- Many ignored missing fields
- Some didn’t validate inputs
- Very few considered real-time consistency
The code works.
But the system is not reliable.
🔍 The Real Issue
This is not just about counting.
It’s about state management.
Because:
👉 Notifications change over time
👉 State must stay consistent
👉 UI must reflect correct data
🔥 Try My Challenge
I created this challenge to test real-world frontend + backend thinking.
👉 Try it here:
https://vibecodearena.ai/duel/c0edcf8e-3338-4555-a621-4a0a582aaa11
Can you:
- Fix incorrect unread counts?
- Handle edge cases properly?
- Keep UI and data in sync?
💡 Final Thought
Notification badges don’t fail because of counting.
They fail because of state inconsistency.
And that’s where real engineering begins.
Try it and tell me 👇
Did AI get the count right… or miss something important?
Top comments (0)