Engineering

Explain Code Line by Line

Build a prompt that walks through a function line by line — what each line does and why — calibrated for a developer still learning the codebase.

Open in Code Explanation Prompt

Overview

Sometimes "what does this function do" is not enough — you need to follow it line by line. This builds a prompt that walks a function top to bottom, explaining what each line does and why it is there, in order, for a newer developer. The example loads a debounce utility. Open it in the Code Explanation Prompt and paste the function you are trying to follow; adjust the audience and depth to match how much you already know.

How to use this resource

Open the example in the tool

It loads with realistic inputs already filled in.
Swap in your own details

Adjust the inputs and options to match your case.
Generate and copy

Produce the output and paste it where you need it.

Why This Works

A line-by-line walkthrough is the right tool when an overview leaves you still lost
Audience calibration keeps it from over-explaining syntax or under-explaining the domain
Anchoring each explanation to a specific line keeps the model honest about what the code shows

Best for

Following an unfamiliar function in detail
Learning a new codebase line by line
Understanding tricky control flow

Not for

A high-level overview — switch the mode to overview
Reviewing the code for issues — use the Code Review Prompt Generator

FAQ

Will the line-by-line explanation flag bugs it notices along the way?

It won't diagnose or fix them. The NON-GOALS section bars code-quality findings, severities, and debugging outright; if something looks defective the walkthrough only "notes it as a question for the team." For actual issue-hunting, the resource points you to the Code Review Prompt Generator instead. The generated prompt runs in your assistant.

How does the prompt keep the AI from inventing why the code was written a certain way?

The ASSUMPTIONS section forces it to label any claim about intent, history, or rationale as an INFERENCE unless a comment, test, or telling name evidences it. Where behavior can't be read from the source, it must say "cannot be determined from this code" rather than fill the gap with a plausible story, keeping fact and guess separated throughout.

The example is a debounce function — can I explain my own code with it?

Yes. The debounce utility loads only as a filled-in example; step two of the workflow is swapping your own function in under CODE CONTEXT. You can also retune the AUDIENCE PROFILE away from junior developer and switch the depth to overview, since the prompt calibrates every section to whoever you say is reading.

Customize This Resource

Opens this setup in Code Explanation Prompt. Generate to get the full understanding contract — then adjust the mode, audience, and depth.

Open in Code Explanation Prompt

Prompt Template

Copy it as-is, or use Open in Code Explanation Prompt to load it pre-filled and customize it with your own context.

EXPLANATION OBJECTIVE
Walk through this function line by line, explaining what each line does and why.
Explanation mode: function walkthrough — inputs, outputs, execution flow, decisions, and side effects.
The goal is understanding, not judgment: explain what this code does and why it is built this way — and clearly separate what the code shows from what you infer.

CODE CONTEXT
System context: A small utility used across the front end to limit how often a handler runs.
Code to explain:
```
function debounce(fn, wait) {
  let t;
  return function (...args) {
    clearTimeout(t);
    t = setTimeout(() => fn.apply(this, args), wait);
  };
}
```

AUDIENCE PROFILE
Audience: a junior developer — fluent in basic syntax, still building a pattern vocabulary.
- Assume: basic language syntax is known; design patterns, idioms, and domain terms are not.
- Define every term of art on first use, in one sentence, in plain words.
- Prefer concrete examples over abstract descriptions — show a real value flowing through the code.

EXPLANATION STRATEGY
1. State the contract first: inputs with their expected shapes, outputs with their meaning, errors with their triggers.
2. Walk the execution flow in order, pausing at every decision point to explain both branches.
3. Surface every side effect — writes, calls to other systems, mutations of shared state — and when each happens.
4. Distinguish the happy path from the edge paths; name the conditions that route execution off the happy path.
- Depth: detailed explanation — thorough coverage of behavior and structure.
- Cover every section of this contract with real content — no skipped or token sections.
- Go as deep as the code requires, but no deeper: detail serves understanding, not completeness theater.

KEY CONCEPTS
- Explain each non-obvious variable, structure, and helper the walkthrough touches — what it holds and why it exists.
- Order concepts by how load-bearing they are for understanding this code — not by where they appear in the file.

EXECUTION FLOW
- Present the flow as a numbered sequence; at each branch, state the condition in plain language and what each outcome means.
- Where the flow depends on state or configuration, say which, and what each setting changes.

DESIGN DECISIONS
- Where the implementation makes a visible choice — an early return, a special case, a particular ordering — explain what the choice achieves.
- Discuss only decisions actually visible in the code; rationale you cannot evidence belongs under ASSUMPTIONS, labeled as inference.

ASSUMPTIONS
- Separate what the code DOES (verifiable from the source) from why it might be that way (inference).
- Label every statement about intent, history, or rationale as an INFERENCE unless the code itself evidences it — a comment, a test, a telling name.
- Where behavior cannot be determined from the provided code, say "cannot be determined from this code" — never fill the gap with a plausible story.

TRADEOFFS
- Identify the tradeoffs this code embodies: what it optimizes for, and what it sacrifices for that.
- Tie each tradeoff to its visible consequence in the code.

LEARNING NOTES
- End with the contract restated in two sentences: what you give it, what you get back, and what else changes.

NON-GOALS
- Do not review code quality — no findings, no severities, no verdicts.
- Do not debug failures — explain the behavior that exists without diagnosing it.
- Do not refactor the code or propose rewrites.
- Do not generate tests.
- Do not invent requirements or unstated intentions.
- If something looks defective, note it as a question for the team — investigating or fixing it is out of scope.
- Clearly separate facts from assumptions throughout.

OUTPUT REQUIREMENTS
- Structure the explanation with headings that mirror the sections above — a reader should be able to navigate it without reading all of it.
- Anchor every claim about behavior in the code: name the function, branch, or line it comes from when precision matters.
- Calibrate every section to the stated audience — too basic wastes their time, too advanced loses them.
- End with the open questions: what could not be determined from the provided code, and who or what could answer it.

More resources from Code Explanation Prompt

Resource

Explain Code Prompt — the Understanding Contract

"Explain this code" gets line-by-line narration. The understanding contract gets strategy, audience-fit, design decisions, and inference labeled as inference.

Prompt Engineering

Resource

Legacy Code Analysis — Likely Intent, Hidden Assumptions

For code whose authors are gone: reconstruct likely intent as labeled inference, hunt undocumented assumptions, and end with a maintenance brief — what's safe to touch.

Prompt Engineering

Resource

Algorithm Explanation Prompt — Idea, Steps, Complexity, Tradeoffs

Explain the idea before the implementation: numbered steps with their contribution, honest best/worst-case complexity, and the alternatives each decision point rejected.

Prompt Engineering

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Related tools

Tool

Code Explanation Prompt

Build code explanation prompts — mode, audience, and depth turn into an understanding contract that teaches, not narrates.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.