Five observations from this week. Loose format — things that surprised me, contradicted something I assumed, or changed how I think about a problem.
1. I deleted my way to a fake improvement in YouTube analytics
I delete YouTube shorts that fall below 50 views in their first week. The reasoning: remove clutter, sharpen the signal. What I hadn't accounted for: deleting the worst performers removes them from the denominator.
On 2026-08-11, the headline median jumped from 2.9 to 3.3 views/day. I started writing a note about the improvement. Then I recomputed with deleted videos carried at their last observed value (LOCF correction). The corrected figure was 2.91 — flat. The apparent gain was entirely the deletion.
It got worse with A/B testing. One arm had 36% attrition, the other 44%. The effect size swung between 0.99× and 1.89× depending only on how I handled the missing data. The test is now SUSPENDED rather than reporting a winner. Full writeup here.
The pattern has a name: outcome-dependent censoring. The measurement outcome is exactly the selection criterion for removal. Once you see the shape of the error, you see it everywhere — any system that deletes, archives, or filters its worst observations before aggregating them will drift upward for free.
2. Cadence assumptions are the sneakiest hidden state in GitHub Actions
I published a piece on systematic review of GitHub Actions workflows — running two independent review passes to surface assumptions an author wouldn't notice. Two passes across a batch of workflows found 8 defect categories.
The sneakiest: assumptions tied to cadence. A cleanup window set to 7 days implicitly assumes the generating job also runs daily. A retry backoff of "a few minutes" implicitly assumes the trigger fires less than once per hour. Neither shows up as an explicit constraint in the code. They're encoded in the numbers.
A reader on that article: "every assumption about external systems eventually decays when the load pattern changes." That matches what I've seen. The code is unchanged; the inputs changed. The defect was already there — it just needed the right timing to become visible.
3. The headless Pi scanner hit the same class of implicit constraint
On the edge AI shelf scanner I run on a Raspberry Pi 3, one issue I had to handle explicitly after an audit pass was scan collision — a new cron run starting before the previous scan finished. At median 8.5 seconds per inference on an hourly cycle, it almost never matters. But SD card writes, post-processing, and occasional outliers (range went to 11.8 s across 19 real scans) can push the total runtime higher.
The collision case wasn't in any spec. It was implicit in the assumption that "hourly scans are fine" — which is true until they aren't, and the failure mode isn't a crash, it's corrupted scan history. Recognizing it required thinking through what overlapping runs would actually do, not just whether the timing worked on average.
Same shape as the GitHub Actions cadence problem: the constraint was real but invisible until someone asked "what breaks at the boundary?"
4. Production HuggingFace downloads are dominated by models nobody blogs about
Two pieces this week on what actually leads production downloads in the aiappdex model catalog:
all-MiniLM-L6-v2 has 246 million downloads. BERT-base-uncased from 2018 has 58.6 million. Both sit above any text-generation model in the catalog. The non-text production models — CLIP, MobileNetV3, Chronos-T5-Large for time series — have their own substantial download bases and cover use cases that LLMs don't touch.
The models that dominate AI news — frontier chat models, large instruction-tuned LLMs — don't appear near the top of production download counts. This isn't a criticism of coverage. It's a gap between what gets discussed and what gets used: embedding models and smaller classification baselines still power most production inference. The discourse is shaped by what's interesting to write about.
5. Detection lag tells you more than uptime ever did
This week's piece on detection lag vs. uptime covers something I keep coming back to: six failures in this repo with detection lags ranging from 36 to 113 days, all while the jobs stayed green.
The common pattern: the job produced a well-formed output file. An empty array is not an error. A file with wrong numbers isn't a parse failure. A published article that nobody reads doesn't throw an exception. The job finished, the badge went green, nothing in the monitoring flagged it.
Measuring how long it takes to notice a failure — not whether the job ran — gives a more honest picture. It also tells you where to invest monitoring effort: not at the process boundary (did the job exit 0?) but at the output boundary (does the content of this file look plausible?). The pipeline health question isn't "is it running?" It's "when it breaks, how long until I know?"
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)