Intent-Driven Engineering and Claude Code Architect Certification: Context Is the Architecture
- Mark Kendall
- 2 days ago
- 7 min read
Intent-Driven Engineering and Claude Code Architect Certification: Context Is the Architecture
Most people think Claude Code succeeds or fails based on the prompt.
That is only partly true.
At the architect level, Claude Code succeeds or fails based on context.
The prompt is the request. Context is the operating environment. Context tells Claude what system it is inside, what rules matter, what files matter, what patterns to follow, what not to touch, what tools it can use, and what evidence must be produced before the work is considered complete.
That is why context management is one of the most important subjects for anyone preparing for the Claude Certified Architect, Foundations exam. Anthropic introduced Claude Certified Architect, Foundations as a technical certification for solution architects building production applications with Claude, available through the Claude Partner Network.
This is not just a coding certification. It is an architecture certification.
And architecture begins with controlled context.
The Big Shift: From Prompting to Operating Context
A developer asks:
“Can Claude write this feature?”
An architect asks:
“What context does Claude need to safely and repeatedly deliver this feature inside our enterprise system?”
That is a completely different question.
In Claude Code, context can come from many places: repository files, CLAUDE.md, project instructions, skills, subagents, hooks, MCP servers, command history, source code, test output, API documentation, tickets, Confluence pages, diagrams, and human feedback.
Anthropic’s Claude Code documentation describes mechanisms such as CLAUDE.md, skills, subagents, hooks, MCP, and plugins as ways to extend and structure Claude Code behavior. The docs also describe patterns where MCP provides the connection to external systems while a skill teaches Claude how to use that connection well.
That sentence is huge.
It means the architect’s job is not only to give Claude access. The architect’s job is to shape access into reliable behavior.
Access without context creates chaos.
Context without validation creates false confidence.
Context plus validation creates architecture.
Why Claude Fails When Context Is Weak
When Claude Code performs badly, many teams blame the model.
Sometimes the real problem is that the model was dropped into a messy system with weak instructions, unclear ownership, missing architecture rules, and no validation loop.
Common failure modes look like this:
Claude changes the wrong layer because the repo structure was never explained.
Claude writes code that passes locally but violates enterprise standards.
Claude creates a clever implementation that does not match the existing design pattern.
Claude edits too many files because boundaries were not defined.
Claude calls the wrong tool because MCP access was available but tool usage rules were missing.
Claude produces a large answer, but no test evidence, no risk statement, and no implementation summary.
That is not a Claude problem alone. That is an operating-model problem.
A Claude Code Architect needs to know how to reduce those failures through better context design.
The Architect’s Context Stack
For certification prep, I would think of Claude Code context in five layers.
1. Repository Context
This is the codebase itself.
Claude needs to understand the structure of the repo: frontend, backend, APIs, tests, configuration, deployment files, build scripts, documentation, and naming conventions.
At the architect level, this should not be left to discovery every time. The repo should contain clear context files explaining how the system is organized and how work should be done.
Research on agentic coding manifests found that files such as CLAUDE.md are used to provide project context, identity, operational rules, commands, architecture notes, and implementation guidance to coding agents.
That confirms what we are seeing in the field: the context file is becoming a serious engineering artifact.
In Intent-Driven Engineering language:
The repo should not just contain code. It should contain intent.
2. Task Context
This is the feature, bug, story, or change request.
A weak task says:
“Add login.”
A stronger task says:
“Add login using our existing auth provider, follow the current API gateway pattern, update the React login screen, add unit tests, preserve existing session behavior, and produce evidence showing the route, tests, and security assumptions.”
That second version gives Claude a better operating box.
For certification purposes, the question is not whether Claude can generate code. The question is whether the architect can define the intent clearly enough that Claude can make the right decisions.
3. Tool Context
This is where MCP, APIs, databases, Jira, Confluence, GitHub, Figma, test runners, and deployment systems come into the picture.
Anthropic’s Claude Code documentation says Claude Code can connect to external tools and data sources through MCP, an open standard for AI-tool integrations.
But here is the trap: connecting a tool does not mean the agent knows how to use the tool responsibly.
That is where architecture matters.
The architect must define:
Which tool can be used?
When should it be used?
What inputs are allowed?
What output should be trusted?
What action requires human approval?
What evidence must be captured?
For example, giving Claude access to Jira is not enough. Claude needs to know whether Jira is the source of truth for scope, whether Confluence overrides Jira for design, whether Figma overrides both for UI behavior, and whether GitHub is the final evidence layer.
That is architecture.
4. Execution Context
This is where Claude actually acts.
Claude Code can run commands, edit files, inspect output, reason over failures, and repeat the loop. Anthropic’s Agent SDK documentation describes giving developers access to the same tools, agent loop, and context management that power Claude Code in Python and TypeScript.
For an architect, execution context means designing the safe operating lane.
Should Claude run tests automatically?
Should it be allowed to install packages?
Should it create branches?
Should it open pull requests?
Should it modify infrastructure files?
Should it stop when a test fails or attempt repair?
Should hooks enforce formatting, security checks, or forbidden file rules?
Anthropic’s hooks documentation describes hooks as a way to automate actions around Claude Code events, including advanced behaviors such as async hooks, HTTP hooks, prompt hooks, and MCP tool hooks.
That is not a toy feature. Hooks are one of the places where Claude Code becomes an enterprise workflow engine.
5. Evidence Context
This is the layer most teams forget.
Claude should not just do work. Claude should prove what it did.
A certification-level architect should expect evidence such as:
Tests run.
Files changed.
Commands executed.
Assumptions made.
Risks identified.
Validation results.
Open questions.
Human approvals required.
Rollback notes.
This is where Intent-Driven Engineering becomes powerful. The intent file should not only describe the desired outcome. It should also define the required evidence.
A feature is not done because Claude says it is done.
A feature is done when the evidence matches the intent.
The Certification Mindset: Context Before Autonomy
A weaker architect gives Claude more autonomy and hopes for speed.
A stronger architect gives Claude better context, safer tools, clearer boundaries, and stronger evidence loops.
That is the exam mindset.
The exam will likely not reward “Claude can code fast.” It will reward understanding how to design systems where Claude can operate safely, repeatedly, and measurably.
The real pattern is:
Intent → Context → Tools → Execution → Validation → Evidence
That is the architecture loop.
And every part of that loop matters.
If intent is vague, Claude guesses.
If context is missing, Claude wanders.
If tools are uncontrolled, Claude overreaches.
If execution is unbounded, Claude changes too much.
If validation is weak, Claude sounds confident but may be wrong.
If evidence is missing, the enterprise cannot trust the result.
The Intent File as the Context Contract
This is why I keep coming back to the intent file.
In traditional software delivery, the ticket often becomes the work request. But tickets are usually not enough for agentic engineering. A Jira story may describe the business need, but it often does not contain the architecture, repo rules, testing expectations, security boundaries, data contracts, and acceptance evidence needed for an AI coding system.
The intent file fills that gap.
A good intent file should include:
Business outcome.
System boundary.
Affected repos.
Affected APIs.
Affected UI screens.
Data model impact.
Security constraints.
Known patterns to follow.
Tools Claude may use.
Files Claude should avoid.
Validation commands.
Required evidence.
Human approval checkpoints.
That is the difference between asking Claude to “do a feature” and giving Claude a governed engineering mission.
Example: Weak Context vs Architected Context
Weak version:
“Update the customer profile page.”
Architected version:
“Update the customer profile page to display preferred contact method. Follow the existing React component pattern under /src/features/customer-profile. Add the field to the API response only if it already exists in the customer profile service contract. Do not modify authentication or account settings. Run frontend unit tests and API contract tests. Provide a summary of files changed, tests run, and any contract assumptions. Stop and ask for review if the backend field does not exist.”
That is not just a better prompt.
That is context architecture.
It gives Claude boundaries, source paths, permission limits, validation requirements, and stop conditions.
That is what a Claude Code Architect has to learn to do.
Exam Trap: More Context Is Not Always Better
One mistake is thinking that context management means dumping everything into Claude.
That is wrong.
Bad context can be just as harmful as missing context.
Too much context creates noise. Old context creates confusion. Conflicting context creates bad decisions. Untrusted context creates risk.
The architect has to decide what context is relevant, current, authoritative, and safe.
That means context should be curated.
For example:
Jira may define the business request.
Confluence may define architecture.
Figma may define UI behavior.
GitHub may define actual implementation reality.
Test output may define current truth.
Production logs may define operational behavior.
The architect’s job is to tell Claude which source wins when sources conflict.
That is a major enterprise skill.
The Practical Study Exercise
For article five, the practice assignment is simple.
Take one real feature and create a context map before asking Claude Code to implement anything.
Use this structure:
What is the intent?
What repo or repos are involved?
What files or folders matter?
What existing pattern should Claude follow?
What tools can Claude use?
What tools are off limits?
What commands should validate the work?
What evidence must Claude return?
What should cause Claude to stop?
What human decision is still required?
That exercise teaches the architect mindset.
You are not just prompting.
You are creating the operating environment for agentic delivery.
Final Thought
Claude Code is powerful, but Claude Code is not magic.
It needs structure.
It needs boundaries.
It needs context.
It needs validation.
It needs evidence.
That is why context management and reliability belong near the center of Claude Code Architect certification prep.
The future architect will not be the person who writes the fanciest prompt. It will be the person who can design a reliable system where AI agents understand the mission, operate within boundaries, use the right tools, validate their work, and produce evidence that humans and enterprises can trust.
That is Intent-Driven Engineering.
And that is the road to becoming a real Claude Code Architect.
:::
Comments