Skip to content
WANCODE
BM

Asking AI to Explain Code

15 minIntermediateHTML · CSS · JS

In this lesson

  • Ask for explanations that are specific enough to check
  • Turn each claim in an explanation into a quick experiment
  • Fix code — and comments — when the evidence disagrees with the explanation

The big idea

An explanation is a set of claims. Each claim ("returns 0 for an empty array") is a tiny experiment you can run in seconds. Run them before you believe them.

Asking an assistant to explain code is one of the best ways to learn a codebase quickly. It's also risky in a quiet way: a wrong explanation doesn't crash anything. It just plants a wrong belief that you'll build on later.

Ask for checkable explanations

Markdown
Explain what average() and isWeekend() in script.js do.
- Go line by line and say what each line does.
- What do they return for normal input, for an empty array,
  and for a Sunday?
- List any assumptions (types, ranges, time zones).
- If you're not sure how a built-in behaves, say so.

Asking about edge cases and assumptions turns a vague summary into claims you can test.

Then verify each claim

  1. Predict, then run. Write down what you expect, then console.log the real result. A mismatch is information.
  2. Try the edges. Empty arrays, zero, negative numbers, very long strings, Sunday, midnight.
  3. Check claims about built-ins in real documentation such as MDN. "getDay() returns 1–7" is the kind of fact that sounds right and isn't.
  4. Explain it back. If you can't restate a line in your own words, you haven't verified it yet.

What the assistant said

Text
average([]) safely returns 0.
Results are rounded to 2 decimal places.

What running it showed

JavaScript
console.log(average([]));      // NaN
console.log(average([1, 2, 2])); // 2  (not 1.67)

Two lines of console.log disprove two claims. The explanation described what the code was meant to do, not what it does.

Explanations often describe the code's intent — its name, its comments — rather than its behaviour. When intent and behaviour disagree, you've found either a bug or a misleading comment. Both need fixing.

Don't change the functions yet. Use console.log to find out what the original code really does, and fill in the observed object in script.js:

- averageOfScores — the value of average(scores) - averageOfEmpty — the value of average([]) - sundayGetDay — the value of new Date(2026, 9, 18).getDay()

Type the values you saw (numbers, or NaN), not the expressions.

Checks

  • Recorded the real average of scores
  • Recorded what happens with an empty array
  • Recorded getDay() for a Sunday

Check understanding

Q1

An assistant explains: "This function returns an empty string for null input." What's the fastest way to know if that's true?

Q2

Why do explanations often match the comments and function names rather than the actual behaviour?

What you learned

  • Ask for explanations that cover edge cases and assumptions — they become checkable claims.
  • Verify each claim: predict, run, compare. Check built-in behaviour in real docs.
  • When explanation and behaviour disagree, fix the code or the comment — never leave a lie behind.
Preview

Console output from your code appears here.

Step 1 of 3