A Developer’s Guide to Claude Code in the IDE

A Developer’s Guide to Claude Code in the IDE

Let Intent Lead. Let Claude Determine the Path.

Most developers using Claude Code are not building an agentic system from scratch.

They are not manually inspecting stop_reason.

They are not writing an execution loop.

They are not creating a coordinator, spawning subagents, wiring tool results back into the conversation, or controlling every internal step.

They are working inside Visual Studio Code.

They open a repository, describe what needs to change, allow Claude to inspect the codebase, review the proposed direction, and guide the work toward a completed implementation.

That is a different operating model.

In this environment, Claude Code already provides the agentic harness. The developer does not need to reproduce the harness inside every request.

The developer’s responsibility is to provide something more important:

Clear intent.

The intent file becomes the primary work order. It defines the desired outcome, establishes boundaries, identifies acceptance criteria, and tells Claude where its authority ends.

Claude determines the most appropriate path inside those boundaries.

That is the practical foundation of intent-driven development with Claude Code.

Claude Code Is Already Running the Loop

When developers first learn agentic architecture, they often encounter the underlying execution loop:

1. Send Claude a request.

2. Receive a response.

3. Inspect whether Claude requested a tool.

4. Execute that tool.

5. return the result.

6. Continue until the work is complete.

That loop matters when engineers are building their own applications with the Claude API or Agent SDK.

But that is not normally the layer a developer is working at inside Visual Studio Code.

Claude Code already manages the interaction between the model and its development tools. It can inspect files, search the repository, edit code, run commands, analyze test failures, and continue working through the task.

The developer does not need to place low-level execution instructions into the intent file.

An intent file should not say:

Check the stopping reason after every response.

Use Grep first.

Then invoke Read.

Spawn an exploration subagent.

Run a testing skill.

Stop after six iterations.

Those instructions attempt to control the machinery rather than the outcome.

Inside the IDE, the better model is:

The intent file defines the work. Claude Code manages the execution. The developer supervises the result.

The Intent File Is Not a Prompt With More Words

An intent file should not simply be a large prompt.

It should be a governed engineering artifact.

A prompt often asks Claude to perform an action:

Add validation to the customer registration endpoint.

An intent file explains why the change is needed, what must be true when the work is complete, what areas are permitted to change, and what risks or constraints must be respected.

For example:

# Intent: Strengthen Customer Registration Validation

## Business purpose

Prevent invalid or incomplete customer registrations from entering downstream account-processing workflows.

## Desired outcome

Add validation for required identity, contact, and account fields before the registration request reaches the persistence layer.

## In scope

- Registration API validation

- Shared validation utilities

- Unit and integration tests

- Error-response mapping

## Out of scope

- Authentication redesign

- Database schema changes

- Changes to external API contracts

- Infrastructure changes

## Acceptance criteria

- Missing required fields return the approved validation response.

- Invalid email and phone formats are rejected.

- Existing valid registrations continue to succeed.

- All affected tests pass.

- New edge cases are covered by automated tests.

## Constraints

- Preserve backward compatibility.

- Do not introduce a new validation framework.

- Follow existing repository patterns.

- Stop and request guidance if the current API contract cannot support the required behavior.

## Completion evidence

Provide:

- Files changed

- Tests added or modified

- Commands executed

- Test results

- Assumptions

- Remaining risks

This does not tell Claude how to perform every step.

It tells Claude what success means.

That is the difference between instruction and intent.

Give Claude Freedom Inside a Defined Solution Space

The strongest use of Claude Code is not unrestricted autonomy.

It is bounded autonomy.

Developers should allow Claude to determine how to investigate and implement a change when the repository, architecture, and task permit more than one reasonable path.

At the same time, developers must define the boundaries of the solution space.

A useful intent file answers six questions.

Why are we doing this?

Claude should understand the business or engineering purpose behind the change.

Without purpose, Claude may produce a technically correct implementation that solves the wrong problem.

What outcome is required?

The desired result should be observable and testable.

Avoid vague objectives such as:

Improve the service.

Prefer:

Prevent duplicate event delivery from creating duplicate financial transactions.

What is in scope?

Claude should know which areas of the repository may be changed.

This reduces unnecessary exploration and protects unrelated systems.

What is out of scope?

Explicit exclusions are often as valuable as requirements.

They prevent the task from expanding into architecture redesign, framework replacement, or infrastructure work that was never authorized.

What constraints must remain true?

Constraints define the non-negotiable conditions surrounding the implementation.

Examples include:

• Maintain backward compatibility.

• Preserve the current API contract.

• Do not modify authentication.

• Do not introduce another dependency.

• Follow existing data-ownership boundaries.

• Do not execute destructive commands.

What proves the work is complete?

Claude needs a concrete definition of done.

That normally includes tests, validation evidence, changed files, unresolved risks, and confirmation that acceptance criteria were met.

When these six areas are clear, Claude has enough freedom to reason without receiving unlimited authority.

Do Not Turn the Intent File Into a Procedure Manual

One of the easiest mistakes is to over-specify the implementation process.

A developer may write:

Search the repository using Grep.

Read the controller.

Inspect the service.

Create three files.

Use a subagent to inspect tests.

Invoke the security-review skill.

Run these four commands.

Modify the handler using this exact pattern.

This may appear controlled, but it has several disadvantages.

First, it assumes the developer already knows the best route through the repository.

Second, it prevents Claude from adapting when the actual architecture differs from the developer’s assumptions.

Third, it makes the intent fragile. A file move, naming change, or architectural improvement may invalidate the entire sequence.

Fourth, it turns Claude into an expensive script runner.

The intent file should normally specify the destination, boundaries, and proof—not every turn in the road.

There are exceptions.

A procedural instruction is appropriate when:

• A regulated workflow requires a fixed order.

• A known migration runbook must be followed exactly.

• A production operation has mandatory steps.

• A specific tool or command is required by policy.

• The implementation must conform to an approved technical decision.

• The developer is intentionally reproducing a known procedure.

In those cases, deterministic procedure is part of the requirement.

But it should be introduced because the work demands it, not because Claude happens to support tools, skills, and subagents.

Do Not Explicitly Call Skills Unless There Is a Reason

Skills can be valuable.

They can package repeatable workflows, repository reviews, test analysis, security checks, release preparation, and architectural assessments.

But developers should not feel required to name a skill in every intent file.

An instruction such as:

Use the test-analysis skill.

is useful only when that skill represents a specific workflow that the developer wants executed.

It may be appropriate when:

• The team has standardized the workflow.

• The skill produces a required artifact.

• The skill enforces a repeatable review method.

• The task is known to benefit from isolated execution.

• The same procedure is used across many repositories.

• The skill is part of the team’s definition of done.

It is unnecessary when the intent is already clear and Claude can determine the appropriate repository tools and development steps.

The same principle applies to subagents.

Do not require a subagent merely because subagents are architecturally interesting.

Use one when there is a reason to isolate, specialize, parallelize, or independently review work.

Examples include:

• Exploring a large unfamiliar subsystem

• Tracing a transaction across several services

• Conducting an independent code review

• Comparing multiple architectural approaches

• Isolating verbose research from the main session

• Assigning work to an agent with restricted tools

In other situations, explicit subagent instructions may add overhead without improving the result.

The rule is simple:

Use architectural components to solve architectural problems—not to decorate the intent file.

The Repository Should Carry the Permanent Rules

The intent file should not repeat every engineering standard on every feature.

Permanent rules belong in the repository operating model.

That may include:

• CLAUDE.md

• .claude/rules/

• Existing project documentation

• Coding standards

• Testing conventions

• Security requirements

• CI policies

• Branch protections

• Pull-request templates

• Tool permissions

• MCP configurations

These artifacts define how Claude should behave across many tasks.

The intent file then defines what is unique about the current task.

This separation matters.

Without it, every intent file becomes bloated with repeated instructions.

Developers begin copying large sections from one feature to another, increasing context usage and creating inconsistent versions of the same rules.

A cleaner model is:

Repository instructions:

How work is normally performed here

Intent file:

What this specific change must accomplish

Claude Code:

How the work is explored and implemented

Developer:

Whether the proposed approach and final result are acceptable

The repository carries the stable operating model.

The intent carries the change-specific direction.

Plan Mode Is a Developer Control, Not an Intent Requirement

Developers do not need to place “use plan mode” inside every intent file.

Plan mode is a supervision decision.

It is useful when the task involves:

• Multiple files

• Architectural decisions

• Significant refactoring

• Unfamiliar code

• Several valid approaches

• Cross-service dependencies

• Schema or API implications

• High rework risk

For a narrow, well-understood change, direct execution may be entirely appropriate.

For a complex feature, a developer may begin by giving Claude the intent and asking for a concise plan before allowing edits.

A practical workflow is:

Step 1: Present the intent

Give Claude the business objective, boundaries, constraints, acceptance criteria, and completion evidence.

Step 2: Ask Claude to investigate

Allow Claude to inspect only what is needed to understand the task.

Step 3: Review the proposed plan

Confirm that the approach respects scope and architecture.

Step 4: Authorize implementation

Allow Claude to make the agreed changes.

Step 5: Require validation

Claude should run the relevant tests and report the evidence.

Step 6: Review independently when warranted

For important changes, use a fresh review pass or separate context rather than relying entirely on the same session that produced the implementation.

This process gives the developer control without micromanaging every tool call.

Cost Is Controlled by Boundaries, Not by Eliminating Reasoning

Allowing Claude to determine its own implementation path does not automatically make the work expensive.

Poorly bounded work makes it expensive.

Claude becomes costly when it must repeatedly discover what the developer could have defined upfront.

Common cost drivers include:

• Vague objectives

• Unlimited repository exploration

• Huge intent files

• Repeatedly loading irrelevant context

• Long sessions containing unrelated work

• Multiple overlapping subagents

• Broad skills invoked automatically

• Repeated test runs without targeted feedback

• Unclear completion criteria

• Rework caused by missing architectural constraints

The answer is not to prescribe every action.

The answer is to reduce uncertainty.

Compare these two requests.

Unbounded request

Review this repository and make the customer workflow better.

Claude must determine what “better” means, which workflow matters, what changes are permitted, and how success should be measured.

Bounded intent

Reduce duplicate customer creation in the registration workflow. Limit changes to the registration API and matching service. Preserve the public contract and database schema. Add tests for repeated requests using the same verified email. Do not modify authentication or infrastructure.

The second request gives Claude substantial freedom while sharply reducing the search space.

That is the economic advantage of intent.

A strong intent file does not eliminate reasoning.

It prevents wasted reasoning.

Developers Still Control the Work

Claude Code may manage the internal agentic loop, but the developer remains accountable.

Developer control takes several forms.

Approve the direction

Before major edits, confirm that Claude understands the architecture and has chosen a reasonable approach.

Restrict authority

Do not grant destructive command access, infrastructure changes, production operations, secret handling, or broad repository modifications without a reason.

Watch for scope drift

Claude may discover adjacent issues while working. Those discoveries may be useful, but they should not silently expand the current task.

A good intent file should tell Claude to report out-of-scope findings rather than automatically fixing them.

Interrupt poor exploration

When Claude begins inspecting irrelevant areas, the developer should redirect it.

Autonomy does not mean passivity.

Separate generation from review

The same session that produced a solution may be less effective at challenging its own assumptions.

For meaningful changes, a fresh review context can examine the diff, tests, and intent independently.

Require evidence

The final response should do more than say the work is complete.

It should show:

• What changed

• Why it changed

• What tests ran

• What passed

• What failed

• What could not be validated

• What risks remain

The developer controls the work by controlling authorization, boundaries, and acceptance.

Business Stop Conditions Belong in the Intent

An intent file should contain stopping conditions.

But they should be engineering stopping conditions—not internal protocol instructions.

Do not write:

Continue until the stop reason equals end_turn.

That belongs to the Claude Code harness.

Instead, write:

## Completion conditions

The task is complete when:

- Every acceptance criterion has been addressed.

- Relevant unit and integration tests pass.

- Existing public behavior remains compatible.

- No unresolved TODOs remain in the changed code.

- The final response identifies modified files and test results.

- Assumptions and residual risks are documented.

Stop and request guidance when:

- The implementation requires an out-of-scope change.

- Acceptance criteria conflict with the current architecture.

- A destructive operation appears necessary.

- Security, authentication, infrastructure, or data ownership must change.

- Required information is unavailable.

These conditions define when Claude should finish, when it should pause, and when human judgment is required.

That is the correct use of stopping logic inside an intent file.

A Recommended Intent Structure for Developers

A reusable intent file can follow this structure:

# Intent: [Feature or Change Name]

## Business purpose

Why this work matters.

## Desired outcome

What must be observably true when the work is complete.

## Current context

Relevant repository, architecture, workflow, and business information.

## In scope

Files, components, services, or behavior that may change.

## Out of scope

Areas Claude must not modify.

## Acceptance criteria

Specific, testable requirements.

## Architectural constraints

Rules that the implementation must preserve.

## Quality requirements

Testing, performance, security, observability, and documentation expectations.

## Execution autonomy

Claude may determine the appropriate investigation and implementation approach within the stated scope and repository rules.

Claude may use available development tools, planning capabilities, isolated analysis, or approved reusable workflows when they materially improve the result.

Do not introduce unnecessary orchestration, agents, tools, or dependencies.

## Escalation conditions

Situations requiring developer review before continuing.

## Completion evidence

Files changed, tests executed, results, assumptions, and remaining risks.

The wording under execution autonomy is important.

It gives Claude permission to choose an appropriate method.

It does not force Claude to use a skill, subagent, or particular tool.

It also makes clear that unnecessary complexity should not be introduced.

The Balanced Developer Model

There are two extremes developers should avoid.

Extreme One: Unlimited autonomy

Here is the repository. Fix whatever you think is wrong.

This provides inadequate direction, weak governance, unpredictable scope, and potentially high cost.

Extreme Two: Total procedural control

Use these tools in this exact order, modify these exact lines, spawn these agents, and perform these exact internal steps.

This prevents adaptation and reduces Claude to a rigid workflow executor.

The more productive position is between the two:

The developer defines purpose, boundaries, constraints, evidence, and authority. Claude determines the implementation path inside those limits.

That is controlled autonomy.

It is neither uncontrolled agent behavior nor traditional step-by-step automation.

It is a development operating model designed around intent.

The Practical Architecture

The architecture for Claude Code in the integrated development environment is straightforward:

BUSINESS OR ENGINEERING NEED

              ↓

          INTENT FILE

Purpose, outcome, scope, constraints,

acceptance criteria, evidence, authority

              ↓

         CLAUDE CODE

Explores, plans, selects tools,

edits, tests, and iterates

              ↓

     REPOSITORY OPERATING MODEL

CLAUDE.md, rules, standards,

permissions, CI, and protections

              ↓

          DEVELOPER

Approves direction, controls authority,

reviews evidence, and accepts the result

The agentic loop is inside Claude Code.

The implementation strategy is selected by Claude.

The permanent standards live in the repository.

The current work is governed by the intent file.

The final accountability remains with the developer.

Final Thought

Developers do not need to become low-level agent orchestrators to use Claude Code effectively inside Visual Studio Code.

They need to become strong authors and reviewers of intent.

The intent file should not attempt to control every tool call.

It should not require skills or subagents merely because those mechanisms exist.

It should not recreate the underlying agentic loop.

It should clearly define:

• Why the work matters

• What must be accomplished

• What Claude is allowed to change

• What must remain protected

• What evidence proves completion

• When Claude must stop and ask for help

Claude should have freedom where reasoning adds value.

The repository should enforce permanent engineering expectations.

Deterministic controls should protect the rules that cannot fail.

The developer should remain in charge of direction, authority, and acceptance.

That is the developer’s guide to Claude Code in the IDE:

Intent defines the destination. Guardrails define the road. Claude determines the route. The developer decides whether the result is ready to ship.