July 22, 2026
I Asked an AI to Review My Code — It Caught a Bug I’d Missed for Days
I was already confident the logic was correct. I was wrong, and the reason why taught me more than the fix did.
By Babar saad
2 min read
I had a function I was sure was fine. It had been running for days without an obvious crash, passed my manual spot-checks, and looked clean enough that I stopped double-checking it. Out of curiosity more than need, I pasted it into an AI assistant and asked for a review. What came back wasn't a style nitpick — it was a real bug, sitting exactly where I'd stopped looking.
The Function I Was Confident About
The code filtered a list of user records, keeping only "active" users above a certain signup date:
```python
def get_recent_active_users(users, cutoff_date):
result = []
for user in users:
if user["active"] == True and user["signup_date"] > cutoff_date:
result.append(user)
return result```python
def get_recent_active_users(users, cutoff_date):
result = []
for user in users:
if user["active"] == True and user["signup_date"] > cutoff_date:
result.append(user)
return result
It had run in production for days. No errors. No crashes. I genuinely thought it was done.
**What the Review Actually Caught**
The AI flagged one specific line: `user["active"] == True`. Its point was simple — if `active` is ever missing from a user record instead of explicitly `False`, this comparison silently evaluates to `False` and the user just… disappears from the result. No error. No warning. Just quietly wrong output.
I checked the data. Sure enough, a batch of older user records didn't have the `active` field at all — they predated when that field was added to the schema. Every one of those users was being silently excluded from "recent active users" reports, and nothing about the code would have told me that. It just looked like fewer users than expected, which I'd been chalking up to normal fluctuation.
**Why I'd Missed It Myself**
I'd tested this function against sample data I created myself — and every test record I wrote naturally included the `active` field, because I already knew it existed. I was testing against my own mental model of the data, not the actual data, which had a gap I didn't know to look for.
That's the part that actually stuck with me: the AI didn't catch this because it was smarter about the business logic. It caught it because it wasn't carrying my assumption that every record would have that field.
**The Fix**
```sql
```python
def get_recent_active_users(users, cutoff_date):
result = []
for user in users:
if user.get("active", False) and user["signup_date"] > cutoff_date:
result.append(user)
return result
It had run in production for days. No errors. No crashes. I genuinely thought it was done.
**What the Review Actually Caught**
The AI flagged one specific line: `user["active"] == True`. Its point was simple — if `active` is ever missing from a user record instead of explicitly `False`, this comparison silently evaluates to `False` and the user just… disappears from the result. No error. No warning. Just quietly wrong output.
I checked the data. Sure enough, a batch of older user records didn't have the `active` field at all — they predated when that field was added to the schema. Every one of those users was being silently excluded from "recent active users" reports, and nothing about the code would have told me that. It just looked like fewer users than expected, which I'd been chalking up to normal fluctuation.
**Why I'd Missed It Myself**
I'd tested this function against sample data I created myself — and every test record I wrote naturally included the `active` field, because I already knew it existed. I was testing against my own mental model of the data, not the actual data, which had a gap I didn't know to look for.
That's the part that actually stuck with me: the AI didn't catch this because it was smarter about the business logic. It caught it because it wasn't carrying my assumption that every record would have that field.
**The Fix**
```sql
```python
def get_recent_active_users(users, cutoff_date):
result = []
for user in users:
if user.get("active", False) and user["signup_date"] > cutoff_date:
result.append(user)
return result
Using `.get("active", False)` instead of directly indexing means a missing field is treated as explicitly inactive, instead of silently crashing or (in this case) silently mismatching. One line, and it required knowing the bug existed in the first place.
**What It Didn't Catch (Because I Want to Be Honest About This)**
The review didn't flag that `signup_date` comparisons would break if the dates were sometimes strings and sometimes datetime objects — a real inconsistency in a different part of my codebase that I only caught later, by hand, because I already knew to check for type mismatches from experience. The AI is good at catching what's visible in the code you show it. It has no way of knowing what your data actually looks like unless you tell it — which is exactly why the missing-field bug was catchable and the type-inconsistency bug wasn't.
**My Honest Verdict**
I didn't come away thinking an AI review replaces careful testing. I came away with a much narrower, more useful takeaway: it's very good at spotting the specific class of bug where your code silently assumes something about your data that isn't guaranteed to be true — because it isn't carrying the same assumptions you built up while writing the code in the first place.
If you've got a function you're "sure" is fine, that's exactly the kind of code worth a second pair of eyes — yours has stopped looking for problems in it, and that's precisely where they hide.
### Before you go
- Please take a moment to like the post and follow the writer!
- Did you know that over 400,000 developers share what they're building, learning, and discovering across our platforms every month? Learn how you can contribute [here](https://plainenglish.io/write-for-us)
Using `.get("active", False)` instead of directly indexing means a missing field is treated as explicitly inactive, instead of silently crashing or (in this case) silently mismatching. One line, and it required knowing the bug existed in the first place.
**What It Didn't Catch (Because I Want to Be Honest About This)**
The review didn't flag that `signup_date` comparisons would break if the dates were sometimes strings and sometimes datetime objects — a real inconsistency in a different part of my codebase that I only caught later, by hand, because I already knew to check for type mismatches from experience. The AI is good at catching what's visible in the code you show it. It has no way of knowing what your data actually looks like unless you tell it — which is exactly why the missing-field bug was catchable and the type-inconsistency bug wasn't.
**My Honest Verdict**
I didn't come away thinking an AI review replaces careful testing. I came away with a much narrower, more useful takeaway: it's very good at spotting the specific class of bug where your code silently assumes something about your data that isn't guaranteed to be true — because it isn't carrying the same assumptions you built up while writing the code in the first place.
If you've got a function you're "sure" is fine, that's exactly the kind of code worth a second pair of eyes — yours has stopped looking for problems in it, and that's precisely where they hide.
### Before you go
- Please take a moment to like the post and follow the writer!
- Did you know that over 400,000 developers share what they're building, learning, and discovering across our platforms every month? Learn how you can contribute [here](https://plainenglish.io/write-for-us)