How Claude Interprets Instructions Across Interfaces for the Developer Exam

Different interfaces, different instruction surfaces

You interact with Claude through several distinct interfaces, Claude Code, the Claude Desktop app, claude.ai in the browser, the raw API, and the client SDKs, and a defining fact for the Claude Certified Developer - Foundations (CCDV-F) exam is that they do not all read instructions from the same place. Each interface exposes its own configuration surfaces: the API and SDKs take a system prompt and messages in the request; Claude Code reads project context from a CLAUDE.md file and honours a settings file; the desktop and web apps have their own settings and conversation context. An instruction only takes effect if it is placed on a surface the interface you are using actually consumes.

This sits on top of the Messages API request-response cycle. The API is stateless and acts only on what the request contains, so for an API integration the request is the entire universe of instruction. Other interfaces add file- and settings-based surfaces on top, but those conveniences belong to the interface, not to the model in general. Designing a Claude application well starts with knowing which surfaces your chosen interface reads and putting your instructions there.

The same instruction lands differently

Because the surfaces differ, an identical instruction can behave differently depending on where you put it and which interface is running. Written into a Claude Code CLAUDE.md, a coding convention shapes how Claude Code works in that project because Claude Code reads that file. The very same text pasted nowhere the interface reads, or sent to an interface that has no notion of that file, does nothing at all. Likewise, an instruction placed in the API system prompt is in force for every request that carries it, while the same instruction buried in a single user message applies only to that turn.

The lesson is that placement is not cosmetic; it determines whether an instruction is consumed. This is why content boundaries and schema design matter alongside this knowledge point: deciding where each instruction lives, and being deliberate that the chosen interface reads that location, is part of designing the application, not an afterthought. An instruction that is behavior-critical has to sit on a surface the interface actually consumes, or it is just inert text.

The two traps the exam sets

The first trap is assuming a CLAUDE.md convention applies to a raw API integration that never reads it. CLAUDE.md is a Claude Code feature: it supplies project context to Claude Code specifically. A raw API or SDK integration does not read CLAUDE.md at all, so a team that documents "the model will follow the rules in our CLAUDE.md" and then builds directly on the API has written instructions the integration will never see. The behavior they expect simply will not happen, because the surface they used belongs to a different interface. If those rules are behavior-critical, they must be sent in the API request, typically in the system prompt.

The second trap is placing behavior-critical instructions where the chosen interface does not consume them. This is the general form of the first trap: any time an instruction that must take effect is put on a surface the running interface does not read, it is dead weight. It could be a settings file the interface ignores, a file convention from another tool, or context added in the wrong part of a request. The symptom is always the same, an instruction that "should" apply but demonstrably does not, and the cause is a mismatch between where the instruction lives and where the interface looks.

Choose the interface whose instruction model fits

The third concept turns the first two into a design principle: application design chooses the interface whose instruction model matches the use case. Because the interfaces differ in how they take instructions and maintain context, the right choice depends on what you are building. A programmatic, high-volume service that needs precise, per-request control over behavior fits the API or an SDK, where every instruction rides in the request and you own the full context. A project-scoped coding assistant that should absorb repository conventions fits Claude Code, where CLAUDE.md and settings give exactly that file-based context. An interactive end-user experience may fit the desktop or web app.

Choosing deliberately means the instruction surfaces you rely on are ones the interface actually reads, which is precisely what avoids both traps. It also connects to CLAUDE.md and settings.json configuration: once you have picked an interface, configuration management is about maintaining the specific surfaces that interface consumes. The design question, asked early, is which interface's instruction model matches this use case, and then place every behavior-critical instruction on that interface's surfaces.

How this is tested on the exam

Domain 2 questions on this knowledge point are design and diagnosis scenarios. The signature case gives you a team relying on a CLAUDE.md, or another interface-specific surface, from a raw API integration and asks why the expected behavior does not appear; the correct answer is that the API does not read that surface and the instructions must be sent in the request. Others describe an instruction that "should" apply but does not, and ask you to locate the mismatch between where it lives and which interface reads it.

Reason from the three concepts. Interfaces expose different instruction surfaces; the same instruction lands differently by placement and interface; and good design picks the interface whose instruction model fits and puts behavior-critical instructions where that interface consumes them. Keep those straight and you avoid the two traps, assuming CLAUDE.md reaches the API, and placing critical instructions where the interface never looks, which are exactly the errors this knowledge point is built to test.