Explain unfamiliar code

Why this prompt works

• →Pitching the explanation at a named level stops the two default failures: condescending line-by-line narration, or a summary that assumes you already understand it.
• →Asking for assumptions and the likely break is what turns an explanation into understanding — it is the part you cannot get from reading the code slowly.
• →The no-guessing clause matters for snippets: models otherwise confidently describe what an unseen helper function "probably" does.

Part by part

explaining WHY at each step, not just what

The distinction between an explanation and a transcription. Restating what each line does is readable from the code; the reason it is there is not.

list any assumptions it makes about its inputs or environment

The section that transfers real understanding — what has to be true for this code to work, which is invisible until it stops being true.

the most likely way it breaks

Asks for the failure mode, which is what someone about to modify the code most needs to know.

do not invent behaviour for functions whose definitions you cannot see

Names the specific hallucination this task invites. A confident description of a helper it has never seen is indistinguishable from a real one.

Common mistakes

• What does this code do?

  Produces a line-by-line paraphrase, which you could get by reading it. The useful parts — why it is written this way and what it assumes — are not asked for and do not appear.

• Explain this code simply.

  Simply is achieved by omitting the parts that are hard, which are usually the parts worth explaining. Naming the reader's level gives a target that does not require cutting substance.

• Explain this code and suggest improvements.

  Combines understanding with critique, so the explanation is shaped by the suggestions. Understand it first; deciding whether to change it is a separate question.

Questions