The gap between "AI says it works" and "it actually works" cost me a clean dataset
I've been building a crypto alert bot using AI-assisted coding — describing features to Claude, getting code back, running it, moving on. It's a fast workflow.
But fast has a failure mode I didn't expect.
What happened
I added a post-alert tracking feature: after each alert fires, log the price at 30 min / 1 hour / 4 hours. Build enough data, figure out the optimal exit window.
The bot ran cleanly for a while. Then I opened the spreadsheet and noticed the 1-hour and 4-hour columns were nearly empty — only the 30-minute column had data.
No errors. Bot still running. Data just... half missing.
The issue: the code AI wrote used an elif chain. Once the 30-minute condition matched, the other branches never ran. Every alert recorded 30 minutes, silently skipped everything else.
I know the elif/if distinction. But I was reviewing AI-generated code at the "does it run?" level, not the "does the logic hold?" level. It slipped through.
Fix: replace the elif chain with independent if statements. Five minutes.
The near-miss
If I'd analyzed that dataset without catching this, my conclusion would have been: sell within 30 minutes, always.
Clean-looking data, no errors, no red flags. I would have built strategy around it. All of it wrong, from a bug that never once complained.
What I changed
When I get code from AI now, my review question isn't "does this work?" It's "what could be wrong with this?"
One question change. It's caught more issues than anything else I've added to the process.
The lesson isn't that AI-assisted coding is unreliable. It's that "runs without errors" and "works as intended" are two different things — and AI only guarantees the first one.
Tags: automation, python, building-in-public, ai
