Ide Grounding And Review — Claude Code Guide

Terminal-first, IDE for transparency

It is useful to launch and control Claude Code through the terminal, while using the IDE to read code, provide precise context, and review changes. An open file by itself does not mean its contents were sent to Claude.

A high-quality agent response does not guarantee a high-quality change. The actual diff in the editor shows more reliably what changed.

• The terminal handles launch, commands, modes, and session state.
• The IDE shows the complete file, surrounding code, selections, and the range of changed lines.
• The developer accepts or rejects the result after checking it.

Grounding — tying the request to exact code

Grounding means tying a request to a specific file, method, selection, or line range. Explicitly name the work object, the boundaries of allowed changes, and the desired response format.

The more precisely the context is defined, the lower the chance of unnecessary changes in neighboring files or a vague explanation.

• A file path, for example support/TicketRow.tsx.
• A line range or selected method.
• Allowed and forbidden change boundaries.
• The expected result: an explanation, plan, diff, or list of edge cases.

Connecting to an IDE

You do not need to change your usual editor just for Claude Code. VS Code and JetBrains products — IntelliJ IDEA, WebStorm, PyCharm, or GoLand — are suitable.

1. In VS Code, open the project and its integrated terminal, then run claude.
2. Alternatively, install the official Claude Code extension from Anthropic through Extensions.
3. In JetBrains, run claude from the IDE terminal or install the official plugin through Settings/Preferences → Plugins.
4. Check that the IDE and CLI use the same environment, shell, and PATH.
5. For WSL, do not mix a Windows-native project with a CLI installed only inside WSL.

# In the IDE terminal
claude

First integration check

1. Open a project file in the IDE.
2. Select several lines containing a noticeable variable or method.
3. Open the Claude panel and ask it to explain exactly the selected fragment.
4. Check whether the response mentions the variable names and logic from the selection.
5. If the response is generic, check the plugin settings, version, and launch environment.

Requests with constraints

It is safer to ask for an assessment or plan first and allow editing only afterward. In the request, name the file, constraints, and evidence format.

Analyze the selected method and name possible edge cases.
Give a risk assessment first, without editing.

Make the smallest necessary change in payments/RefundService.java.
Do not change the method signature or other classes.
Show the result as a diff.

Reviewing the diff

• Count the changed files and compare them with the original scope.
• Make sure signatures and surrounding code were not changed without need.
• Check for unused imports, mass formatting, and violations of the project style.
• Run tests and check the behavior of the key scenario.
• If a change cannot be explained by the task, return to the plan and narrow the scope.

BigDecimal actualDiscount =
        discount == null ? BigDecimal.ZERO : discount;
return total.subtract(actualDiscount);