Archive
1046 posts · Page 5 of 88. ← Blog
A chain answers one call; a conversation needs to remember. LangChain handles memory by treating conversation history as data you manage and pass in — and, for anything beyond simple chat history, hands state management to LangGraph. Knowing which is which keeps your stateful applications clean instead of tangled.
A chain answers one call; a conversation needs to remember. LangChain handles memory by treating conversation history as data you manage and pass in — and, for richer state, hands state management to LangGraph.
Most agent code is tested by running it and eyeballing the output — because testing agents properly is genuinely hard. Pydantic AI's whole design has been quietly building toward making it easy: type safety, dependency injection, and test models combine so you can unit-test agent logic deterministically, offline, without ever calling a real LLM. This is arguably the framework's biggest practical advantage.
Most agent code is tested by running it and eyeballing the output, because testing agents properly is hard. Pydantic AI's design builds toward making it easy: type safety, dependency injection, and test models let you unit-test agent logic deterministically, offline, with no real LLM.
The individual controls — KYC, AML, screening, audit, privacy, reporting — aren't separate products; they're facets of one system that shares data, decisions, and evidence. Building a compliance platform means engineering them as a coherent whole, with the auditability, explainability, and testability that turn a pile of checks into a defensible program. This is where the series comes together.
The individual controls — KYC, AML, screening, audit, privacy, reporting — aren't separate products; they're facets of one system sharing data, decisions, and evidence. Building a compliance platform means engineering them as a coherent, auditable, testable whole.
All the theory pays off in a handful of habits that separate resilient backend code from code that falls over the first time the network misbehaves — which it will. Set timeouts on everything, reuse connections, retry idempotently, and know how to read the layers when something breaks. This closing post turns the stack into a working checklist.
All the theory pays off in a handful of habits that separate resilient backend code from code that falls over the first time the network misbehaves — which it will. Set timeouts on everything, reuse connections, retry idempotently, and debug by layer.
Knowing the pillars is not the same as having an observable system. In practice, observability is built incrementally, costs real money you have to manage, and only pays off if the whole team treats telemetry as part of building software — not something added after the outage. This closing post turns the concepts into a way of working.
Knowing the pillars is not the same as having an observable system. In practice, observability is built incrementally, costs real money you must manage, and only pays off if the whole team treats telemetry as part of building software — not something added after the outage.
Identity is the front door to everything, which makes it the most attacked part of most systems and the place where a single mistake compromises everyone. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and doing yourself what a library should do. This closing post is the practical security checklist.
Identity is the front door to everything, which makes it the most attacked part of most systems. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and rolling your own.
Training a good fine-tune is the easy half. Running it in production — deciding it's even worth it, serving adapters efficiently, keeping it from going stale as base models leap ahead, and re-tuning as your needs shift — is where fine-tuning becomes an ongoing commitment rather than a one-time project. This is the reality check that closes the series.
Training a good fine-tune is the easy half. Running it in production — deciding it's worth it, serving adapters efficiently, keeping it from going stale as base models leap ahead, and re-tuning — is where fine-tuning becomes an ongoing commitment.
The final decision isn't "which algorithm is best" — it's "which point on the recall-latency-memory triangle does my workload need, and what's the simplest thing that hits it." For a huge number of systems the honest answer is far less exotic than the vector-database marketing suggests, and knowing when you've genuinely outgrown Postgres is worth more than knowing HNSW's internals.
The final decision isn't 'which algorithm is best' — it's 'which point on the recall-latency-memory triangle does my workload need, and what's the simplest thing that hits it.' Often the honest answer is far less exotic than the vector-database marketing suggests.
The demo runs on your phone; now you have to get it running on thousands of phones you'll never touch. Shipping on-device AI has its own hard problems — a model file too big to bundle, first-run downloads, a fleet of wildly different devices, and updates you can't push instantly — and handling them is what separates a hackathon project from a product.
The demo runs on your phone; now you have to get it running on thousands of phones you'll never touch — a model file too big to bundle, first-run downloads, a fleet of different devices, and updates you can't push instantly.
There is no single "make it fast" for LLM serving — latency and throughput pull against each other, and both trade against cost. The job isn't to maximize one number; it's to hit your latency targets at the lowest cost per token, which means knowing exactly which knob moves which metric and in which direction.
There is no single 'make it fast' for LLM serving — latency and throughput pull against each other, and both trade against cost. The job is to hit your latency targets at the lowest cost per token, knowing which knob moves which metric.
SQL is a language where you say what you want, not how to get it — and the component that invents the "how" is the query planner, the closest thing a database has to a brain. When a query is mysteriously slow, the answer is almost always in the plan, which is why reading `EXPLAIN` is the single most valuable database skill you can learn.
SQL says what you want, not how to get it — and the component that invents the 'how' is the query planner, the closest thing a database has to a brain. Reading EXPLAIN is the single most valuable database skill you can learn.
In a distributed system, failure is not an exception to handle — it's the steady state. Nodes are always crashing, recovering, slowing down, and being partitioned somewhere in your cluster. Resilience is not preventing failure; it's designing so that the failures happening right now don't become the outage your users see.
In a distributed system, failure is not an exception to handle — it's the steady state. Resilience is designing so the failures happening right now don't become the outage your users see: detection, safe retries, isolation, and graceful degradation.