1046 posts · Page 32 of 88. ← Blog
Organizations rarely fail at building an AI demo; they fail at the gap between a working prototype and a governed, reliable, cost-controlled system — and that gap has a shape you can map.
Organizations rarely fail at building an AI demo; they fail at the gap to a governed, reliable, cost-controlled system. This roadmap maps that gap as twelve phases and a maturity ladder.
The single highest-leverage setup step for Claude Code is a good CLAUDE.md — the file where you write down, once, the context and conventions you'd otherwise repeat every session.
The highest-leverage setup step: a good CLAUDE.md that gives durable project context (build/test commands, conventions, gotchas, what not to do), how it layers, and the settings/permissions that tune autonomy safely and shareably.
An FDE's superpower is turning a vague problem into something the customer can see and touch within days — because a rough working demo teaches more than a month of meetings.
Turn a vague problem into something the customer can touch in days: build the thinnest slice that tests the riskiest assumption, run a tight demo loop, and manage the prototype's lifespan so 'it demoed' doesn't get shipped as 'it's done'.
A defender's field guide to the injection and jailbreak techniques a red-teamer probes for — the taxonomy, why each one works, and how to turn it into a re-runnable test suite that maps every passed test to a concrete fix.
A deeper, test-focused look at injection and jailbreak families — direct vs indirect (the RAG/agent threat), role-play, obfuscation, many-shot, multi-turn, cross-lingual — plus a red-team methodology: build a probe suite, mutate, test input and retrieval paths, measure, re-test.
Why the non-functional requirements — performance, scalability, availability, security, maintainability and their kin — are what your architecture is actually optimized for, how to make them measurable, and why they always trade off against one another.
The non-functional requirements that actually drive architecture: the -ilities (performance, scalability, availability, security, maintainability…), making them measurable as scenarios with numbers, and prioritizing the top few because they all trade off.
How to write code-review comments that improve the code and the relationship at the same time — commenting on the code not the coder, labeling severity so the author knows what blocks, asking instead of decreeing, teaching the why, and knowing when a thread belongs on a call.
Writing review comments that improve the code and the relationship: comment on the code not the coder, be specific and actionable, label severity (nit/suggestion/blocking), ask questions when you lack context, and pick your battles.
How the four families of automated security tests — static analysis, dynamic analysis, secret scanning, and instrumented runtime testing — fit together across a pipeline, and why tuning signal-to-noise matters more than adding scanners.
Automated security testing in the pipeline: SAST vs DAST vs IAST and their trade-offs, secret scanning (including git history), where each runs, and making findings actionable so false-positive fatigue doesn't get the scanner muted.
Why the biggest class of API bugs is not about who you are but about what you are allowed to touch — and how to check ownership, function access, and property access on every single request.
The dominant class of API bugs: broken object level authorization (BOLA/IDOR — the #1 API risk), broken function level authorization, and object property level (mass assignment / excessive data exposure) — with allow-listed DTOs, ownership checks, and deny-by-default.
Shaping the payloads clients actually consume — consistent bodies, content negotiation, field selection, and pagination that survives scale and mutation.
Shaping the payloads clients consume: consistent naming, dates and money done right, content negotiation, field selection, and pagination — why offset pagination breaks at scale and how cursor/keyset pagination fixes it.
The highest-leverage tool for latency and scale — and the source of its hardest problem, invalidation. Where caches live, the patterns for filling them, how they evict, and why keeping them correct is the part that stays hard.
Caching as the highest-leverage latency tool — and its hardest problem: where caches live, the patterns (cache-aside/read-through/write-through/write-behind), eviction, and invalidation including cache stampede, penetration, and hot keys.
Governance is only as real as your ability to measure it. This is the MEASURE function of an AI risk program made concrete — a versioned eval set, the metric families that matter for an LLM system, and a CI gate that fails the build when quality regresses instead of just logging a warning.
Governance enforced through evaluation — the Measure function made real: build a versioned eval set, pick the metric families (quality, faithfulness, safety, bias, PII, cost/latency), and turn eval into a CI quality gate that fails the build on regression.
Part three of the AI Security Engineering series: protecting the data that flows through an LLM system — how sensitive information leaks out of prompts, logs, and retrieval, and the engineering controls (redaction, data minimization, per-user retrieval authz, residency choices) that actually stop it.
Protecting data in LLM systems: sensitive-information disclosure, PII in prompts and logs (your observability can be the leak), redaction with Presidio, data residency, and per-user access control on the retrieval layer so RAG doesn't leak across tenants.