Claude Architect · Lesson

Eliminating Wrong Answers

Anti-patterns are usually the distractors — recognize them.

Eliminating Wrong Answers is a free Claude Architect lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

The Distractor Is Usually an Anti-Pattern

On the Claude Certified Architect exam, every question gives you 4 options and exactly 1 is correct. The other 3 are distractors — and they are not random. They are engineered to look reasonable to someone who half-knows the material.

Here is the single most useful insight for this lesson: distractors are very often well-known anti-patterns dressed up as solutions. If you can recognize the anti-pattern catalog on sight, you can eliminate 2-3 options before you even finish reading them.

Elimination is leverage. With no penalty for guessing, killing two wrong answers turns a 25% guess into a 50% one — and usually leaves the correct answer obvious.

Build a Mental Anti-Pattern Catalog

Before you can eliminate, you need a list of red flags memorized cold. These are the recurring wrong answers across all 8 exam scenarios:

Parsing text for completion signals ("stop when the reply contains 'done'")
Arbitrary iteration caps as the primary stop mechanism
Minimal/ambiguous tool descriptions or too many tools per agent
Generic error statuses ("Operation failed")
Enforcing critical business rules with prompts alone
Single-pass multi-file review and same-session self-review
Batch API for blocking/time-sensitive checks
Sentiment/confidence-based escalation
Requiring possibly-absent schema fields
Silent error suppression and aggregate-only accuracy metrics

When an option matches one of these, it is almost certainly the wrong answer. Treat the list as a tripwire.

Red Flag: Parsing Text to Stop the Loop

The agentic loop terminates on stop_reason — never by scanning the model's text for words like "done" or "finished". Any option that loops while a string is in the output is an anti-pattern distractor.

The correct mechanism: send the full history each turn, inspect stop_reason, run tools on tool_use, and stop on end_turn.

# ANTI-PATTERN (a distractor you should eliminate):
while "done" not in response.content[0].text.lower():
    response = client.messages.create(...)

# CORRECT: terminate on the structured stop_reason
while response.stop_reason == "tool_use":
    tool_results = run_tools(response.content)
    messages.append({"role": "user", "content": tool_results})
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=messages,
        tools=tools,
    )
# loop exits when stop_reason == "end_turn"

Red Flag: Iteration Caps as the Primary Stop

A close cousin of the previous trap. An iteration cap ("stop after 10 turns") is a legitimate safety net — but it is never the primary stop mechanism. Decisions are model-driven; you reserve hard-coded limits for guarantees, not for control flow.

So when two options both mention a loop cap, read carefully: the wrong one makes the cap the main exit condition. The right one stops on end_turn and keeps the cap purely as a runaway guard.

MAX_TURNS = 25  # safety net ONLY — not how we normally stop
turns = 0
while response.stop_reason == "tool_use":
    if turns >= MAX_TURNS:
        raise RuntimeError("runaway loop guard tripped")  # rare escape hatch
    turns += 1
    messages.append({"role": "user", "content": run_tools(response.content)})
    response = client.messages.create(model="claude-sonnet-4-5",
        max_tokens=1024, messages=messages, tools=tools)
# normal, expected exit: stop_reason == "end_turn"

Red Flag: Prompts for Critical Business Rules

When a question involves money, legal, or safety consequences (refund limits, policy violations), an option that says "instruct the model in the system prompt to never refund over $500" is a distractor. Prompts are ~90% probabilistic. Hooks are 100% deterministic.

The correct answer enforces the rule with a PostToolUse / outgoing-call hook or a programmatic precondition — code the model cannot talk its way around.

# Distractor: "Add 'never refund more than $500' to the system prompt."
# Correct: deterministic enforcement outside the model.
def on_pre_tool_use(tool_name, tool_input):
    if tool_name == "process_refund" and tool_input["amount"] > 500:
        return {"block": True,
                "reason": "Refunds over $500 require human approval."}
    # precondition: identity must be verified first
    if tool_name == "process_refund" and not customer_verified():
        return {"block": True, "reason": "Verify customer identity first."}
    return {"block": False}

Red Flag: Bad Tool Design

Two tool-design distractors show up constantly in Scenario 4 and 8 questions:

"Improve selection by renaming the tools" — wrong. Tool descriptions, not names, are the primary selection mechanism.
"Give the agent all 18 tools so it never lacks one" — wrong. 4-5 tools per agent is optimal; 18+ degrades selection reliability.

The correct answers: write rich descriptions (purpose, return values, input formats with examples, edge cases, boundaries) and scope tools tightly to the role with least privilege.

# Correct: a description that actually drives selection.
lookup_order = {
    "name": "lookup_order",
    "description": (
        "Retrieve a customer's order by order_id. "
        "Returns status, line items, and total. "
        "order_id format: 'ORD-' + 8 digits, e.g. 'ORD-10293847'. "
        "Use AFTER get_customer verifies identity. "
        "Returns an empty result (not an error) if no order matches."
    ),
    "input_schema": {"type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"]},
}

Red Flag: Generic Errors & Silent Suppression

In multi-agent and extraction scenarios, watch for two error anti-patterns:

Returning "Operation failed" — a generic status that blocks intelligent recovery.
Silently swallowing a failure, or aborting the whole workflow because one subagent failed.

The correct answer returns structured errors: isError, errorCategory (transient/validation/business/permission), isRetryable, the attempted query, and partial results. It also distinguishes an access failure (maybe retry) from a valid empty result (no matches — don't retry).

# Distractor: return {"status": "Operation failed"}
# Correct: structured, routable error
error = {
    "isError": True,
    "errorCategory": "transient",   # vs validation/business/permission
    "isRetryable": True,
    "message": "Upstream timeout from inventory service",
    "attempted_query": "SELECT * FROM stock WHERE sku='A91'",
    "partial_results": [{"sku": "A91", "warehouse": "EU"}],
}

Red Flag: Same-Session & Single-Pass Review

For code-review and CI/CD scenarios (Scenario 2 and 5), eliminate any option that reviews in the same session that generated the code — the author keeps its own reasoning and won't challenge itself. An independent, fresh-instance review is always stronger.

Also eliminate single-pass multi-file review: it dilutes attention. The correct multi-pass approach does a per-file local pass, then a separate cross-file integration pass.

# Distractor: same chat asks itself "now review what you wrote."
# Correct (CI/CD): isolated, non-interactive review session.
#   claude -p "Review this diff for correctness bugs only." \
#     --output-format json \
#     --append-system-prompt "Flag an issue ONLY when code contradicts intent."
#
# Multi-pass: pass 1 per-file, pass 2 cross-file integration —
# never one single pass across all files at once.

Red Flag: Batch API for Blocking Checks

The Message Batches API is 50% cheaper with up to a 24-hour window — but it has no latency SLA and does not support multi-turn tool calling. So any option that uses Batch for a pre-merge gate, a synchronous user-facing check, or an agentic tool loop is a distractor.

Batch is correct only for non-blocking jobs: overnight audits, bulk reports. If the scenario word is "blocking", "pre-merge", "real-time", or "the user is waiting" — eliminate Batch immediately.

# Correct use of Batch: overnight, non-blocking audit.
batch = client.messages.batches.create(requests=[
    {"custom_id": "doc-001",   # custom_id correlates each result
     "params": {"model": "claude-sonnet-4-5", "max_tokens": 1024,
                "messages": [{"role": "user", "content": audit_prompt(d)}]}}
    for d in nightly_documents
])
# WRONG: using this for a pre-merge CI gate (no latency SLA, no tool loop).

Red Flag: Bad Escalation & Bad Schemas

Two more high-frequency distractors:

Escalation triggered by sentiment analysis or a model self-rated confidence score (1-10). These are bad triggers. Good triggers: explicit human request, policy gaps, no progress after attempts, threshold violations.
Marking a possibly-absent field as required in a JSON schema. The model will fabricate it. Require a field ONLY if it is always present; use enums with an "other" value plus a free-text detail for extensibility.

If an option escalates on "angry tone" or requires "middle_name" — eliminate it.

# Distractor schema: requires a field that's often missing.
# Correct: only truly-always-present fields are required.
schema = {
    "type": "object",
    "properties": {
        "invoice_id": {"type": "string"},
        "category": {"type": "string",
                     "enum": ["goods", "services", "other"]},
        "category_detail": {"type": "string"},  # free-text, NOT required
        "po_number": {"type": "string"},        # may be absent -> NOT required
    },
    "required": ["invoice_id", "category"],
}

The Elimination Drill

Put it together into a repeatable process for every question:

1. Read the scenario for the real constraint — money/legal (needs a hook), blocking vs overnight (Batch or not), single vs multi-file (passes), present vs absent field (required or not).
2. Scan all 4 options for anti-pattern tripwires and strike every match. Usually 2-3 fall away.
3. Among survivors, pick the one with a deterministic guarantee where it matters — structured over generic, model-driven stop over text parsing, independent over self-review.
4. Always answer. No penalty for guessing — never leave a blank, even when you're down to a coin flip.

Anti-pattern recognition isn't a shortcut around understanding; it's how an experienced architect reads a question fast and clean.

Quick Check

Apply the elimination drill to a real exam-style scenario.

Recap: Read the Constraint, Strike the Anti-Pattern

Key takeaways for eliminating wrong answers:

Distractors are usually anti-patterns in disguise. Memorize the catalog and treat each one as a tripwire.
Eliminate on sight: text-parsing to stop, iteration caps as the primary stop, prompts for critical rules, generic/suppressed errors, too many tools, name-based tool selection, single-pass and same-session review, Batch for blocking checks, sentiment/confidence escalation, requiring absent fields.
The right answer favors deterministic guarantees where stakes are high: hooks and preconditions, structured errors, model-driven termination on end_turn, independent review, rich tool descriptions.
Always answer — no guessing penalty. Strike two distractors and a coin flip becomes a strong bet.

Recognize the trap, and the correct option practically selects itself.

Frequently asked questions

Is the “Eliminating Wrong Answers” lesson free?

Yes — the full text of “Eliminating Wrong Answers” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.

What will I learn in “Eliminating Wrong Answers”?

Anti-patterns are usually the distractors — recognize them. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Claude Architect?

No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Eliminating Wrong Answers” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Claude Architect lesson?

Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Claude Architect