Recap and Feedback
In this part, your study log was reorganized into a set of named, specified, tested functions. The behavior of the program did not change. The way it reads, the way it scales, and the confidence you have in any particular piece of it did change — quite a lot.
This part introduced five big ideas. Functions are the most visible: defining them, calling them, passing arguments, returning values. Testing is the second: small assert-based checks that connect directly to the edge-case checklist from the previous part. Scope is the third — the rule that gives every function call its own clean slate, and that you should resist working around with globals. Exceptions and input validation are the fourth — the mechanism your functions use to signal that something has gone wrong, and the try/except mechanism that lets you recover when something does. Refactoring is the fifth — the activity of changing how code is organized without changing what it does.
The AI thread continued from reading and verifying into specifying. With those three skills in place, the AI relationship has shape. You decide what you want by writing a specification. You ask for it precisely. You verify the result against the specification, not against itself. The act of writing the spec is the act of making the decisions that the AI will follow. The act of verifying the result is the act of checking that the AI followed those decisions.
If this part has gone well, your study log should now feel like a small system rather than a one-off script. The functions are named in ways that say what they do. The tests can be run quickly when you make a change. The specs in your docstrings tell anyone reading the code — including you, later on — what each function is supposed to do. And the program does not crash when the user types something unexpected.
Recap Quiz
The recap quiz below is a short sequence of questions drawn from the main ideas of this part. Complete it before the feedback form.
Feedback
Next, please take a moment to reflect on your work in this part and provide feedback. Your input helps us improve the course materials.
A few questions worth thinking about as you reflect:
- Which chapter felt most straightforward?
- Which chapter still feels uncertain?
- Which scope confusion or function-related bug took you the longest to debug?
- How does the refactored study log feel compared to the version from the last part? Easier to read, harder to read, about the same?
- Did the spec-writing exercise change how you would prompt an AI? If so, how?
Reflection and feedback
0 / 5 points
Consider the following statements and answer them based on your experiences from studying the materials and working on the assignments in this part. When answering the numeric statements, answer them so that value 1 means that you strongly disagree with the statement, and value 7 means that you strongly agree with the statement. Please be as honest as possible when answering. The feedback will be used to improve the course.
Looking Ahead
In the next part, the study log moves out of the sandbox and onto your own machine. With files as a new tool, the program will remember what you logged across runs — your data will persist between sessions instead of vanishing when the program exits. This is the moment the project becomes genuinely usable. The try/except mechanism from this part becomes essential there: files have their own ways of going wrong (missing, locked, malformed), and the same exception-handling pattern handles all of them.
The AI thread continues with the fourth skill: detecting plausible-but-wrong code. File-handling is a domain where AI can produce code that runs without errors on the happy path but has real problems — files left open, errors silently swallowed, paths that work only on one operating system. The verification skill also gets sharpened on a category of bugs that surface-level testing does not catch.