A coding agent can draft a convincing patch, explain its changes and still leave a system less reliable than it found it. The difference between a useful coding assistant and a production-ready engineering workflow is the system around it: project instructions, permission boundaries, deterministic checks, code review and a record of what actually changed.
Claude Certified Architect – Foundations examines that system. The published blueprint allocates 20 percent to Claude Code Configuration & Workflows. This does not make candidates responsible for memorizing every command-line flag. It asks them to judge how an organization should configure coding assistance so that developers gain speed without losing accountability.
Project instructions should explain constraints, not replace controls
A repository may have a prescribed test command, directory layout, API version and deployment policy. Without those facts, an assistant must discover them repeatedly or make assumptions. A well-maintained CLAUDE.md file can supply durable, project-specific context: which areas are generated code, where integration tests live, what constitutes an acceptable change and which architectural decisions are non-negotiable.
Good instructions are specific enough to be actionable. “Write clean code” is vague. “Do not edit files under generated/; regenerate them using the documented build step and run the API compatibility tests before proposing a patch” changes behavior. The file should also distinguish general repository conventions from task-specific requirements. A temporary feature request belongs in the current task, not necessarily in permanent project instructions.
Yet instructions remain text. A statement that production credentials must never be used cannot substitute for isolating credentials from the coding environment. Sensitive paths need operating-system permissions, separate access controls or tooling constraints. Developers should not confuse the agent’s willingness to follow a policy with a security mechanism capable of enforcing it.
A team should also review how instructions are inherited across directories or workspaces. Conflicting guidance can produce surprising behavior. The meaningful question is which source has authority and whether the resulting change is independently validated, not whether the agent confidently says it followed every rule.
Use planning when the blast radius is unclear
Not every edit needs an elaborate plan. Fixing a spelling error in a comment is different from migrating a persistence layer or restructuring a deployment pipeline. A plan-oriented workflow can help an agent inspect the repository, identify dependencies, estimate the scope of a change and present a sequence of modifications before any high-risk write occurs.
This matters most when the task has hidden coupling. Changing a shared API type may require client regeneration and coordinated tests. Updating a security-sensitive authentication module may affect token handling, logging and integration contracts. A good preliminary plan records which files and tests matter, which assumptions still need checking, and what the rollback route would be.
A plan should not become an automatic excuse for more text. The approval boundary is useful when it changes the risk of execution. If an agent could already run an arbitrary shell command on a production server, a written plan alone does not make that safe. The system must provide a permissions boundary that constrains actual tool calls.
During an architectural review, ask what the agent can do before review and what requires explicit action from a developer. Read-only inspection is often a reasonable default; changes to deployment configuration, secrets, data migrations or release branches deserve tighter controls.
Permissions must be expressed as capabilities
Claude Code can interact with files, commands and external tools. The relevant architectural decision is which capabilities to expose in a particular environment. An assistant working in a disposable branch with test fixtures has different authority from one that can modify production infrastructure.
Separate capabilities by risk. Reading source code and running a local unit test are generally narrower than deleting a directory, calling a billing API or deploying a release. Permissions should be least-privilege, observable and reversible wherever possible. When an operation requires approval, present the actual operation and target, not a vague summary that conceals the command being executed.
External tool integrations deserve the same scrutiny. An MCP server added to a coding environment can expose repository management, issue tracking or secrets. Tool availability should follow the developer’s verified role, and the backing service must enforce its own authorization. A model should never inherit a universal credential simply because it is convenient during setup.
Secure tool access for AI agents begins by defining the work to be done, granting only necessary operations, and independently checking high-impact actions.
Hooks turn policy into observable checkpoints
A hook can run a conventional command at a defined stage of a coding workflow, such as formatting files, testing changed modules, checking a diff or verifying an artifact. Deterministic hooks are useful because their results come from an external tool rather than the model’s own estimate of correctness.
Suppose a coding assistant changes an API contract. A hook can run a schema validation or build check. If it fails, the workflow has evidence of a defect and should not claim the change is ready. The failure needs to be surfaced with an actual command result and relevant diagnostics. The agent can propose a fix, but the check must run again before completion is reported.
A hook should be designed for predictable timing and cost. A long, expensive integration suite on every tiny edit may disrupt the workflow without improving decisions. Conversely, running only a linter after a database migration leaves critical behavior untested. Choose checks according to change type, and make it clear which must succeed before publication or deployment.
Security-sensitive checks should not rely on easy-to-bypass local scripts alone. Protected branch rules, continuous integration and deployment gates can enforce policies at a boundary the agent cannot simply skip. Local hooks improve feedback; release controls establish organizational authority.
The project instruction and the enforcement hook solve different jobs
Suppose a repository requires an architect to keep generated API clients outside manual edits. A project instruction can explain the reason and point Claude toward the generator’s source specification. A hook can run a deterministic check that rejects modifications to generated paths or requires a regeneration command, while CI independently verifies that generated artifacts match their sources. These are not competing approaches: one helps the assistant understand the project, the second checks behavior at a defined workflow point and the third guards the actual merge.
If a project contains both ordinary application files and infrastructure-as-code that can alter production permissions, a single blanket instruction may create noisy refusals or insufficient caution. Define file-specific conventions and use explicit permission boundaries where a command can have an external effect. A planned edit should state which directories are in scope, what tools are available and which results must be produced before the task is considered complete. Subagents may help with bounded code exploration, but they should not inherit more privileged credentials merely because they have a narrower task.
Verify the resulting workflow by proposing an allowed edit, a forbidden generated-file edit and an interrupted test run. Inspect actual hook and CI receipts. If the model says “the tests passed” while the runner is still executing, treat that as an unverified claim. A successful developer workflow has reproducible evidence and safe failure behavior, not just correct prose about engineering process.
Skills, subagents and context serve different purposes
A skill packages a repeatable procedure or domain knowledge. For example, a repository may describe how to regenerate clients after an API change or how to conduct an accessibility review. The content can help a coding assistant follow established practices without embedding every instruction in the top-level prompt.
A subagent, by contrast, can tackle a bounded assignment with its own context or tools. A parent might ask one worker to inspect tests and another to review a database migration plan. The parent must reconcile the results and validate whether the workers examined the same code revision. Two agents agreeing is not a substitute for running tests.
Context design is often the limiting factor. Feeding an entire codebase into every request increases noise and cost. Useful workflows locate relevant files, narrow the task and preserve durable findings. When a session continues after an interruption, the assistant should recover from real repository state and saved test output rather than inventing progress from a summary.
The organization should decide which instructions are static and which facts must be refreshed. A CLAUDE.md description of where tests live may remain useful for months; the claim that a specific test passed is per-revision evidence and must not be treated as permanent memory.
CI/CD integration needs an accountable release path
Claude Code can assist with reviewing pull requests, proposing test changes or investigating a failed build. That is different from granting it direct release authority. A production-friendly pipeline records the candidate commit, runs independent checks, stores their outputs and requires the appropriate approvals before a release.
The agent’s written conclusion belongs alongside those records, not in place of them. A comment saying “all tests pass” is not enough if the CI workflow never ran or tested a different commit. A sound process associates every claimed check with its exact code revision and execution result. When failures appear, the system should prevent a release even if the agent argues that the error is unrelated.
Teams also need a strategy for nondeterministic code suggestions. A coding agent may make different edits for similar prompts, which means review and test coverage remain essential. Regression tests should target observable contracts and important edge cases instead of merely checking that generated code has a familiar shape.
Avoid adding an unnecessary model call to every deployment stage. Some checks are better handled by traditional tooling: static analyzers, dependency audits, type checkers, database migration checks and integration tests. Claude can interpret their findings, but it should not replace their deterministic pass/fail function.
Debugging a workflow without hiding the evidence
When a coding assistant fails to implement a change, diagnose the process before changing the model. Did it read the relevant files? Did the task brief specify the desired behavior? Was the tool denied permission? Did the test failure come from an environmental dependency? Did a long session lose the original requirement? These problems demand different fixes.
For example, a model may repeatedly edit the wrong configuration file because the repository contains several similarly named files. The remedy may be a clearer project map or a more precise file-selection instruction. If a tool invocation fails because a service token is expired, revising the prompt will not renew that token. If tests time out, the runner needs bounded retries or the environment must be repaired.
A useful postmortem preserves the input request, files examined, actual edits, commands executed, test results and human interventions. It should not dump credentials or sensitive source material into an unrestricted transcript. Provenance makes failure actionable and allows the team to identify whether a defect came from planning, tool design, verification or permissions.
An architect should also consider how much work the agent can safely perform unattended. Long-running automation needs checkpoints, cancellation, meaningful progress records and a way to resume without duplicating a deployment or overwriting another developer’s changes.
An exam-quality exercise
In a disposable project, create a task that requires both a code change and a test update. Document repository conventions in CLAUDE.md, configure narrow tool permissions and add an external check that will fail if the desired behavior is not implemented. Ask Claude Code to inspect the project and propose a plan before editing. Then introduce a deliberate failing test and examine whether the workflow reports the failure accurately.
Next, test an interruption. Restart the process and see whether it can identify the current branch, uncommitted modifications and completed tests without claiming work that never happened. Finally, propose a command that would modify a protected resource and confirm the environment blocks it independently of the model’s wording.
Those exercises matter more for CCA-F than memorizing one set of commands. The credential examines whether an architect can design a workflow where coding assistance produces useful work while conventional engineering controls still define what is approved, reproducible and safe to release.