Explain It Like I Own It
For the builder who did not write the code
Partial · ChatGPT, Pro · September 27, 2026
What it does
Turns a file somebody handed you into something you could explain in a meeting: what it is for, what would break it, and what you would touch first.
When to use it
Before you take responsibility for anything an AI — or a contractor — made for you.
The prompt
Paste it, then fill in the <angle brackets>
CONTEXT
I did not write this file and I am about to be responsible
for it: <path>. I am good at my job but I am not an engineer.
Assume I can read code slowly.
RULES
- Do not change the file. Explain it.
- No technical word without a short plain meaning the first
time you use it.
- If the code alone does not tell you why something is there,
say so. Do not make up a reason.
DONE MEANS
- I can say in one sentence what this file is for.
- I know the three things most likely to break it.
- I know which part I would touch first for the change I am
most likely to be asked for.
LAY IT OUT LIKE THIS
- What it is for: one sentence
- What it reads, and what it writes: bullets
- The three ways it breaks: what goes in → what fails → where
I would notice
- If you had to change one thing: which, and why
- What you could not tell from the code aloneWays to use it
- Run it on every file in a change you did not write yourself
- Save the answer beside the file so the next person has it
- Ask a second AI and compare the two explanations
Test log
Each prompt was pasted into a fresh private chat with memory off and graded against pass standards written before the run (all of them, dated).
| Date | Tool | Model | Result | What happened |
|---|---|---|---|---|
| September 27, 2026 | ChatGPT | Pro | Partial | Explained purpose, inputs, three break cases and the unexplained 32 days without changing the file; the one-sentence purpose left out the Stripe signature check. |
The pass standard for this prompt: six criteria and an automatic-fail rule, written down on September 27, 2026, before any run.
Related words
- brownfield — Code that already exists and already works, which you now have to change without breaking it.
- rubber duck debugging — Explaining your problem out loud, line by line, to something that cannot answer, until you spot the mistake yourself.