Technical Writing
Notes on distributed systems, AI infrastructure, databases, and observability. Written for engineers who want depth, not surface-level takes.
Databases
1 noteStorage engines, query planners, indexing strategies, and schema evolution.
AI Infrastructure
2 notesMLOps, vector databases, embedding pipelines, and serving large language models.
Nobody Tunes the Recursion Limit
Across six agents in a vulnerability scanner, the number I spent the most time on was never a model parameter. It was recursion_limit. The fallback for hitting it exists in exactly one of the six.
Six AI Agents, Three Ways to Find a Message ID
Claude, Cursor, Copilot, Codex, Gemini and LangChain do not agree on what a message is. Normalizing them collapsed into three strategies: trust the agent's id, borrow one from a file it wasn't meant to share, or invent your own and persist a counter.
Security
3 notesAPI security, threat modeling, supply chain integrity, and zero-trust architectures.
I Built a Red Team Orchestrator for AI Agents. Here's What Made It Hard.
AI red-teaming looks like a prompting problem. It isn't. The hard parts were making attacks survive first contact with a guardrail, validating findings against tool calls rather than text, and a budget race condition that let two requests spend $37 against a $20 limit.
Building an AI Security Engineer Before Coding Agents Could Do It
A hybrid static-analysis, semantic-search and LLM pipeline for finding vulnerabilities in source code, built in 2024 because no model could do it alone. We retired it a year later because they could.
Swagger Knows the Endpoints. It Doesn't Know the Workflow.
Generating requests straight from an OpenAPI spec got 10% of endpoints to execute. Treating the spec as a dependency graph instead of a list got us to ~60%. The last stretch needed an agent, and only because deterministic heuristics had stopped paying.
Distributed Systems
2 notesConsensus, replication, consistency models, and failure modes in large-scale systems.
Kafka, Parallel Consumers, and the 6-Hour Testing Bottleneck
We were running 70,000 security tests in about 6 hours on a shared queue, and I was explicitly not allowed to solve it by adding machines. What that constraint forced was per-message offset tracking, a hard 4-minute timeout, and a state file on disk.
You Don't Need Kafka Internals. You Need Four of Them.
Every Kafka guide hands you the same nine-row config table. In practice almost every failure I've debugged came down to four things: the log's shape, two timeouts people conflate, the rebalance tax, and the fact that auto-commit is a correctness bug with a config flag.