Archive
1290 posts · Page 9 of 108. ← Blog
Every idea in this series is worthless until someone builds the function that runs it. The most common failure in AI governance isn't picking the wrong framework — it's never getting past the framework to an operating capability, or building such a heavy one that the organization routes around it. This closing post is a practical path from zero: what to build first, how to make governance an enabler rather than a blocker, and how to grow the function as AI adoption grows. It turns the series into a plan.
Every idea in the series is worthless until someone runs it. A practical path from zero: start with visibility (inventory, then risk-tier, then a minimal owner-assigning policy), build controls highest-leverage-first in runnable layers, and make governance an enabler — the easy path — so it accelerates trustworthy AI rather than blocking it.
A coding agent is only as good as its understanding of the code it's changing, and real codebases are enormous — far larger than any context window. The agent can't read everything, so it must find and load the right code for the task: navigate the repository, search for what's relevant, and build enough understanding to make correct changes. This grounding problem — understanding a large codebase through a small window — is where many coding-agent successes and failures are decided.
A coding agent is only as good as its understanding of the code it's changing, and codebases dwarf the context window. How agents find and understand the right code — search, navigation, strategic reading, repo conventions, semantic retrieval — and why most coding-agent failures are comprehension failures, so grounding is decisive.
To understand why eBPF is such a big deal, you have to understand the wall it lets you cross: the boundary between user space and the kernel. That boundary exists for good reasons — safety and isolation — but it also meant that extending the kernel was historically a choice between two bad options. eBPF is the third option nobody had before.
To understand why eBPF is a big deal, you have to understand the wall it lets you cross: the boundary between user space and the kernel. That boundary exists for good reasons — safety and isolation — but it meant extending the kernel was a choice between two bad options: a dangerous kernel module or a limited user-space workaround. eBPF is the third option nobody had before.
The language model is where a voice agent stops being a transcription toy and becomes something you can actually talk to. But dropping an LLM into a real-time voice loop imposes constraints a chatbot never faces: it must respond in a tight latency budget, produce speech-friendly text, and carry conversation state — all while streaming its answer so the user isn't left waiting. This post is about the LLM stage, adapted for voice.
The language model is where a voice agent stops being a transcription toy and becomes something you can talk to. But dropping an LLM into a real-time voice loop imposes constraints a chatbot never faces: respond in a tight latency budget, produce speech-friendly text, and carry conversation state — all while streaming so the user isn't left waiting. The LLM stage, adapted for voice.
Model providers go down, rate-limit you, and time out — regularly. If your application calls one provider directly, its reliability is capped at that provider's. An AI gateway breaks that ceiling: because it can route across providers, a failure on one becomes a transparent retry on another. This post covers the reliability patterns that turn provider outages into non-events.
Model providers go down, rate-limit you, and time out — regularly. If your application calls one provider directly, its reliability is capped at that provider's. An AI gateway breaks that ceiling: because it can route across providers, a failure on one becomes a transparent retry on another. Retries, fallback, and circuit breakers — with an interactive request-flow sequence diagram.
A pipeline isn't a build-it-once artifact; it's a production system that needs operating. It degrades — tests get flaky, builds get slow, rollbacks get rusty — and if you can't measure your delivery, you can't improve it. This closing post is about keeping a pipeline healthy over time and using the DORA metrics to know whether your CI/CD is actually working.
A pipeline isn't a build-it-once artifact; it's a production system that needs operating. It degrades — tests get flaky, builds get slow, rollbacks get rusty — and if you can't measure your delivery, you can't improve it. This closing post covers keeping a pipeline healthy, fast recovery over rare failure, observability, and using the DORA metrics to know whether your CI/CD actually works.
Governance that stops at deployment governs the wrong moment. An AI system's real behavior — and its real risks — emerge in production, over time, as the world drifts and users do things no test anticipated. Post-deployment governance is the discipline of watching systems in the wild, catching when they go wrong, and maintaining a clear line of accountability for what they do. This post is about governance as an ongoing operational practice, not a launch checklist.
Governance that stops at deployment governs the wrong moment — risk emerges in production as the world drifts and users find the edges. Monitoring the governance-relevant signals (drift, continuous bias, safety) with thresholds tied to action, plus accountability for a system's whole life: durable owners, AI incident response, traceability, and redress.
Every coding agent, under the hood, runs the same loop: understand the situation, take an action, observe what happened, and decide the next action — repeating until the task is done. This read-edit-run-observe loop is the engine of a coding agent, and it works for code precisely because each action produces concrete, verifiable feedback. This post builds that loop and shows why closing it against real results is what separates an agent from a code generator.
Every coding agent runs the same loop: observe the state, decide an action, act through a tool, observe the result, repeat. Closing the loop against code's concrete feedback (errors as rich signals) is what makes it an agent that converges to working code, not a one-shot generator — and the loop is only as reliable as the feedback driving it.
eBPF lets you run your own sandboxed programs inside the Linux kernel, safely, without changing kernel source or loading a risky module — and that quietly unlocks a new generation of observability, networking, and security tools. It's one of the most consequential systems technologies of the last decade, and it's worth understanding from first principles. This series builds eBPF up from the problem it solves.
eBPF lets you run your own sandboxed programs inside the Linux kernel, safely, without changing kernel source or loading a risky module — quietly unlocking a new generation of observability, networking, and security tools. It's one of the most consequential systems technologies of the last decade. This series builds eBPF up from the problem it solves.
The first real stage of a voice agent is turning sound into words, and it's harder than it looks. Modern ASR is astonishingly good on clean audio, but real conversations are full of noise, accents, and disfluencies, and — for a voice agent — the transcript has to arrive fast and incrementally, while the model also figures out when the user has actually stopped talking. This post covers ASR for real-time voice.
The first real stage of a voice agent is turning sound into words, and it's harder than it looks. Modern ASR is astonishingly good on clean audio, but real conversations are full of noise, accents, and disfluencies — and the transcript has to arrive fast and incrementally while the model figures out when the user has actually stopped talking. ASR for real-time voice.
Once every model call flows through one place, that place can make an intelligent decision on every request: which model should serve this, and through which of your capacity? Routing picks the right model for the task; load balancing spreads traffic across providers and keys so no single limit or outage bottlenecks you. Together they turn the gateway from a passthrough into a control plane.
Once every model call flows through one place, that place can make an intelligent decision on every request: which model should serve this, and through which of your capacity? Routing picks the right model for the task; load balancing spreads traffic across providers and keys so no single limit or outage bottlenecks you. Together they turn the gateway into a control plane.
Put the pieces together and a modern frontier language model comes into focus: a deep transformer whose feed-forward blocks are Mixtures of Experts, whose attention is made efficient with grouped-query and FlashAttention, and which is engineered end to end around one goal — maximum capability per unit of compute and memory. This closing post assembles the anatomy and looks at where architecture is heading.
Put the pieces together and a modern frontier LLM comes into focus: a deep transformer whose feed-forward blocks are Mixtures of Experts, whose attention is made efficient with grouped-query and FlashAttention, engineered end to end around one goal — maximum capability per unit of compute and memory. This closing post assembles the anatomy and looks at where architecture is heading.