The 13 CCDV-F anti-patterns: wrong answers, catalogued

Thirteen wrong answers that recur across the CCDV-F question bank.

1. Reading content[0].text unconditionally

Wrong: Treating the response content as a string, or assuming the first block is text.

Right: content is an array of typed blocks. A thinking block or a tool_use block can precede the text, and code that indexes blindly breaks the first time one does.

2. Parsing prose to decide control flow

Wrong: Ending the agent loop when the text contains "done" or "final answer".

Right: Branch on stop_reason. tool_use means continue, end_turn means stop, max_tokens means truncated rather than finished.

3. Treating max_tokens as a normal completion

Wrong: Parsing a max_tokens response as a complete answer.

Right: It is truncated. Any JSON in it is probably malformed, and any conclusion in it was probably never reached. Continue the generation or raise the limit.

4. Asking for JSON in the prompt and parsing the result

Wrong: "Respond only with JSON, no prose", then json.loads in a try/except.

Right: output_config.format with a schema, or strict: true on the tool. Constrain at generation instead of validating after the fact.

5. Assuming a schema guarantees correctness

Wrong: Trusting a schema-valid extraction because it parsed.

Right: A schema guarantees shape, not truth. Business validation — cross-field consistency, ranges, referential integrity — is a separate step, and refusal or max_tokens can still produce non-conforming output.

6. Blanket retry on every error

Wrong: Three attempts with exponential backoff regardless of status code.

Right: Retry 429, 500, 504 and 529, honouring retry-after. Surface 400, 401, 403, 404 and 413 immediately — retrying a permanent failure buys latency and nothing else.

7. Reacting to rate limits instead of anticipating them

Wrong: Waiting for the 429 and backing off.

Right: Watch anthropic-ratelimit-*-remaining and throttle before you are throttled. Remember that cache reads do not count toward ITPM, so caching raises effective throughput as well as cutting cost.

8. Reaching for an agent when a workflow would do

Wrong: Building an autonomous agent because it is more flexible.

Right: Use the least complex pattern that meets the requirement. Agents cost latency, spend, predictability and debuggability, and are justified only when the steps genuinely cannot be known in advance.

9. Routing everything through the Batches API to save money

Wrong: Applying the 50% discount uniformly.

Right: Batch processing is asynchronous, with a window of up to 24 hours. Match the surface to the latency requirement: batch the offline evaluation run, keep the interactive path on the standard API with prompt caching.

10. Fixing context problems with a bigger window

Wrong: Moving to a larger context window when quality degrades in long conversations.

Right: Attention dilutes across long contexts. Trim stale tool results, offload state to files or memory, isolate exploration in a subagent, and use context editing to clear automatically.

11. Trusting tool results because they came from your own tool

Wrong: Treating retrieved content — a web page, an email, a document, an MCP server response — as trusted because your code fetched it.

Right: Everything you did not write is untrusted data. Put it in tool_result blocks, label its provenance, and never let it issue instructions.

12. Writing to stdout in a stdio MCP server

Wrong: A print() or console.log() left in for debugging.

Right: stdout carries the JSON-RPC stream. Anything else written there corrupts it and breaks the server in a way that looks like a connection fault. Log to stderr.

13. Prompt-level defence where architectural defence was available

Wrong: Hardening the system prompt against an agent misusing a dangerous tool.

Right: Remove the tool from that agent's scope. Prompt defences reduce the probability of an attack succeeding; least privilege removes the possibility of damage.

← Previous: Domain 8 — Eval, Testing and Debugging  |  Next: Cheat sheet →