Security is eBPF's third domain, and arguably its most natural fit: the kernel sees every syscall, every process, every file access and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
Security is eBPF's most natural fit: the kernel sees every syscall, process, file access, and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
A voice demo that works in a quiet room with a good headset is a long way from a voice agent that survives a noisy phone call from a real customer. Production voice AI has to handle bad audio, unpredictable humans, failures at every stage, and the peculiar demands of telephony — and it has to be evaluated in ways text systems never require. This closing post is about making a voice agent real.
A voice demo that works in a quiet room with a good headset is a long way from a voice agent that survives a noisy phone call from a real customer. Production voice AI has to handle bad audio, unpredictable humans, failures at every stage, and the peculiar demands of telephony — and be evaluated in ways text systems never require. Making a voice agent real.
A knowledge graph you can't query is just a diagram. The power of the graph is realized when you can ask it questions — and querying a graph is fundamentally different from querying tables. Instead of joining rows, you describe a pattern of connections and ask the graph to find every place that pattern occurs. This post covers SPARQL, the standard query language for RDF graphs, and the graph-pattern-matching mindset that makes graph queries so expressive for connected questions.
Querying a graph is pattern matching, not joining: you describe a shape of nodes and edges and the engine finds every match. SPARQL (and Cypher for property graphs), path expressions for arbitrary-depth connection that SQL can't express, and inference-aware queries over the reasoned graph.
How good is a coding agent, really? The honest answer requires evaluation — measuring whether an agent can actually resolve real software tasks, not just produce plausible-looking code. Benchmarks like SWE-bench made coding-agent progress measurable by testing agents on real GitHub issues verified by real tests, and understanding how coding agents are evaluated (and the pitfalls) is how you cut through the hype to what agents can actually do. This post is about measuring coding-agent capability honestly.
How good is a coding agent, really? Because code is verifiable, you can measure task resolution by tests on real issues — which is what SWE-bench does. The pitfalls that inflate numbers (contamination, overfitting, weak tests, cherry-picked demos), and why your real tasks are the real benchmark.
The most powerful idea in recommendation is also the simplest to state: you can recommend things to someone based purely on the behavior of people like them, without knowing anything about the items themselves. Collaborative filtering turns "people who liked what you liked also liked X" into an algorithm, and it's the backbone of the whole field. This post covers how it works and why it's so effective — and where it breaks.
The most powerful idea in recommendation is also the simplest: recommend things based purely on the behavior of people like you, without knowing anything about the items themselves. Collaborative filtering turns 'people who liked what you liked also liked X' into an algorithm, in user-based and item-based flavors — the backbone of the whole field, and where it breaks (cold start, sparsity).
Networking is where eBPF delivers its most dramatic performance wins. By running packet-processing logic in the kernel — at the earliest possible moment a packet arrives, before the kernel even builds its usual data structures — eBPF can filter, route, and load-balance at speeds user-space networking can't touch. It's why the networking layer of modern cloud-native infrastructure is increasingly eBPF underneath.
Networking is where eBPF delivers its most dramatic performance wins. By running packet-processing logic in the kernel — at the earliest moment a packet arrives, before the kernel builds its usual data structures — eBPF can filter, route, and load-balance at speeds user-space networking can't touch. It's why modern cloud-native networking is increasingly eBPF underneath.
The cascaded pipeline — ASR, then LLM, then TTS — has powered voice agents for years, but it has an inherent ceiling: every stage adds latency and every conversion loses information. A newer architecture collapses the three models into one that goes from speech directly to speech, promising lower latency and richer understanding. This post compares the cascade with the emerging end-to-end approach, and where each fits.
The cascaded pipeline — ASR, then LLM, then TTS — has powered voice agents for years, but it has an inherent ceiling: every stage adds latency and every conversion loses information. A newer architecture collapses the three models into one that goes from speech directly to speech, promising lower latency and richer understanding. Comparing the cascade with the emerging end-to-end approach.
You've seen what an AI gateway does; the last question is how to get one — build it, adopt an open-source proxy, or use a managed service — and how to run it once you have it. This closing post assembles the full architecture, weighs build-versus-buy honestly, and covers operating the gateway as the critical piece of infrastructure it becomes.
You've seen what an AI gateway does; the last question is how to get one — build it, adopt an open-source proxy, or use a managed service — and how to run it once you have it. This closing post assembles the full architecture, weighs build-versus-buy honestly, and covers operating the gateway as the critical infrastructure it becomes.
An ontology is the blueprint; a knowledge graph is the building. A knowledge graph is a network of real-world entities and the relationships between them, structured against an ontology so that both humans and machines can navigate it, query it, and reason over it. They power web search, recommendations, fraud detection, and increasingly the grounding of LLMs — and understanding what makes a graph a "knowledge" graph is understanding why this shape of data keeps winning for connected problems.
A knowledge graph is the ontology populated — entities as nodes, typed relationships as edges, integrated from many sources. RDF vs property graphs, and why graphs win for connected problems: relationships are first-class (traversal, not join cascades), the schema flexes, and meaning lives in structure.
A coding agent can produce a confident, plausible change that's subtly wrong — and the whole value collapses if you can't tell. Verification is how you know the agent's code actually works, and trust is what you build (or lose) based on it. Because code is verifiable, coding agents can check much of their own work — but the human reviewer remains the final, accountable arbiter. This post is about verifying agent-written code and the trust that makes coding agents usable.
A coding agent can produce a confident, plausible, subtly-wrong change — verification is how you know it's actually right. Why verification drives the agent's self-correction AND your trust, the layered toolkit (tests, type-checks, diff review, human review), and the rule: trust is earned through verification, and the human stays accountable.
Every time a streaming service suggests what to watch, a shop shows "you might also like," or a feed decides what you see next, a recommender system is at work. Behind that simple experience is one of the most economically important and technically rich problems in applied machine learning: from a catalog of millions, pick the handful a specific person will want, right now. This series builds recommender systems from the ground up.
Every time a service suggests what to watch, buy, or read next, a recommender system is at work — one of the most economically important and technically rich problems in applied ML: from a catalog of millions, pick the handful a specific person will want, right now. This series builds recommender systems from the ground up, starting with the problem and the two-stage architecture that structures nearly all of them.
Observability is where eBPF first went mainstream, and for good reason: it lets you see almost anything the kernel sees — syscalls, function calls, network events, disk I/O — with very low overhead and, crucially, without changing the code you're observing. That combination broke a long-standing trade-off in tracing and profiling, and it's why modern observability tools are increasingly built on eBPF.
Observability is where eBPF first went mainstream: it lets you see almost anything the kernel sees — syscalls, function calls, network events, disk I/O — with very low overhead and, crucially, without changing the code you're observing. That combination broke a long-standing trade-off in tracing and profiling, and it's why modern observability tools are increasingly built on eBPF.