Don't fight in clear water โ stir it first. Don't strike when they're watching โ strike when they're looking somewhere else.
โ The 36 Stratagems, ...
For further actions, you may consider blocking this person and/or reporting abuse
What stood out to me isn't the reveal that someone else was inside the pipelineโit's how Alex arrives at that conclusion.
Most engineers investigate anomalies as isolated events. Alex investigates consistency. A perfectly linear 1.5% weekly decline is almost suspicious because it is too clean. Random systems rarely produce disciplined degradation; people do. That shifts the investigation from "What failed?" to "Who is maintaining this pattern?"
I also liked the transition from metrics to software craftsmanship. Instead of treating code style as aesthetics, the story treats it as operational telemetry. Four services performing unrelated jobs but sharing the same minimalist fingerprint (pure functions, identical naming philosophy, absence of comments) become a form of developer attribution. In reality, organizations spend enormous effort fingerprinting binaries while often overlooking that engineering habits themselves can become signatures.
Another subtle point is that throughput contradicts declared intent. The timestamp aligner isn't exposed because its code is malicious; it's exposed because its resource profile doesn't match its stated responsibility. That's a lesson that extends well beyond AI systems: validating behavior is often more powerful than reviewing implementation.
From a storytelling perspective, I appreciate that the antagonist remains invisible. The tension comes from inference rather than confrontation. Every clue is individually explainable, but together they create a Bayesian accumulation of evidence until the alternative explanations become less probable than the existence of another operator. That's a much more satisfying investigative arc than relying on a dramatic "smoking gun."
It also mirrors a broader security principle: sophisticated adversaries rarely leave obvious artifacts. They leave correlationsโtiming, style, deployment cadence, infrastructure placement, and statistical regularity. The investigator who notices relationships between weak signals often succeeds where someone searching for a single critical alert fails.
Finally, the title lands differently after reading the piece. "The AI collector slowed down" sounds like an infrastructure issue, but the story reframes it as a psychological moment. Alex doesn't recognize a machine problemโhe recognizes another engineer's fingerprints. The collector slowing down isn't the discovery; it's merely the first sentence in a conversation between two unseen operators who are communicating through system behavior instead of words.
That's what I enjoyed most: this chapter isn't really about AI. It's about observation, attribution, and the idea that complex systems quietly preserve traces of the humans who shape them.
Thanks for sharing โค๏ธ :D
Alex has always been my favorite character. Quiet, but technically brilliant. When everyone else's attention drifts, he's the one who stays cool โ and he's the type to bend the rules just enough without breaking them. Really glad you enjoyed #20. See you at #21 โ maybe the day after tomorrow, maybe the day after that. No clue honestly๐คฃ
Thanks for not making a promise.๐ญ
Haha, it's already in draft stage โ rest easy๐คฃ
By the way, the advice you gave yesterday really came in handyโplease share some more wisdom today as well!
I'm not some wise old sage, you know~๐คฃ
@xulingfeng really enjoyed this. As someone who works with AWS infrastructure, Linux, automation, and monitoring, what resonated with me most wasn't just the technical detail but the mindset. Watching patterns instead of waiting for alerts is something that translates directly to real-world operations, so by the time an alert fires, the signals have often been there for a while.
I also liked how you blended the technical concepts with storytelling. The subtle use of latency, mirrored traffic, and operational discipline kept it grounded while making the stratagem come alive. Looking forward to seeing how Alex and P's timelines continue to converge. Great work!๐
@ndcodes
My goal for this series has always been: technically solid enough to use in production, and story-driven enough to keep people reading. Your comment means I'm hitting both marks โ and that genuinely makes me happy.
Pretty dashboards are the emperor's new clothes. Someone has to be the kid who calls it out. That's what this series is for. #21 is already in the pipeline. Stay tuned ๐ซก
Really enjoyed the โwatch patterns, not alertsโ theme. One technical detail made me pause, though: TTL 247 is an interesting clue, but concluding โinitial TTL 255, exactly eight hops, therefore a Unix-class silent gatewayโ feels stronger than the evidence allows.
Initial TTL values can be configured, and tunnels, overlays, NAT, middleboxes, or asymmetric paths can distort the apparent hop count. TTL can narrow the possibilities, but usually needs corroboration from TCP options, window scaling, MSS, IP ID behaviour, repeated captures, or traceroute data before attributing a device class.
That uncertainty could actually make the scene even stronger: Alex would know he had found an unusual responder, but not yet exactly what was behind the door. The evidence becomes a lead rather than a conclusion โ which fits the investigative tone of the series perfectly.
Good catch, @merbayerp . TTL 247 is a lead, not a proof โ you're right about that. I trimmed Alex's reasoning for pacing, but "evidence becomes a lead rather than a conclusion" is exactly how it should've been framed.
Honestly, this is the part of the series I struggle with most. Strict POV means the characters can only reason from what they actually see, and I'm always one step away from handing them the answer myself instead of letting them earn it. Still figuring that out. ๐
Your point's definitely coming with me into the next one โ this exact tension gets a lot more screen time there.
I think thatโs exactly the balance. Readers donโt expect the characters to be omniscientโthey expect them to make reasonable inferences from incomplete evidence. Leaving a little uncertainty actually makes the investigation feel more authentic, because thatโs how real incident response usually works. Looking forward to seeing how you handle that tension in the next chapter.
The latency curve is a good choice because it makes the conflict technical instead of just dramatic. Below-threshold drift is exactly where a lot of real monitoring systems get fooled. The alert says nothing happened, but the shape says someone changed the load path. That is a much more convincing AI-security signal than another โthe model noticed everythingโ scene.
Exactly โ the alert is the last thing to change in these systems. The shape moves first, and only if you're watching the shape do you notice. Most of the monitoring I've tuned in test environments taught me to distrust the rule and trust the curve.
I like these "AI Post-Mortems", they're helpful and that was especially the case for this episode!
For instance:
"... this is the first observed instance of two operators producing de facto collaboration on the same target within the same time window, without either party actively coordinating ..."
and
"... I'm starting to wonder โ they didn't choose the same target. The same target chose both of them ..."
are particularly "to the point" and elucidating ...
So, maybe both 'actors' think they're "playing", while actually they're "being played"? ;-) ;-) ;-)
P.S. oh and that tacit guy behind the counter at The Third Cup, who never speaks but just handles his cups - he might be more 'significant' than we thought ...
Haha, the AI post-mortems are proving more and more useful โ the information gap effect is crystal clear.
I paused for a second when I read this: "Alerts tell you what broke. Patterns tell you what's changing."
That's a really nice way of describing the difference between fixing problems and seeing them coming. Looking forward to the next chapter!
Ha, you caught the exact line I was most proud of in this one. "Alerts tell you what broke. Patterns tell you what's changing" โ that's the whole series' philosophy in one sentence, and Alex is the character who lives it.
Appreciate you reading both chapters back to back. The next stratagem is already sitting in my drafts โ though I'll read it a few more times myself first, hunting for bugs. QA habits die hard, haha.
Hi @xulingfeng! Loved the chapter. Why did Alex choose a mirror percentage of 30% for the probe instead of capturing 100% of the mirrored traffic?
Hi @mia_keller_ffd2584c046ecb ๐
Great question. Alex isn't after completeness โ he's after plausible deniability. 30% mirror reads as a routing hiccup, not a probe. 100% would've tripped something before the first packet landed. A glimpse is enough โ there's an old Chinese saying, "็ฎกไธญ็ชฅ่ฑน" (looking at a leopard through a tube): see one spot, know the whole animal. Alex only needed that one spot. And he got the TTL 247.