Thursday, August 13, 2026

Claude Certified Developer – Foundations

Claude Certified Developer

The course arc: M1 gives the vocabulary → M2 builds the production API skills → M3 moves them into Claude Code/MCP → M4 proves the system holds under production traffic → M5 turns the working build into a reusable, deployable, defensible asset.

Module 1 — MSO Foundations

Model fundamentals and technical foundations everything else assumes. 6 sections, 2 checkpoints.

1.1 How LLMs behave: tokens, context, sampling, non-determinism

Tokens are the unit of input, output, and cost. Claude reads tokens, not characters or words; the chars-per-token ratio is tokenizer- and model-generation-dependent, so treat any rule of thumb as model-dependent and confirm at build time. Everything is counted in tokens: prompt, conversation history, tool definitions, tool results, and the generated response. Budget and price in tokens, not words.

The context window is a fixed token budget that must hold the entire request at once: system prompt, history, tool calls/results, and the response being generated.

An input that is already oversized is rejected with an error before generation begins.
A request that fits on input but hits the ceiling mid-generation returns truncated output with a model_context_window_exceeded stop reason (current models stop and return what they generated, not an error).
Managing history (trim or summarize before each call) is the application's job. Development rarely fills the window (short test inputs); production fills it fast (longer inputs, more turns).

Sampling: the model doesn't pick one fixed next token; it produces a probability distribution at each step and samples from it. Temperature shapes the distribution — lower concentrates probability on likely tokens (more repeatable), higher spreads it (more varied). Confirm current parameter support in the API reference at build time.

Non-determinism is the primary consequence: identical inputs do not guarantee identical outputs. Never assert on exact response text in tests — assert on the property that must hold (required field present, value in range, structure parses). When judging meaning rather than structure, use an eval with a model-graded judge.

1.2 Models & reasoning modes

The Claude family spans capability tiers (Opus / Sonnet / Haiku classes): capability vs cost vs latency trade-offs.
Model choice and reasoning mode are separate, composable levers. Model choice picks which family member runs; extended thinking is a per-request setting any supporting model can run with on or off.
Reasoning earns its cost on hard multi-step problems; it is wasted on lookups and classification.
Per-model thinking defaults differ (some newer models think adaptively by default or always) — confirm current defaults at build time.
A capable model with reasoning off is fast and direct; a smaller model with reasoning on spends more tokens to think; the hardest tasks pair a capable model with a higher effort setting.

1.3 Prompting modes: zero-shot, one-shot, multi-shot

Zero-shot: instruction, no examples. One-shot: one input→output example. Multi-shot (few-shot): several examples. Examples are not training data — they sit in the prompt and show the exact output shape a description often fails to pin down.
Every example costs tokens on every call — quality vs cost trade-off. Use zero-shot for simple tasks with obvious output shape; add examples when structure/casing/edge cases keep being missed. One or two correct examples usually fix a formatting problem faster than another paragraph of instructions.
Discipline: add the smallest amount of prompt that produces a reliable result.
Mode interacts with model choice: a more capable model often succeeds zero-shot where a smaller model needs examples — so adding examples can let a cheaper model do the job. Try the simplest model + fewest examples that pass your eval.

1.4 Technical substrate: SDK vs REST, sync/streaming, async

Claude is reached over an HTTP REST API (endpoint + API key + JSON). Official SDKs (Python, TypeScript, …) are thin convenience layers over the same API — they handle auth, request construction, retries, and parsing. Same API, same model either way.
Synchronous: send request, wait for the complete response.
Streaming: response arrives in pieces as generated — better perceived latency for user-facing work (M2 covers the handling rules).
Async concurrency: Python SDK AsyncAnthropic (non-blocking async/await); TypeScript client is Promise-based (no separate async class). Requests still return in real time, but the app isn't blocked. Right pattern for concurrency without blocking.
Message Batches API: bulk offline pattern — submit a large set of requests in one call, get an identifier, poll for completion. Up to 24 h to complete, lower per-token cost in exchange for latency. Right for offline pipelines, eval runs, bulk jobs where nobody waits per result.

1.5 Module 1 five takeaways

Tokens are the unit of input, output, and cost — think and budget in tokens.
The context window is a fixed budget holding the whole request; oversized input errors before generation, mid-generation overflow truncates with model_context_window_exceeded; history management is the app's job.
Sampling makes generation non-deterministic — exact-text tests are unreliable; this is what evals are for.
Model choice and reasoning mode are separate, composable levers — pick the smallest model/simplest settings that meet your eval.
Claude is reached over REST, usually via an SDK; pick sync/streaming/async/batches by workload shape.

Checkpoint drills (M1 quiz)

Question	Answer	Why
Same prompt twice → same response?	No — the model samples each next token from a probability distribution; wording varies even when both answers are correct.	Non-determinism from sampling.
Separate model choice from reasoning mode	Model choice picks the family member; extended thinking is a per-call setting any supporting model can toggle.	Independent, composable levers.
Zero-shot classification already correct — what does adding 3 examples do?	Adds token cost on every call for little or no gain.	Examples only pay when output shape is being missed.
Thousands of inputs offline at lowest cost	Message Batches API (submit batch, poll; ≤24 h; lower per-token cost).	No user waiting per result.
Long multi-turn session keeps filling the window — symptoms?	Fixed token budget fills as history/tool results accumulate; oversized input → error before generation; mid-generation ceiling → truncated output + `model_context_window_exceeded`. App must trim/summarize.	"Ran fine in testing, fails when inputs grow."

Module 2 — Production-Grade Prompting, Agents & Tool-use

Production prompts, extended thinking, tool-use loops, streaming, context & memory, agent construction, multimodal & batch. 29 screens, 10 checkpoints.

2.1 Prompting craft

Techniques: system prompts (role + durable behavior), XML tags (delimit untrusted/structured input, e.g. <ticket>…</ticket>), few-shot examples (pin output shape), output constraints (exact format specification).

Failure type → missing technique: wrong output shape → missing output constraint; drift across turns → underspecified system prompt; hallucinated structure → missing few-shot examples. Diagnose by failure type instead of rewording and retrying.

Checkpoint 1 — fix the broken prompt. A support-ticket extractor's system prompt said only "Extract the key information." Defect: no output format specification. Fix: demand only a JSON object with exactly the three fields — category (enum, e.g. billing / technical / escalation), urgency (low / medium / high / critical), summary (one sentence) — and "Return only the JSON object. No other text."

2.2 Extended thinking

Turn it on and the model writes out step-by-step reasoning (a thinking block) before the answer block. On newest models the thinking content is omitted by default; request a readable summary via the display setting.
Reasoning is adaptive on current models: enable with the thinking parameter; tune depth with effort, not a fixed token budget. The older budget_tokens control is deprecated (400 error on newest generations).
Thinking tokens are billed as output tokens — don't reach for it by default.
When to enable: multi-step reasoning holding several constraints (derivations, multi-hop logic, dependent action planning); agentic loops that plan across tool calls (budget for the planning step).
When to leave off: mechanical/lookup tasks — classification, format conversion, extraction, short factual answers.
Carry-back rule (structural, non-negotiable): in tool-use conversations, every thinking block must be returned to the API unchanged on the next turn. Each block carries a signature; edit/summarize/drop it and the API rejects the request. Redacted thinking blocks (encrypted) follow the same rule. If context growth is the worry, the fix is context engineering — never stripping thinking blocks.

Checkpoint 2 — when does thinking earn its cost? Classify 50,000 tickets overnight → leave it off (a one-word label needs no reasoning; cost multiplies across calls). Plan a multi-step dependent refactor → enable it, budget for the planning step (without it the model commits before working through dependencies). Strip the thinking block from history to save context → never do this (breaks the signature/carry-back rule).

2.3 Tool-use & schema design

Claude never runs tools. It reads your tool definitions, decides which fits, and tells your application what to call with what inputs. Your app executes, returns the result, and Claude continues. The Claude-owns / your-code-owns boundary is where most tool-use bugs live.
Loop: define schema → send message → tool_use block → you execute → return result → Claude continues. If tool selection misses systematically, the fix is in the schema definition.
Four block types: text, tool_use (assistant), tool_result (sent in the user role — role marks the sender, not the author), thinking blocks.
Pairing invariant: every tool_use must have a matching tool_result in the immediately following user turn, matched by id, not position, with the id preserved exactly.
Descriptions drive selection. A schema can be structurally valid and still fail: overlapping descriptions make Claude mis-route near the boundary between two tools. Write intent + preconditions + exclusions ("use for X; requires Y; never use for Z").

Checkpoint 3 — spot the schema bug. Trace: assistant issues tool_use id toolu_01; the tool_result references toolu_02; API errors "tool_result block references unknown tool_use_id." Fix: correct the tool_use_id to match the id issued in the assistant turn — not description tweaks, not schema required changes.

2.4 Streaming responses

Streaming sends the response in pieces (content_block_start / content_block_delta / message_stop events); your code assembles final content and must handle interruption.
Commit only complete turns: a dropped stream can leave a half-built tool_use block; if you append it to history, the next request fails validation — the error points away from the cause.

Checkpoint 4 — repair the handler. Broken handler tracked stop_seen but appended the assembled turn unconditionally. Fix: gate the append on message_stop having arrived (if stop_seen: append; else: discard partials and retry from the last complete turn).

2.5 Context engineering

The window holds system prompt + history + every accumulated tool call/result. Tool outputs consume context like everything else.
Accumulated large tool results crowd out current instructions → degraded tool selection late in a session ("ran fine in dev, hit a ceiling in production").

Checkpoint 5 — diagnose the context failure. Turns 1–4 correct (4 × 2,400-token tool results piling up), turn 5 picks the wrong tool, session dies. Trigger is turn 5 accumulated context, not the schema (turns 1–4 correct rules that out), not max_tokens. Fix: prune large tool results after each turn / apply compaction before the failure point.

2.6 Agent construction

An agent = a multi-step tool-use loop with managed context and a defined goal, plus HITL (human-in-the-loop) checkpoints where the worst case is expensive.
Loop mechanics: on stop_reason == "tool_use", append the assistant turn, execute each tool_use block, append tool_results, continue; on end_turn, return.
Place a human gate before executing actions that are hard to undo or that reach systems beyond the file/task (production configs, writes to shared systems). Testing rarely surfaces the need — production does.

Checkpoint 6 — complete the wiring. (1) update_record description must state intent + write semantics + exclusions: "modifies a single field on an existing customer record; requires customer_id, field, new_value; WRITES data — only on explicit user request; never for reads (use read_record)." (2) HITL code: if block.name == "update_record": show the proposed change, ask for approval, and on rejection append a tool_result for that tool_use_id saying it was rejected and skip execution.

2.7 Agent memory

In-context memory: all state in the active conversation — right for single sessions that end and don't resume.
External storage: write state to a DB at session end, read it back at session start — right when the same user/agent continues across sessions/days.
Stateless: each session starts fresh — right for fully independent jobs.
Failure story: concatenating all prior session transcripts in-context works in dev (one long session) and fills the window by session four in production.

Checkpoint 7 — choose the scope. Support agent with daily check-ins over two weeks → external storage. Document formatter, independent jobs → stateless. Multi-hour single-session coding assistant → in-context (external storage is unnecessary overhead; summarizing compresses out detail still needed within the session).

2.8 Multimodal & batch ingestion

Every image/PDF consumes context budget before Claude reads a character of your prompt.
Inline base64: one-off image in a single request.
Files API: upload once, reference file_id per request — right for assets reused across many requests.
Message Batches API: one batch call + poll — right for high-volume jobs; looping over the synchronous API is "serialization with extra steps" and runs into rate limits/connection management.

Checkpoint 8 — pick the encoding. Reference diagram used in every request → Files API. One-off bug screenshot → inline base64. 5,000-item classification job → Batches API.

2.9 Cumulative debug task (4 planted bugs, one per layer)

Schema layer: description "Gets data." — too vague to route on → wrong/missed selections. Fix: intent + exclusion description.
Streaming layer: turn committed without checking message_stop and thinking blocks stripped during assembly → partial tool_use in history; stripped thinking breaks the carry-back signature. Fix: keep ALL blocks including thinking; gate commit on stop_seen; raise on interruption.
Context layer: the API sees a tool_result referencing a tool_use it never received as a complete assistant turn → request rejected. (Resolved once the streaming fix lands the full assistant turn before the tool_result.)
Memory layer: concatenating all prior transcripts in-context → window fills by session ~4–5. Fix: external storage + bounded summary.

2.10 Module 2 takeaways (8)

Failure type tells you which prompting technique is missing.
Extended thinking: enable for hard reasoning/planning; off for mechanical tasks; thinking blocks return unchanged in tool loops.
Tool selection is driven by schema descriptions — write intent, preconditions, exclusions.
tool_use/tool_result pair by id in adjacent turns, exactly.
Streaming: assemble from events; commit only complete turns.
Context is a budget: prune/compact accumulated tool results before they crowd instructions.
Agents need HITL gates where the worst case is expensive.
Memory scope: in-context / external / stateless — match to session lifecycle. Files API vs base64 vs Batches — match to reuse and volume.

Module 3 — Claude Code, MCP & Integration

Permission modes & human gates, durable project context, packaging workflows as plugins, MCP servers, enterprise integration. 22 screens, 8 checkpoints.

3.1 Permission modes & human gates

Claude Code runs the same agent loop from M2 in your terminal, adding a permission system that gates every action.
Permission mode is a risk decision, not a speed decision. Modes range from prompt-before-everything (default) through acceptEdits to bypassPermissions (prompt-for-nothing). Bypass removes the one prompt that matters exactly when a destructive action appears "routine."
settings.json permissions block: defaultMode, allow rules, deny rules (e.g. "deny": ["Bash(rm:*)", "Bash(git push:*)", "Read(.env.production)"]). Deny rules are deterministic — preferable to relying on a classifier's judgment for shell-gating.
Even with edits auto-approved, place a human gate before any single action that is hard to undo and reaches beyond the file (e.g. a deployment config several production services read). Review-before-write, not review-in-the-next-PR.

Checkpoint 1. Trusted local refactor: pick the piece denying destructive shell (rm, git push) + the piece denying Read(.env.production); reject bypassPermissions and allow: ["Bash(*)"]. Human gate: a human approves the deployment-config change before the write executes.

3.2 Durable project context: CLAUDE.md, rules, hooks, subagents

CLAUDE.md = always-on project memory; rules files = scoped guidance; hooks = deterministic guardrails on lifecycle events; subagents = isolated contexts for subtasks.
Watch out: an 800-line CLAUDE.md stops landing — every rule felt individually reasonable, but rules compete for attention. Keep it lean; move enforcement into hooks.
Hooks: PreToolUse runs before a tool call executes — the only point where blocking is possible (PostToolUse is too late). A command hook reads the tool call from stdin, checks it, and exits code 2 to block, with stderr becoming the message Claude sees.

Checkpoint 2. Path-restriction hook: lifecycle event = PreToolUse (matcher Read); command = the script that checks the path and exits 2 for .env.production (not the audit-logger that exits 0, not the unconditional warner).

3.3 Packaging workflows: skills, plugins, marketplaces

Plugins bundle skills, commands, hooks, subagents, and MCP servers into one installable unit. Install ≠ execution: installing copies files; running them on another machine is the real test.
Portability defect #1: absolute paths. /Users/alex/... exists only on the author's machine. Reference scripts from the project root via CLAUDE_PROJECT_DIR so the path resolves on every clone (not a network drive, not ~ shortcuts).
Where a skill loads (4 runtimes):
1. Claude Code terminal → SKILL.md in .claude/skills/ with a description matching the request.
2. Messages API call → send the code-execution + skills beta headers; skill steps must not depend on local files/tools.
3. Headless Agent SDK job → set settingSources explicitly so filesystem skills load (don't rely on defaults; confirm against the SDK reference).
4. Anthropic-hosted long-running agent (agent ID across sessions) → define the agent as an API resource listing the skill + managed-agents-2026-04-01 beta header; runs in Anthropic's sandbox, so no local-file dependencies.

Checkpoints 3–4. Skill-runtime matching as above; plugin defect = the absolute path in step 1, fix = $CLAUDE_PROJECT_DIR-relative reference.

3.4 MCP servers: transport & scope

An MCP server exposes tools/resources to Claude. Choose transport (stdio = local process; HTTP = network service) and scope (Local = just you; Project = .mcp.json checked into the repo, shared with the team; Enterprise = managed settings pushed by IT).
Matches: local-only dev tool (SQLite) → stdio + Local; company-hosted service for the whole team → HTTP + Project; experimental one-repo, not-ready-to-share → Local (stdio or HTTP); org-wide mandated deployment → HTTP + Enterprise (managed settings).
Credential rule: never hardcode an API key in a config file — a key committed to a repo enters history where it cannot be removed by a later commit and must be treated as compromised. Reference an environment variable in the config; rotate the exposed key first.

Checkpoints 5–6. Transport/scope matching as above. Auth-failure trace (401 with credential read from a file on a CI runner): fix = rotate the rejected key, move the credential into a CI environment variable, reference the variable in the MCP config — not just replacing the file's value, not switching auth schemes to dodge the hygiene problem.

3.5 Enterprise integration

API keys suit server-to-server calls under your control; OAuth suits user-delegated access to enterprise systems.
OAuth redirect URIs are registered per host and often governed per environment — staging success proves nothing about production. Register/verify prod redirect URIs before cutover.

3.6 Cumulative integration task (3 bugs, one per layer)

Config layer: defaultMode: "bypassPermissions" on a production workstation — removes every confirmation prompt including destructive ops (the .env.production deny was correct; only the mode is wrong). Fix: acceptEdits.
Packaging layer: SKILL.md step calls /Users/priya/... — author-machine-only. Fix: $CLAUDE_PROJECT_DIR/scripts/validate-migration.sh.
MCP/auth layer: "Authorization": "Bearer sk-prod-..." inline in .mcp.json — committed credential, unremovable from history, treat as compromised. Fix: rotate + Bearer ${WAREHOUSE_MCP_TOKEN} env reference.

3.7 Module 3 takeaways (7)

Permission mode matches risk, not convenience.
Deny rules + PreToolUse hooks give deterministic enforcement; CLAUDE.md is guidance, hooks are guarantees.
Keep CLAUDE.md lean or rules stop landing.
Package with relative/CLAUDE_PROJECT_DIR paths; install ≠ runs-everywhere.
Skills load differently per runtime (filesystem, beta headers, settingSources, managed agents) — configure for where it runs.
MCP transport & scope follow who needs it and where it lives.
Credentials live in env vars/managed identity, never in committed config; leaked = rotate.

Module 4 — Production Engineering, Evals & Security

Evals & judges, testing & tracing, failure handling, model selection, cost & orchestration, security. 23 screens, 8 checkpoints.

4.1 Evals & LLM-as-judge

"I tried it a few times and it looked right" is not done. An eval turns "done" into a score on a fixed dataset. Manual demo runs use inputs shaped like the ones you imagined — the edge case that breaks you isn't among them.
Dataset: input cases + expected_behavior specific enough to grade against (e.g. "a summary listing all three action items with their owners"; "summary of the bug and repro steps that omits the unrelated aside").
Judge prompt: grades output vs expected behavior, returns structured JSON (misses / reasoning / score). Calibrated score bands: 1–3 = misses required content; 4–7 = partial; 8–10 = complete and faithful.
Grading method matches output type: exact match when there's one correct form; code checks for structure; model-graded judge for meaning.

4.2 Testing & tracing

Unit tests passing + functional tests passing ≠ system works: seams break. A trace that shows retrieve() ok → build_prompt() silently dropping .content → model answering off-topic is an integration failure at the handoff.
Fix the seam and add an integration test on the handoff (retrieve → build_prompt), not the parser, not prompt wording.
Tracing per step is what localizes the break an end-to-end failure only signals.

4.3 Failure handling

Development traffic is low-volume and stable; production adds rate limits, timeouts, transient 5xx, and overload — write the error path before it's needed.
Retry rules: exponential backoff with jitter, capped (min(cap, 2**attempt) + random.uniform(0,1)); honor retry-after on 429; fail fast on terminal statuses (400s) — retrying them can never succeed; raise RetryBudgetExhausted when attempts run out. time.sleep(0) retries deepen a rate limit — each instant retry is another counted request.
Never dereference a possibly-None response after a retry loop.

4.4 Model selection in production

Choice is driven by the deciding constraint, verified by eval:
- High-volume classification, eval shows Haiku holds the bar → Haiku; cost-at-volume.
- Dependent multi-step refactor where a wrong early step is expensive, Sonnet misses hardest cases → Opus; quality on hard reasoning where wrong answers are costly.
- Mixed traffic → route: Sonnet/Haiku default with Opus override on complex requests.

4.5 Cost & orchestration

Parallel fan-out cuts latency a little and multiplies cost a lot (every subagent bills its own context) — split only when parts are truly independent and the trade is worth it.
Levers matched to task shape:
- Single-fact lookup on a stable corpus → small model, fetch-once retrieval (model choice lever).
- Broad research splitting into independent parts → orchestrator-worker (large lead, small workers; parallel-split lever).
- User-facing instant feel → streaming.
- Cost-sensitive non-urgent bulk → Batches API (~50% cost reduction) + prompt caching.

4.6 Security

Untrusted content (fetched pages) can carry instructions — prompt injection. Trusting your users ≠ trusting the content their requests pull in.
Minimal secure config for a fetch-and-write agent — all four controls, each enforcing one thing:
1. PreToolUse hook — denies writes outside the permitted path before execution (guardrail, not convention).
2. Deny rules — /etc, /secrets, ~/.aws unreachable; limits blast radius if the agent is steered.
3. Env-var secret reference — credential never in committed config.
4. Audit log — records every privileged action + result; the evidence trail a regulated review requires.

4.7 Cumulative production-hardening task (3 defects)

Eval/test layer: no eval exists — success was judged by manual demo runs; nothing fails when the prompt/model changes. Fix: graded holdout dataset + judge, gate promotion on it.
Error-handling/cost layer: except Exception + time.sleep(0) — instant retries deepen rate limits; terminal statuses retried. Fix: backoff + jitter, honor retry-after, fail fast on terminal, call_with_retry helper.
Security/guardrail layer: write_file(page.suggested_path, …) — untrusted fetched content chooses the write destination. Fix: fixed write path + PreToolUse hook enforcing the boundary.

4.8 Module 4 takeaways

Set the standard before you build: eval + calibrated judge define "done."
Test the seams — unit green + e2e red means an integration handoff broke; tracing localizes it.
Failure handling: backoff + jitter, retry-after, terminal-status detection, explicit exhaustion.
Model selection: the eval + the deciding constraint (cost-at-volume / quality-on-hard / route mixed traffic).
Cost levers: batching + caching for bulk, streaming for UX, fan-out only when independence justifies the bill.
Security: treat fetched content as data, gate writes pre-execution, deny sensitive paths, env-var secrets, audit everything.

Module 5 — Accelerators & IP Contribution

Packaging for reuse, contributing back, requirements & lifecycle, deployment & versioning, comparing platforms, trust boundaries. 25 screens, 9 checkpoints.

5.1 Packaging a reusable accelerator

An accelerator keeps the reusable logic, exposes customer-specific values as documented parameters, and bundles the eval + audit log alongside the asset.
Hardcoding ships faster and reuses never: repo_path="/home/acme/checkout-service" inside a "reusable" template forces the next team to edit code instead of configuring it.

Checkpoint 1. Defect = hardcoded repo_path. Fix: def build_review_agent(repo_path): … repo_path=repo_path (set per engagement). "The difference between a template that runs and a template that reuses."

5.2 Contributing back to the ecosystem

Channel matches the asset: focused tool wrapping one API → the tool's own repository; full application → the Cookbook, but only after the reusable pattern is stripped out as a focused example (a whole app doesn't fit a review built for one pattern); one-line fix to an existing Cookbook example → that example's own repository.
Readiness item per case: bare function → a test that proves the wrapper behaves; whole application → reduction to a single focused pattern; engagement-derived code → the rights check (licensing constraints block the merge before any technical review).

5.3 Requirements & lifecycle

Business → functional → infrastructure requirements. Functional = what the system does ("the agent produces a summary a human approves before it is stored"). Infrastructure = where/how it runs ("transcript data is processed in the EU"). "Fast and accurate" is neither — untestable.
Lifecycle phases: requirements → design → test → deploy → operate.
- Residency rule ("data must be processed in region X") → requirements.
- Choosing the platform that satisfies it (e.g. Bedrock for a customer's AWS compliance posture) → design.
- Writing the eval suite and rubric → test; gating promotion on the eval result → deploy.
- Pinning the full model ID + retaining the prior version → deploy.
- Instrumenting token cost and latency per call in production → operate.

5.4 Deployment & versioning

Platforms: first-party Anthropic API, Amazon Bedrock, Google Vertex AI. Choose on the customer's cloud, compliance posture, and residency — not team familiarity.
Pin the full model ID; never ship a moving alias. An alias that silently moves changes production behavior with no code change. Retain the prior pinned version so rollback is possible.
AWS + residency + rollback scenario → Bedrock + AWS identity (role ARN, not an Anthropic API key) + pinned full model ID + retained prior version.
Latency must be measured from the customer's region, not your dev laptop; a platform picked on familiarity can fail an EU-only residency check outright.

5.5 Multi-component apps & trust boundaries

Connecting individually-tested components multiplies seams; every seam where content crosses from one trust level to another is a boundary that needs marking.
Two blanks that hold under review: wrap untrusted fetched content so the next component treats it as data (treat_as_data(fetched) — closes the injection seam); scope the most privileged component (MCP server → customer DB) to least privilege (read-only) so a steered action can't reach beyond its task. Distractors: run_as_instructions, full_access.

5.6 Cumulative task (3 defects)

Packaging: hardcoded repo_path → parameterize.
Deployment/versioning: model="opus" moving alias, no retained prior version → pin full model ID + retain for rollback.
Boundary: next_call(input=fetched) passes untrusted content as trusted instructions → wrap as data; keep privileged components least-privilege.

5.7 Module 5 takeaways

Package while the build is fresh: parameters for customer-specifics, eval + audit log bundled.
Contribute the focused pattern through the channel built for it; clear rights before code from an engagement leaves the engagement.
Requirements decompose business → functional → infrastructure; each lifecycle phase owns specific decisions.
Deployment platform is chosen on compliance/residency/latency evidence; versions are pinned and rollback is retained.
Trust boundaries are marked at every seam; untrusted content is data, privileged identities are least-privilege.

Cross-module themes worth knowing cold

Deterministic beats judgment for enforcement: deny rules and PreToolUse hooks (exit 2) enforce; CLAUDE.md and prompts guide.
Ids pair things: tool_use ↔ tool_result by id in adjacent turns; thinking blocks return untouched (signatures).
Budgets everywhere: context window (trim/compact), retry budgets (backoff + jitter + terminal detection), cost budgets (model tier, batching, caching), token cost of examples and thinking.
Dev hides what production reveals: short inputs hide context ceilings; stable endpoints hide missing error paths; single sessions hide memory-scope mistakes; happy-path tests hide seam breaks; trusted users hide injection via fetched content.
Never let untrusted content decide anything: not the write path, not the instructions, not the tool routing.
Pin and retain: full model IDs, prior versions, environment-injected secrets (rotate on any exposure — repo history is forever).

Thursday, August 13, 2026