The Night My Routine Caught Its Own Bug

I recorded 49 minutes of my computer working without me. Three routines run on a schedule every evening: two of them trade, and the third builds a video report of every position I'm holding. I hit record, sat back, and narrated.

The most useful two minutes were the ones where nothing appeared to be happening.

That's the honest headline of this whole experiment. Not "AI built my thing" — it did, and that's fine — but that the interesting part of automation is never the part you'd put in a demo. Here are five things that night actually taught me, each of which cost me something to learn.

1. A check that can't fail isn't a check

Partway through the run, the video routine hit a position it couldn't chart. Rather than shrugging and rendering a blank panel, it stopped, traced the problem, and found the cause: my code recognized coins bundled in thousands by a lowercase k prefix — kPEPE, kBONK — but the live data had just sent one in uppercase, KSHIB. Nothing matched. No chart, and worse, a price that would have been drawn a thousand times too high.

That bug had been sitting in the code since day one. It only surfaced because the exchange happened to send an uppercase ticker that night, and it only got caught because the routine's checks were written so they could actually fail. There's a real assertion in there that says: this position's entry price must be within an order of magnitude of the last close. That one line turned a silent, wrong chart into a loud stop.

Trust, but verify is one of my favorite mantras. Another dividend earned.

The rule: if your verification step can't return "no," it isn't verification. It's decoration. An AI agent reporting "done" is not evidence. A test that fails when the thing is broken is evidence.

2. Fix narrowly, or you break the thing next door

The obvious fix was "also accept uppercase K." The obvious fix was wrong.

There are real coins that legitimately start with K — KAVA, KDA, KSM, KAITO. Strip the K off those and you'd be charting a coin that doesn't exist, silently, forever. The fix that shipped only treats an uppercase K as a bundle marker when what follows it is a known bundled ticker, and leaves every genuine K-coin untouched. Then it proved the fix numerically: the corrected price matched the market's own price for the same coin, to the decimal.

The rule: when you're fixing a pattern-matching bug, the question isn't "does this fix my case?" It's "what else does this now match that it shouldn't?" Narrow fixes are boring and they let you sleep.

3. Your data's noise floor moves

Later, editing the recording, I wanted to cut the waiting. I wrote something to detect silence and trim it. It found almost nothing.

The reason turned out to be a faint hum in the room. My "silence" wasn't silent — it sat around −56 decibels while my voice ran around −38. My threshold was set at −58, tuned from the recording's overall quiet, so a stretch of pure hum registered as sound and survived the cut. Ninety-five seconds of nothing, right in the middle.

The instinct is to just move the threshold. I tried, and the opposite happened: it started eating real narration, cutting a 46-minute recording down to 15. The hum wasn't constant across the whole file — it came and went — so no single number worked anywhere.

What worked was two rules instead of one: cut anything very quiet for two seconds, or anything moderately quiet for twelve. Short pauses in speech survive. Long stretches of nothing don't. The confidence comes from the duration, not just the level.

The rule: when you tune a threshold, measure your own data instead of trusting a constant — and if the thing you're measuring drifts, one threshold will never fit. Two cheap rules often beat one clever one.

4. The boring part might be the actual content

Here's where I got it wrong and got corrected.

That 95-second dead stretch? I'd been treating it as a problem to delete. But there was no narration because I was watching the screen — where the routine was working through the bug in full view, reasoning line by line. It wasn't empty. It was the best content in the whole recording, and it just happened to be silent.

Deleting it lost the story. Keeping all 95 seconds of it was unwatchable. The answer was neither: run it at six times speed, put music under it, and add callouts pointing at what just happened. Twenty-one seconds, all the content, none of the tedium.

The rule: before you cut the boring part, check whether "boring" means "nothing is happening" or "nothing is happening loudly." Those are very different problems with very different fixes.

5. Silent truncation is the failure you won't notice

One more, quieter than the others. That evening's report had a chart of market breadth at the end, meant to show the last hundred days. It showed thirty.

Nothing errored. The routine had pulled all hundred days and then, writing them to disk, only saved thirty — an efficiency shortcut that cost nothing visible. The chart's title even said "last 30 days," because it counted what it had. Everything was internally consistent and quietly wrong.

I only caught it because the number looked odd against how long I'd been running the thing. Now there's a guard: if fewer than sixty days arrive, the build fails and says why.

The rule: the dangerous failures aren't the ones that crash. They're the ones that produce a smaller, plausible answer. Anywhere your workflow summarizes, samples, or "keeps the important ones," put a floor under it and make it shout when it drops through.

What I'd actually tell you

If you're pointing an AI tool at something that matters — your files, your books, your calendar, a report someone will read — the pattern from this night generalizes better than any individual trick:

• Ask for the check, not the claim. "Confirm it worked and show me how you know" beats "did it work?"
• Make the check able to fail, and go break it once on purpose to prove it can.
• Watch for answers that are smaller than expected. Those are the quiet ones.
• Fix the narrow case. The broad fix has collateral you haven't imagined yet.

None of that requires you to be technical. It requires you to be a little skeptical in a specific, repeatable way — which is most of what I teach, honestly. Trust, but verify.

For the record, the routine wrote that bug fix, but it didn't ship it alone: I read the change, checked what else it could match, and committed it myself. The automation moves the mechanics. The approval stays human.

You can watch the whole run — bug and all — in the video that goes with this post. It's twenty minutes of a laptop doing chores, which is either the most boring thing on the internet or exactly what you've been wanting to see before you trust one of these things with your own work.

If you want help setting this kind of verification habit up around your own tools, book a free 30-minute intro call — no pitch, just your setup and what you're trying to get done.

Not financial advice. The positions in the video are my own small experiment; the subject here is the automation, not the trades.

#ernestGoesToAI