Day 1 ended with a Python script that could extract pose data from a figure skating video. Day 2 was supposed to be the victory lap — detect the actual jump, measure air time, and celebrate.
Instead, my first jump detection algorithm reported 6.47 seconds of air time on a triple Axel that lasted about 0.7 seconds. Not "a little off." Off by an order of magnitude.
Attempt #1: Track the Obvious Signal
The approach seemed obvious. A skater jumps, something moves up, then comes back down. Track the most obvious motion signal across frames, find the peak, measure the duration. Simple physics.
On lab footage — a person jumping straight up in a controlled environment — this works beautifully. Clean parabolic arc, easy peak detection, accurate timing.
On real rinkside footage, it was a disaster. The camera moves. The skater travels horizontally across the ice. Other skaters cross the frame. The obvious signal turns into noise, and the algorithm interprets every camera jitter as the skater leaving the ice.
controlled footage
A simple signal can look elegant when the environment is clean.
rinkside video
Camera motion, travel, and background noise turn elegant into false confidence.
Result: 6.47 seconds of air time. The algorithm was tracking camera shake, not the jump.
Attempt #2: Same Approach, Smaller Tweaks
The natural reaction: smooth the signal. Add a moving average filter. Increase the minimum peak prominence. Tweak the threshold.
This is where most debugging goes wrong — and where my SOP saved me. The second attempt produced 4.2 seconds of air time. Better, but still absurd. A real triple Axel is well under a second.
The problem wasn't the filter parameters. The problem was the entire approach. The obvious metric worked in controlled footage and broke on real rinkside video. Camera movement plus the skater's horizontal travel made the signal meaningless. No amount of parameter tuning fixes a wrong algorithm.
The SOP Kicked In
My workflow has a rule called Blindspot Interception: after two identical failures, force a root cause analysis. After 30 minutes on a dead-end approach, force a strategy switch. Don't tweak — rethink.
On the third attempt, instead of smoothing the same broken signal again, the system did something different. It asked the right question: what physical signal actually indicates a skater is in the air?
Attempt #3: Track What Matters
The answer was embarrassingly simple once you know it: track a different physical signal — one inherently resistant to camera movement. The system stopped asking the video for a generic motion curve and started asking it for evidence that matched the actual skating moment.
Combined with domain constraints — the skater has to leave the ice and come back down — the noise from camera movement was filtered naturally. The wrong signal made every wobble look like a jump. The right signal made the fake jumps disappear.
Result: 0.72 seconds of air time. Within the expected range for a real triple Axel from rinkside footage.
The Debugging Pattern
What made Day 2 instructive wasn't the fix — it was the failure mode. Here's the pattern:
- Attempt 1: Algorithm produces wildly wrong result (6.47s).
- Attempt 2:Same algorithm with parameter tweaks produces slightly less wrong result (4.2s). Developer thinks they're making progress.
- SOP trigger: Blindspot Interception fires — two failures on the same approach means the approach is wrong, not the parameters.
- Attempt 3: Completely different approach. Correct result on first try (0.72s).
The dangerous moment is Attempt 2. The numbers improved, whichcreates the illusion of progress. Without a forced strategy switch, there would have been an Attempt 3, 4, 5 — each slightly better, none correct, each consuming another hour.
Keep tweaking the same broken tracking metric. Each attempt takes 45–60 minutes. After 4–5 attempts and a full day, maybe discover the approach is fundamentally wrong. Maybe not.
Blindspot Interception after 2 failures. Force root cause analysis. Switch to a different physical signal. Correct result within 30 minutes of the strategy switch.
What I Learned
Day 2 taught me the most important debugging principle in AI development:
- Improving wrong numbers feels like progress. 6.47s → 4.2s → 3.1s → ... still wrong. The trajectory of improvement tricks you into staying on a dead-end path.
- Domain knowledge beats algorithm sophistication. The fix wasn't a better filter or a smarter model — it was understanding what "being in the air" physically looks like in a messy rinkside video.
- Forced strategy switches save days. My AI partner would have happily kept optimizing the first metric forever. The rule that forced a rethink after two failures is what rescued the session.
Sometimes the right answer is embarrassingly simple — you just need a system that forces you to stop polishing the wrong ideabefore you've wasted a week on it.
Next: Day 3 — months later, the AI confidently deleted production code labeled "dead." 987 tests passed. The deploy went green. Thirty hours later, a paying customer noticed.
