Software Engineering Foundations for Claude Applications.

This objective is general software-engineering discipline, applied specifically to shipping production Claude apps. The load-bearing insight for developers: the Claude Messages API *is* a REST API that accepts and returns JSON, so the same practices used for any HTTP service - resource-oriented verbs and paths, JSON contracts, asynchronous I/O, version control, code review, and disciplined refactoring - are exactly what a well-built Claude integration needs. Concretely, "Create a Message" is POST /v1/messages, a stateless call: you send prior conversational turns and the model returns the next one. REST's defining constraint - stateless client-server interaction over a uniform interface, per Fielding's original dissertation - is exactly how the Messages API's multi-turn design behaves.

None of this is Claude-specific machinery to relearn from scratch. An engineer who already knows how to design a resource, validate a JSON contract, reason about blocking vs. non-blocking I/O, keep a codebase under version control with reviewed pull requests, and refactor without changing observable behavior already has the core toolkit this objective tests - the job is recognizing that a Claude integration is an instance of that toolkit, not an exception to it.

REST + JSON contract. The request body is JSON with required fields model, max_tokens, and messages (an array of {role, content} turns alternating user/assistant); the response is a JSON Message object with id, type, role, content (an array of content blocks), model, stop_reason, and usage (input_tokens/output_tokens). Because the API is stateless, the server does not remember prior turns - you resend the full conversation history on every call; state lives entirely in your application, not on Anthropic's servers. This is the single most common source of "my app forgot what the user said" bugs: it isn't a bug in the API, it's a missing array element in the request your app sent.

Asynchronous programming. The official Python SDK ships both a synchronous Anthropic client and an AsyncAnthropic client; async calls use await client.messages.create(...), letting an application fan out concurrent requests - parallel tool calls, multiple users, batch workloads - without blocking on each one sequentially. Async matters most when the workload is inherently concurrent or when a call streams; a single simple integration with light traffic gets no meaningful benefit from async machinery it doesn't need.

Streaming. Setting "stream": true returns the response incrementally as Server-Sent Events instead of one blocking payload; SDKs expose client.messages.stream(...) with helpers like get_final_message() to assemble the complete response once streaming finishes. The concrete engineering reason to reach for this: it prevents client/proxy timeouts on long generations or high max_tokens requests that would otherwise sit silent until the full response is ready. Streaming is a latency/UX and timeout-avoidance tool, not a cost-reduction one - token billing is identical whether or not you stream. For the full mechanics of parsing stream events, see the dedicated streaming concept page - see Study Next.

Version control and code review. Use git for history and branching, and treat the pull-request review flow - propose changes on a branch, get them reviewed before merge - as standard practice for anything that ships to production. The Claude-specific implication: system prompts, tool schemas, and orchestration code are source, not configuration to be hand-edited live. A system-prompt change that skips code review is exactly as risky as an unreviewed change to any other production code path, and arguably riskier, since prompt behavior is harder to unit-test deterministically than most application logic.

Refactoring. Restructuring code without changing its observable behavior is the discipline that keeps an evolving prompt/tool/agent codebase maintainable as it grows - renaming and reorganizing tool definitions, splitting an orchestration loop into smaller functions, or consolidating duplicated system-prompt fragments, all without altering what the agent actually does. The distinction that matters for a Claude app specifically: a change is a refactor only if the observable behavior (the agent's outputs, tool-call sequences, eval scores) is provably unchanged - anything that shifts behavior, even a prompt wording tweak intended to be "just cleanup," is a behavior change requiring re-evaluation against the eval suite (see the systems-life-cycle-management page's test-phase discipline), not a refactor exempt from testing.