AI for Explanation, Debugging, and Test Design

Generating new features is only one use of an AI coding tool, and often it is the use with the largest review burden.

A smaller use can be more valuable: ask the tool to help you form a hypothesis, explain unfamiliar code, generate candidate cases, or challenge your current reasoning.

The key word remains candidate.

Explanation can expose what you do not understand

Suppose you inherit:

def summarize(records):
    return {
        key: sum(1 for record in records if record.get("status") == key)
        for key in {record.get("status") for record in records}
    }

You could ask:

Explain this function line by line.
What Python concepts does it use?
What happens if a record has no status key?
Rewrite the explanation without changing the code.

Then verify the explanation yourself by running tiny examples:

print(summarize([]))
print(summarize([{"status": "ok"}]))
print(summarize([{}]))

The generated explanation helps create a mental model. Execution tells you whether the model matches the code.

Debugging assistance should begin from evidence

Weak debugging request:

My code doesn't work. Fix it.

Evidence-rich request:

Expected: load_fixture() returns a list of task dictionaries.
Observed: KeyError: 'completed' in analyze_todos line 18.
Here is the smallest fixture that reproduces it: ...
Here is analyze_todos(): ...
Give three plausible causes ranked by what evidence would distinguish them.
Do not rewrite the function yet.

That prompt keeps you inside the diagnostic loop.

A useful response might suggest hypotheses such as:

H1: one record lacks completed
H2: decoded data is not a list of task dictionaries
H3: wrong fixture file was loaded

Now test them.

Do not jump straight from AI hypothesis to code change.

Beware of error suppression disguised as a fix

Suppose the program fails on:

status = record["status"]

A candidate “fix” might be:

try:
    status = record["status"]
except Exception:
    pass

The traceback disappeared.

The program may now continue with missing or stale state and no explanation.

That is not automatically a repair. It may have destroyed the evidence.

Ask instead:

Is status required or optional?
What should happen when it is missing?
Where should validation occur?
What test captures that contract?

AI can propose test cases, not decide the contract

Given:

def calculate_discount(total, percent):
    ...

You can ask for candidate cases:

List useful normal, boundary, invalid, and empty/zero cases for this function.
Do not write implementation code.
Explain why each case matters.

Then compare the proposed cases with the real requirements.

The tool might suggest negative percentages even though your application validates them earlier. That could be useful, irrelevant, or a clue that the function contract is unclear.

Your job is classification.

Ask the tool to attack your assumptions

A high-value review prompt is not always “write more code.”

Try:

Here is the requirement and this implementation.
Find ways the implementation could satisfy my current tests while still violating the requirement.
Do not modify the code.

That turns the AI into a candidate adversarial reviewer.

You still verify its claims, but the direction is different: instead of generating functionality, it searches for gaps in your evidence.

Compare two candidate explanations

Suppose a list unexpectedly changes after a function call.

Candidate explanation A:

Python copied the list incorrectly.

Candidate explanation B:

The function received a reference to the same mutable list object and modified it in place.

Do not pick B merely because it sounds more technical.

Test object identity/state:

items = [1, 2]
print(id(items))
modify(items)
print(id(items))
print(items)

Use what you learned in Unit 8 about mutation and references.

AI assistance works best when it reconnects you to evidence you can inspect.

Privacy-safe debugging

Before sending an error or code sample:

• replace real names with synthetic values;
• remove credentials/tokens;
• reduce large private files to a minimal fixture;
• share the smallest function that reproduces the issue; and
• avoid entire-repository context when the failure is local.

This often improves the technical question anyway.

Build a hypothesis table

For one bug, use this format:

An AI tool may help generate candidate rows. You decide them using evidence.

When not to use AI

Do not add another layer merely because it is available.

A five-line traceback that clearly says NameError: name 'scroe' is not defined does not require an AI debugging session. Read the error and inspect the spelling.

A tool is useful when it reduces uncertainty or effort without adding more uncertainty than it removes.

Unit skill

By the end of this lesson, you should be able to use AI in three bounded roles:

EXPLAINER      -> candidate mental model
DIAGNOSTIC AID -> candidate hypotheses
TEST REVIEWER  -> candidate cases / evidence gaps

None of those roles owns the final decision.