Ask ChatGPT to Explain Code Before Changing It

You paste an unfamiliar function into ChatGPT and ask for a cleaner version. The reply looks better. It runs. You commit it. A week later a bug shows up because the original function handled a case you did not notice. The rewrite quietly dropped it.

The safer path is a two step exchange. First ask ChatGPT to explain what the code does. Then ask for the change. The explanation is a chance to catch behavior you did not realize was there. It also gives you a shared understanding that both you and ChatGPT can point back to during the rewrite.

What a good explanation looks like

A good explanation is short, plain, and structured. It lists inputs and outputs, describes the main path, and calls out edge cases. It notes any side effects. It does not offer opinions about style or improvements. Those come later in the change step, if they come at all.

When to explain before you change

• Any function longer than a screen or with several branches
• Code you did not write and cannot verify from memory
• Legacy code that has been in the project for years
• Code that touches money, dates, permissions, or user input
• Anything you plan to rewrite significantly rather than tweak

Prompt to explain a function first

Here is a function from our codebase.
Task: explain what it does in plain language.
Return four sections:
1. Inputs and outputs.
2. Main path in five bullets or fewer.
3. Edge cases and how they are handled.
4. Side effects, such as network calls, file writes, or shared state.
Do not suggest any changes yet.

Why this prompt works

The four sections give you a map. The last rule stops the reply from jumping ahead into a rewrite. You get a shared picture of the code before either of you starts changing it, which makes the next round far safer.

Prompt for the change after the explanation

Now, based on your explanation, propose a smaller version that keeps every listed edge case and side effect.
Return the new code plus a short note on which lines correspond to which edge cases from your earlier list.
Do not change any behavior. If a smaller version would drop an edge case, stop and tell me instead of doing it.

Prompt for a targeted explain and check

Here is a function and a bug report.
Task 1: explain what the function does.
Task 2: point out which parts of your explanation match or contradict the bug report.
Do not propose a fix yet.
If the report is unclear, list the missing details you would want to know first.

What to include in an explanation request

• The exact code block you want explained
• A structured format so the explanation is easy to compare against
• An explicit request for edge cases and side effects
• A ban on changes or opinions during the explanation step
• Any external context, such as related files or a bug report

How to refine the explanation

If a section reads vague, ask for a concrete example that exercises it. For example, please give me an input that would hit edge case two. Concrete examples surface mistaken assumptions faster than abstract debate about the code.

Common mistakes

• Skipping the explanation step to save one round
• Accepting a vague explanation that hides the tricky parts
• Letting the explanation drift into opinions about style
• Rewriting the code before you agree on what it does
• Not comparing the new version back to the original edge case list

How to check the rewrite

Read the change with the explanation in front of you. Every edge case and side effect from the explanation should still be visible somewhere in the new code. If any of them disappeared silently, that is the regression you were hoping to avoid. Ask again with a stricter rule and repair before you commit.

Takeaway

Explanation first, change second. That order costs one extra round and saves the bug you would have shipped otherwise.