Code explanation

Claude in VS Code: Pair Programming

Chapter 2  ·  Code Explanation — Understanding Code You Didn't Write

One of the most immediately useful things Claude can do inside VS Code is explain code — a function you inherited, a library you've never used, a codebase you've just joined. This chapter covers how to ask for explanations at the right level of detail, how to use Claude to onboard onto an unfamiliar project quickly, and which questions actually produce useful answers versus which ones waste your time.

Why Explanation in the Editor Is Different

Asking Claude to explain code in VS Code is fundamentally different from pasting code into a browser chat. In the editor, Claude already has the file open — and can reach out to read other files in the project when the explanation requires it. You don't have to copy anything; you don't have to provide imports or class definitions separately; Claude can follow a function call into the file that defines it.

This changes the questions you can ask. "What does this function do?" is fine. But so is "What calls this function, and does anything depend on the value it returns?" — a question that requires reading multiple files, which Claude can do automatically.

Levels of Explanation

The right explanation depends on what you already know and what you're trying to decide. Match the prompt to the level:

Overview
What does this file/module/class do?
A paragraph-level summary. Use when you're orienting — skimming a codebase to understand its structure before reading any code in detail. Ask: "Give me a one-paragraph summary of what this file does and why it exists."
Function
What does this function do, and how?
Detailed explanation of logic, parameters, return values, and side effects. Use when you need to understand a specific piece of behaviour before modifying it. Ask: "Explain what this function does step by step, including what each parameter controls."
Line
What does this specific line / pattern do?
For unfamiliar syntax, idioms, or patterns you don't recognise. Select the exact text and ask. Ask: "What does this line do and why is it written this way?"

Prompt Patterns That Work Well

File overview
Give me a one-paragraph summary of what this file does and where it fits in the project.
Best sent from the chat panel with the file open — Claude reads it automatically.
Function walkthrough
Walk me through this function step by step. What does each section do, and what does it return?
Select the function first, then right-click → Explain with Claude, or paste into chat.
Dependency trace
What calls this function? Does anything in the project depend on the value it returns?
Claude reads across files to answer this. More accurate than a manual grep.
Data flow
Trace what happens to the `user` object from when it enters this function to when it leaves. What gets modified?
Especially useful for understanding side effects and mutation.
Unfamiliar pattern
I don't recognise this pattern. What is it, why would someone use it, and are there any gotchas?
Select the pattern before asking. Works great for decorators, metaclasses, generator expressions, async patterns.
Intent vs implementation
What was this code trying to achieve? Is the implementation a straightforward way to achieve it, or is there something unusual going on?
Surfaces hidden complexity and workarounds that aren't obvious from reading the code.

Before and After: Vague vs Specific

The specificity of your question directly determines the usefulness of the answer. These examples show the same request — one vague, one specific:

Less useful
Explain this code.
More useful
Explain what this function does when the `retries` parameter is 0. Does it still attempt the request, or does it return immediately?
Less useful
What does this file do?
More useful
What does this file do, and what would break if it were removed? I'm trying to decide if it's safe to refactor.
Less useful
I don't understand this.
More useful
I don't understand why this uses a closure here instead of passing the value as a parameter. What does the closure buy us?

The pattern: replace "explain this" with a specific question about behaviour, edge cases, or intent. You'll get a targeted answer instead of a generic walkthrough.

Onboarding onto an Unfamiliar Codebase

When you're new to a project — joining a team, picking up someone else's code, or returning to your own code after six months — Claude can dramatically compress the time it takes to get oriented. Here's a sequence that works well:

Start at the entry point. Open the main file (e.g. main.py, index.ts, App.jsx) and ask: "What is the entry point of this application and what does it set up?" Claude explains the bootstrapping sequence.
Map the major components. Ask: "What are the main modules or directories in this project and what does each one do?" Claude reads the file tree and summarises the structure.
Trace a request end to end. Ask: "Walk me through what happens when a user logs in — from the HTTP request to the response." Claude follows the code path across files.
Find the data layer. Ask: "Where is the database accessed? What ORM or query pattern is used?" Gets you to the data layer quickly without reading every file.
Identify non-obvious conventions. Ask: "Is there anything unusual or non-standard in how this codebase is structured that I should know about?" Surfaces patterns that would confuse you if you discovered them mid-task.
Locate your task area. Ask: "I need to add [feature]. Which files would I most likely need to touch?" Claude uses its codebase understanding to point you to the right area.
Let Claude read the whole project first
Before starting an onboarding sequence, ask Claude: "Take a look at the project structure and let me know when you have a feel for what's here." This gives Claude a chance to read key files before you start asking specific questions — the answers will be more accurate.

Asking About Third-Party Code

Claude is also useful for explaining library and framework code — not just code you wrote. If you're using a library you don't fully understand:

  • Paste a usage example from the library and ask what each argument does
  • Ask: "What does this middleware actually do under the hood?" — Claude draws on its training knowledge of common libraries
  • Ask: "Are there any gotchas with using this pattern in production?" — surfaces known pitfalls
  • Ask: "What's the difference between [method A] and [method B] in this library?" — faster than reading docs
Verify library knowledge against docs
Claude's knowledge of libraries has a training cutoff. For libraries that release frequently (React, Next.js, FastAPI, etc.), Claude may describe an older API. Always cross-check against the current documentation when an API detail matters — especially for breaking changes.

When Explanation Falls Short

SituationWhat happensWhat to do instead
Highly domain-specific logic Claude explains the code structure correctly but misses business intent (e.g. tax calculation rules, medical protocols) Provide context: "This is a VAT calculation for EU digital goods — explain with that in mind."
Generated or minified code Claude can explain it but the explanation is rarely useful — the code isn't meant to be read Ask Claude to rewrite it as readable code first, then explain the rewrite
Macro-level architecture Claude can describe files and directories but can't draw architectural diagrams without help Ask Claude to produce a plain-text description of the architecture, then turn that into a diagram yourself
Runtime behaviour Claude reads static code — it can't tell you what actually happened at runtime (memory usage, actual values, timing) Use the debugger for runtime questions; use Claude for static analysis questions
Next — Chapter 3: Refactoring
Asking Claude to improve, rename, and restructure existing code. How to scope a refactor so Claude doesn't change more than you intended, how to handle multi-file refactors, and how to use the diff view to stay in control of every change.