1046 posts · Page 29 of 88. ← Blog
Subagents let Claude Code delegate a focused task to a separate agent with its own context — keeping the main conversation clean and letting independent work run in parallel.
Subagents delegate a focused task to a separate agent with its own context — for context isolation and parallelism. When to delegate (independent, context-heavy, specialized), defined agent types, and keeping the main session as accountable orchestrator.
An FDE's code only matters if the customer trusts them enough to adopt it — the relationship is not soft-skills garnish, it's the delivery mechanism.
An FDE's code only lands if the customer trusts them: earning trust in small kept promises, speaking the customer's outcomes and vocabulary, managing expectations relentlessly, navigating the org (champion/skeptic), and delivering bad news well.
Why agents and retrieval turn a prompt injection into real-world action, how to red-team the highest-risk AI surface with benign canaries, and the least-privilege controls that shrink an attacker's blast radius.
The highest-risk modern surface: indirect injection via RAG/tools, tool abuse and excessive-agency exploitation, memory poisoning, multi-step attacks, and data-exfiltration channels — with a canary methodology and least privilege as the primary control.
The recurring structural patterns an architect actually reaches for — layered, hexagonal, DDD boundaries, CQRS, event sourcing, saga, strangler fig, and BFF — each with the problem it solves, the cost it charges, and the honest signal that you need it.
The recurring structural patterns and their costs: layered, hexagonal/ports-and-adapters and clean, DDD bounded contexts, CQRS and event sourcing (frequently over-applied), saga, and the strangler fig — apply the simplest that solves the real problem.
Half of review quality is decided before the reviewer ever opens the diff — by the author. Small focused PRs, a description that states what and why, a self-review pass, and clean commits are how you optimize the one resource a review really spends: the reviewer's attention.
Half of review quality is set before the reviewer arrives: small focused PRs, splitting big changes, great descriptions (what/why/how-to-test), self-review first, and keeping refactor noise out of behavior changes.
How to move from hardcoded passwords toward dynamic, short-lived, audited credentials — the hierarchy from bad to good, the role of a real secrets manager, and why a leaked secret is compromised the instant you push it.
Keeping credentials out of code and under control: the bad-to-good hierarchy, secrets managers (Vault/KMS), dynamic short-lived secrets, rotation that consumers actually pick up, and workload identity / OIDC so CI and services never store a long-lived key.
Part five of the API Security series: why limits are a security control and not just an ops knob, how the four rate-limiting algorithms trade off, which dimensions to key on, and how to protect expensive queries and sensitive business flows from bulk abuse.
Rate limiting as a security control (OWASP API4/API6): the algorithms and their trade-offs, keying on authenticated identity not just IP, 429 + Retry-After, protecting expensive operations, and defending sensitive business flows from bulk abuse.
The real skill isn't cutting a v2 — it's knowing which changes are safe to ship silently, which ones break clients you'll never meet, and how to retire an old version responsibly instead of forever.
Changing an API without breaking consumers: what counts as breaking, versioning strategies and their trade-offs (URI vs header vs additive evolution), the robustness principle and its limits, and responsible deprecation with Sunset headers and usage telemetry.
The theory that governs distributed data, made practical — CAP stated correctly, PACELC, the full consistency spectrum with "what the user sees" examples, quorums, and Raft-style consensus without the proofs.
The theory that governs distributed data, stated correctly: CAP as a partition-time choice (not pick-2-of-3), PACELC, the consistency spectrum with what-the-user-sees examples, quorums, and consensus/Raft at an intuition level.
Governance doesn't stop at deploy. This is the NIST RMF MANAGE function in practice: what to monitor for an LLM system, how to detect the drift — including the silent kind where a provider swaps the model under you — and why the audit trail you log is the regulatory deliverable, not a debugging convenience.
Governance doesn't stop at deploy — the Manage function in production: what to monitor (operational, quality, safety), detecting drift including silent provider-model drift behind moving aliases, and the audit trail (versions + retrieved context, PII-redacted) that becomes regulatory evidence.
Part five of the AI Security Engineering series: the two OWASP LLM risks that live in the plumbing around the model — the documents your agent retrieves and the models, datasets, and dependencies it is built from — and the Python patterns that treat both as untrusted until proven otherwise.
Securing the components around the model: RAG as an injection and poisoning vector (treat retrieved content as hostile, enforce provenance and per-user authz) and supply-chain risk (safetensors over pickle, model provenance, pinned and vetted dependencies and tools).
Adding safety to a watsonx app in Python with two complementary layers — the built-in HAP and PII moderations that watsonx.ai applies to generation, and IBM's dedicated Granite Guardian risk-detection models run as classifiers around your main model to catch harm, jailbreaks, and RAG hallucination before a response reaches a user.
Add safety to a watsonx app in Python with two layers: built-in HAP/PII moderations on generation, and Granite Guardian — IBM's dedicated risk models — run as a classifier to screen input and check RAG groundedness, wrapped in a guarded-generate flow.