Software Engineering Foundations

What You Need to Know

This sub-skill covers the engineering around a Claude integration. A fan-out splits one job into many independent API calls. Bounded concurrency caps how many run at once. Messages API rate limits are measured in requests, input tokens and output tokens per minute (RPM, ITPM and OTPM).

Take a bathroom fitter that uses Claude to turn site-survey notes into quotes. It sends a few hundred notes each night, and staff request single quotes from a web form.

HTTP and JSON

Everything in 2.3 runs on plain HTTP and JSON. Know which side sets which header. The 4xx versus 5xx division tells you whose bug it is. An idempotent retry is safe for a read, because reading twice changes nothing. Retrying a create needs thought, because the fitter could file one quote twice.

A JSON payload that crosses a service boundary is an interface. Renaming a field or changing a type breaks every consumer. So contract changes are versioned and reviewed like any API change, never shipped as internal details.

The official SDKs wrap the REST API in seven languages: Python, TypeScript, C#, Go, Java, PHP and Ruby. Typed error classes map onto the documented status codes. The SDK tables name no class for 402 or 413; read those off status_code. In every language, catching the specific class beats string-matching messages.

import anthropic

client = anthropic.Anthropic()

try:
    response = client.messages.create(
        model="claude-sonnet-5-5",
        max_tokens=512,
        messages=[{"role": "user", "content": record}],
    )
except anthropic.RateLimitError:
    ...  # 429: honour retry-after, back off
except anthropic.APIStatusError as err:
    print(err.status_code, err.request_id)

Bounded Concurrency

The fitter's nightly run can fail two ways. A serial loop sends one call at a time, wasting the rate limit and taking hours it does not need. An unbounded fan-out launches every request at once. It trips the token-bucket limiter and turns the run into a 429 storm. Sharp usage spikes can also trigger acceleration limits.

The correct shape is a worker pool or semaphore. It keeps enough requests in flight to use the documented RPM, ITPM and OTPM headroom, and no more. Transient failures, including rate limits and 5xx server errors, are retried with exponential backoff on top. That backoff is jittered and honours retry-after.

import asyncio
import random
import anthropic

# Hand-rolling backoff here, so disable the SDK default of two retries;
# otherwise every application attempt multiplies into three requests.
client = anthropic.AsyncAnthropic(max_retries=0)
semaphore = asyncio.Semaphore(5)  # sized against your documented limits

def spend_capped(err: anthropic.RateLimitError) -> bool:
    body = err.body if isinstance(err.body, dict) else {}
    details = (body.get("error") or {}).get("details") or {}
    return details.get("error_code") == "enforced_spend_limit_reached"

async def normalise(record: str) -> str:
    async with semaphore:
        for attempt in range(4):
            try:
                response = await client.messages.create(
                    model="claude-sonnet-5-5",
                    max_tokens=512,
                    messages=[{"role": "user", "content": record}],
                )
                return response.content[0].text
            except anthropic.RateLimitError as err:
                if spend_capped(err):
                    raise  # the tier's monthly spend cap: no retry clears it
                wait = float(err.response.headers.get("retry-after", 2 ** attempt))
                await asyncio.sleep(wait + random.uniform(0, 1))
        raise RuntimeError("still rate limited after backoff")

async def main(records: list[str]) -> list[str]:
    return await asyncio.gather(*(normalise(r) for r in records))

The SDKs already retry twice by default, so a hand-rolled loop that ignores this multiplies attempts: three application tries become nine requests. That amplifies the bursts backoff exists to damp, hence max_retries=0. OTPM counts the tokens generated. So lowering max_tokens is no rate-limit lever. It only risks truncating the fitter's quotes.

The loop also re-raises one 429 at once. As of September 2026, the tier's monthly spend cap returns a 429 with no retry-after and error.details.error_code set to enforced_spend_limit_reached. No retry clears it until access resumes.

The synchronous cousin is the blocked handler. If the fitter's web form calls the Messages API synchronously inside the request handler, a worker is pinned for the whole generation. That takes seconds to minutes, so throughput collapses under modest load. The fix is async I/O, streaming to the client, or a job queue, chosen by the interaction pattern.

Concurrency or Batch: the Deadline Decides

When the fan-out is large and the deadline loose, the Batches API from 2.3 returns. Results needed within hours go realtime with bounded concurrency. Results acceptable within a day, with cost the main concern, go to batch. Quotes due before the fitter's office opens stay realtime. 2.3 owns choosing the API; this sub-skill owns writing the concurrent code when realtime wins.

Prompts Are Source Code

A prompt change is a behaviour change with the blast radius of a code change. The same holds for output schemas, eval sets, CLAUDE.md files and settings. So they live in the repository, change through branches and review, carry history and roll back like code. A quote prompt tweaked live in the fitter's production console has no history, no review, no rollback, and no guarantee staging matches what users see.

Prompt and schema changes ride the code pipeline, with the eval suite as their regression gate. An edit that lowers eval scores fails the build like a failing test. That gate makes fast prompt iteration safe. If the pipeline is the only route to production, console editing is structurally impossible, not merely discouraged.

Review and Refactoring Discipline

Claude speeds up mechanical work, but some human disciplines do not relax. An AI-assisted diff gets the same review bar as a human one, because review catches a subtly wrong generated refactor. Green tests do not prove behaviour unchanged when no test pinned that behaviour. If no test covers how the fitter prices tiling labour, a refactor that changes it still passes.

Refactoring splits by scale. Small refactors go in behaviour-preserving steps, with the suite green after each. Large work on a poorly covered module first builds a safety net: characterisation tests pinning what the code does now. Then comes an incremental migration, each step small enough to review and revert. For the fitter, that means tests on today's quote prices first. A one-big-rewrite plan, with a new contract and review skipped because tests pass, stacks three violations.

In the exam

This second-heaviest sub-skill in the domain tests whether your engineering discipline is real. It expects protocol fluency over framework familiarity, and knowing which human disciplines do not relax. Wrong options are reasonable-looking shortcuts: the synchronous handler, the unbounded fan-out, the console-edited prompt, the review exemption. The exam states the production console edit as an anti-pattern outright. The one-big-rewrite recurs as a distractor because it stacks three violations.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Claude API errors — Claude Docs, typed SDK exceptions, default retry behaviour and the status table
• Rate limits — Claude Docs, token-bucket enforcement, acceleration limits, OTPM counting actual generated tokens and the spend-cap 429
• CLI, SDKs, and libraries — Claude Docs, the seven official SDKs and their shared behaviour
• Batch processing — Claude Docs, the batch alternative when the deadline allows it
• Claude Certified Developer Foundations Exam Guide — Domain 2, Software Engineering Foundations — Anthropic