From order, chaos. From courage, fear. From strength, weakness.
— The 36 Stratagems, "Make a Sound in the East, Strike in the West"
Alex neve...
For further actions, you may consider blocking this person and/or reporting abuse
Ngl, that's why large corporations lose millions, while small corporations lose alot less. Scale. A small corp fights to win back 1%, while large corps breeze off 10%... That compounds and the day it gets noticed, it's already cost 10x what it would have with the same diligence as a small corp. It's not that the dev's are incompetent, it's the bureaucracy behind 'management' and 'roles' that lead to valid inputs being shot down, because 'that's not your job', or 'we trust our million dollar AI over you'. While a small corps takes every input seriously and only dismisses it once proven, large corps' structure sees is as toe-stepping acting out of line. Result range from "Tell me first", to "you've been put under review", not because you're wrong, but because you're right and they see it as a threat. Whether it's a threat to their own job, or a threat to the company's investor program. Fact is, no company has earned their trillion dollar valuation on pure merit, it's been stat sheets and investments, inflation that balloons egos and guardrails investor previews above correctness... A "1000 tests ran, 1% error rate", looks better than "1100 test ran, 10% error rate". Summarizing to a confidence threshold is wrong... Instead, logs should be more descriptive, eg. tagged with 'simple retry', or 'failover', or 'data-corruption', so the scoped logs can tell the real story. Every single 'data-corruption' tagged error should be in every summary, while 'simple retry' is less useful, 'failover' is less useful. Both of those arent breaking failures, unless they hit a threshold... That's the level of detail small corps fixate on, while large corps just look at % covered.
The 1,530 filtered flags thing — that's exactly what your tagging idea fixes. 'data-corruption' always in the summary, 'simple retry' folded away unless it hits a threshold. That's the kind of detail that makes small-team diligence scale.
It comes back to an old project of mine, V.A.L.I.D. which let you tag things a little smarter than standard C# or CSLA, so it's not just 'warning, error', tag it and filter it in your log view, so you know what is code red, vs ignorable. V.A.L.I.D. was written as the definitive path for large-scale C#/F# refactoring, because it produces 80% of the code, you just declare your DTO with ValidObjects and the layout of your UI and everything is wired for you, including a MCP, Unit Tests and a UI fuzzer for REAL UI testing at scale, so you can test the actual app in use on a dummy db.
The key being, all of those 1530 errors have an origin, half are in improperly done boilerplate, the remainder are from improperly set up endpoints, data access layers and business objects (or their equivalent). So when you create the 20%, you put in 100% effort, by making sure you tag everything properly, because the overhead you save on everything else, you can spend on making sure everything is perfectly scoped, with constraints, rules, permissions, tags, etc. Without even touching AI (though the architecture does have a MCP and skill for codebase refactoring and creation to make sure the LLM doesnt mess up).
For perspective, my employer's codebase throws 3000+ warnings on each build. 99% of those could be solved with V.A.L.I.D. letting the team focus on the remaining 1% diligently. Consistency is what allows a codebase to operate for 20 years without failure, not LLM interpretability.
V.A.L.I.D. sounds like the kind of thing that makes QA actually sleep at night. From a testing perspective, consistency = testability. If everything's wired the same way, you write one test setup that works everywhere — not 30 different ones that all break for different reasons.
The UI fuzzer on a dummy db though — that's the part I'd steal. Most "AI testing" tools just screenshot-diff and call it a day. A fuzzer that hits live UI with real data patterns and checks what actually breaks? That's where testing should be heading.
And 3000 warnings per build is wild. Not because of the number — because when everything's a warning, nothing is. QA can't prioritize what's buried in noise.
Exactly. Oh upside of V.A.L.I.D. writing everything non-unique, beyond consistency, is that by generating the in-betweens, it can translate to the most optimal possible. Eg. It will actively convert your written language to a different compiled language. What you write in C#, converts to F#, so developers write easier, while it makes sure it runs faster. Result is getting over 3600 mutations (multi-rule driven concurrency across multiple UI elements at once) per second, by bypassing the VDOM entirely, actually making frameworks like Blazor useable for real apps, not just basic forms (which at max hits 650/s without rules or linkages). It's quite a piece of work if I do pat myself on the back.
3600 mutations/s is definitely worth a pat on the back. I'd do the same 😂
But real talk — how do you keep up with verifying the results at that speed? Not questioning whether it runs, just curious how you know it changed the right things after all those rounds. For testing, find speed and verify speed need to match, or faster just means harder to trace.
The confidence threshold problem here is a textbook example of why static thresholds break at scale. The 70% cutoff made sense when MedTech was handling 50K orders a day â low confidence genuinely correlated with false positives, mostly edge cases the model hadn't seen enough of. But at 100K orders, the "low confidence" bucket starts capturing a completely different distribution: not noisy false positives, but genuine edge cases that legitimate edge cases â novel supplier combinations, unusual batch configurations, cold-chain anomalies in novel contexts.
The model isn't getting worse at those thresholds. The population it's operating on has changed. The threshold that was a signal-to-noise filter has quietly become a systematic blind spot.
What makes this insidious is that it's technically compliant. The raw logs have everything. The database has everything. Only the audit report has the hole â and an auditor checking the report sees clean numbers, not the 1,530 filtered events sitting in logs nobody looked at.
This pattern shows up constantly in AI monitoring: confidence thresholds, relevance cutoffs, sampling rates â all calibrated against yesterday's data distribution, all silently degrading as the system scales. The fix isn't just lowering the threshold. It's building observability into the filtering layer itself: monitoring what gets filtered, not just what passes through.
The "yellow not red" insight is also quietly brilliant. Red alerts have response protocols. Yellow alerts have skepticism. That asymmetry is exactly what makes yellow the more dangerous lane for real anomalies to hide in.
This is exactly the pattern I see in test automation too. We optimize for what fits in the dashboard — pass rate, coverage percentage — and those numbers look great. But they're only measuring what we decided to measure. The blind spot isn't in the execution, it's in the selection of what to monitor.
"Monitoring what gets filtered, not just what passes through" — that should be a rule for dashboards everywhere. What'd you run into that made you frame it this way? Sounds like personal experience talking
Intriguing one - maybe it lacks a bit of the drama of the other episodes, but there are some subtle points well made here - and I see that this episode elicited a number of thoughtful comments, so I won't try to repeat what others have already articulated very well !
Appreciate you saying that — and you're right, this one's quieter than the others. Not every compliance war room ends in a fire drill. Sometimes the win is just getting the config changed and having no one notice 😅
Glad the subtle points landed though. Those are the ones that take the most rewriting.
All six protagonists have done their solo debut now. Which means the 36 Stratagems series is officially 1/6 done🎉. Wait — that also means 5/6 to go. 😭 Words once said gotta be delivered. Seriously though, thanks to everyone who's been reading. Comparing the new series to the old one, the likes and comments aren't even close — still blows my mind.
Next post won't be Stratagem #7 yet. Need to pause, do a proper retrospective, and figure out what I've learned so far. More soon.🤣
Okay... I did not expect this post to go in this direction. 😄 I thought it would be another AI compliance article, but that twist with the hidden low-confidence alerts genuinely caught me by surprise.
What stood out to me the most wasn't the configuration change itself—it was the moment when Alex realized that 1,530 low-confidence alerts had been silently excluded, and 58 of them later turned out to be valid issues. That completely changed the way I think about AI-generated dashboards. We often celebrate a clean dashboard, but this post reminded me that sometimes the absence of alerts can be just as dangerous as the presence of them.
Another part I really appreciated was Alex's response when he was questioned about changing the threshold. He wasn't trying to prove he was right or make anyone look wrong—he simply wanted the system to stop hiding information that could actually matter. That small conversation at the end felt surprisingly realistic because in real projects, technical decisions are often as much about communication and trust as they are about code.
One more thing I liked was that the article didn't paint AI as either "good" or "bad." Instead, it highlighted something much more important: AI decisions are shaped by the rules we give it. If those rules filter out useful signals, the dashboard may look perfect while reality tells a different story. That's a subtle but powerful message.
Really well written. This is the kind of post that stays in your mind even after you've finished reading it.
And now... after making all of us question every green dashboard we see, I think you've earned a break. :D Go enjoy your Nintendo... I'll just open my old Nokia and play Snake while pretending my dashboard is 100% compliant too. 🐍
Honestly you read way more into it than I did while writing 😂 "Absence of alerts is more dangerous than presence" — that hit different coming from someone else.
The 1530 thing is semi-real btw — took it from an actual incident, just exaggerated a bit for the story 🤏. So yeah you're spot on about rules shaping output.
Anyway, it's the weekend — go relax, play some games (and I mean all kinds, not just video games). That's the important thing. 🎮🤣
@technogamerz Apologies for the wait — Stratagem #6 is finally out, so now I can get back to playing my Switch. 😂
Why are you apologizing to @technogamerz!! She doesn't even write posts!!