explain-back

Explain Back

The failure mode this fixes

The most expensive bug in AI-assisted development isn't wrong code — it's code that looks right that nobody understands. The agent writes 80 lines, the human skims, says "looks good," and merges. Six weeks later it breaks and no one — human or agent — can say why it existed.

explain-back inverts review. Before code is trusted, the agent must explain it back in plain language until the human confirms the model is correct. If the agent can't explain a line, that line is suspect. If the human can't follow the explanation, the code is too clever. Either way, you find out now, not at 3am.

When to Use This Skill

• Right after you (the agent) generate a non-trivial change, before declaring it done
• When reviewing code an agent wrote and the diff "looks fine" but no one built a model of it
• When onboarding to an unfamiliar file before changing it
• When the human catches themselves about to approve something they can't explain
• Before building new logic on top of existing code whose behavior is assumed, not known

Don't use when: the change is a trivial rename, a config value, or a one-line typo fix. Reserve it for logic that someone will later have to reason about.

Instructions

Work through these phases in order. Do not skip to a fix or a "looks good" — the whole point is to surface the gap between what the code says and what everyone thinks it says.

1. Restate the intent (before reading the code closely)

State, in one sentence, what this code is supposed to do — from the requirement, the PR title, or the conversation. Do not look at the implementation yet. This is the contract you'll check the code against.

"This function is supposed to deduplicate incoming webhook events so we never process the same payment twice."

2. Explain it back, line group by line group

Walk the code in small chunks. For each chunk, say in plain language:

• What it does (the mechanic)
• Why it's there (the intent it serves)
• What breaks if it's wrong or removed