Code Defense

A polished demo answers:

Can the project show something impressive for a few minutes?

A Code Defense answers a harder question:

Do you understand and own the system well enough to explain behavior, evidence, architecture, and limitations when the inspection path is not rehearsed?

Ownership does not mean typing every character

You may have used:

• Python's standard library;
• third-party packages;
• documentation;
• starter code;
• classmates/mentors within course rules;
• AI assistance; or
• a coding agent.

Software development always builds on other work.

Ownership means the code you accepted into your project is explainable and maintainable by you at the level the project requires.

If you cannot explain a generated helper, the answer is not:

AI wrote it.

The answer is to study it, simplify it, replace it, or remove it before claiming the project is ready.

The defense can be live, recorded, or self-audited

This is a self-paced course. A live instructor cannot be a hidden prerequisite.

Use one of three modes.

Live defense

A teacher, mentor, or peer chooses prompts and asks follow-up questions.

Recorded defense

Record a short screen/code walkthrough. Use the prompt deck below and select prompts using a reproducible random method, such as drawing numbers or using Python's random module before recording.

Do not cherry-pick only the easiest prompts.

Self-audited defense

Answer the same prompts in writing. Link every answer to source, test, Git, runtime, or architecture evidence.

The evidence standard is the same across all three.

Build the defense prompt deck

Number these prompts:

1. Trace one user input from entry to final output/storage.
2. Explain one function selected from a core module.
3. Explain one class or data structure decision.
4. Show which test proves a required boundary behavior.
5. Explain one failing test or traceback you repaired.
6. Interpret one selected Git commit/diff.
7. Identify one dependency and justify why it remains.
8. Explain one controlled failure and recovery behavior.
9. Identify one known limitation and where it is documented.
10. Show one place where architecture could be simpler and defend the current choice.
11. If AI/agent work exists, explain one rejected or revised candidate.
12. Identify a requirement your test suite does not prove as strongly as you would like.

Select at least five prompts, including one from source/architecture, one from tests, and one from history/failure/limitations.

Trace data, not just files

If the prompt asks about input flow, do not answer:

main.py calls storage.py.

Trace the value:

user enters "Nova"
        ↓
main() receives str
        ↓
create_task validates/normalizes
        ↓
Task object/dict created
        ↓
collection updated
        ↓
save_tasks serializes fields
        ↓
JSON file contains ...

That demonstrates understanding across boundaries.

Defend a test by its claim

Weak:

This test checks saving.

Strong:

The requirement says an empty task list must serialize as an empty JSON array.
This test creates an empty list, saves to a temporary path, reloads/inspects the file,
and asserts the result is []. It protects the exact empty-state contract.

Then identify what it does not prove, such as behavior when the destination directory is unwritable.

Defend a Git commit as a decision

Pick a commit:

fix exact low-battery threshold

Explain:

Observed: battery 20 classified as normal.
Requirement: <=20 is low.
Evidence: new boundary test failed at 20.
Change: < became <=.
Retest: boundary + suite passed.

That commit tells a technical story.

A limitation is not an apology

Every system has a boundary.

Useful limitation:

The application assumes one process writes the JSON file at a time.
Concurrent writers are out of scope and could overwrite each other's state.

Weak answer:

It is perfect for what I need.

A developer who can name limitations is easier to trust than one who claims there are none.

AI/agent defense is about decisions

If AI contributed, do not spend the defense describing the brand or praising the tool.

Use engineering evidence:

TASK BOUNDARY
CANDIDATE
DIFF / TEST RESULT
REJECTION OR REVISION
FINAL ACCEPTED BEHAVIOR

If no AI was used, skip the AI-specific prompt. There is no penalty for completing a Python course with Python rather than an AI tool.

Score your own defense

Use a simple rubric for each selected prompt:

0  cannot explain / unsupported claim
1  partial explanation, weak evidence
2  accurate explanation with linked evidence
3  accurate explanation + limitation/tradeoff/failure reasoning

Five prompts produce a maximum of 15 points for the rehearsal.

A low score is not a final grade. It tells you where to review before the capstone verification.

The random-entry test

Open the repository at a file you did not plan to present.

Ask:

What responsibility does this file have?
Who calls it?
What does it depend on?
Which behavior would fail if I removed it?
Where is that behavior tested?

If you cannot answer, investigate.

That is the heart of Code Defense: the project should survive inspection from more than one rehearsed path.