Practice: check an AI suggestion
After lesson 6 · Control flow · Allow 30–40 minutes, at your own pace
An assistant offers you a short Python function. It looks tidy and its explanation sounds confident. How do you decide whether to use it? You compare it with the job you wanted done, follow its steps, and run examples that could prove it wrong. You already have the tools for this: comparisons, conditionals, and functions.
This lab follows Functions and reuses the grading rules from Conditionals. You will predict → attempt → inspect → test → explain, then solve a different problem on your own. Checking a suggestion is a programming skill; typing fewer lines does not by itself show that you understand them.
The assistant response below is a fixed teaching example written for this lab, with a deliberate mistake. It is not a live model response or evidence about how often a particular tool fails. You can finish everything on this page without signing up, sharing data with an AI service, or making a paid call.
The Python runner downloads its runtime when needed and executes your code in the browser. Notes and editor text are temporary: copy anything you want to keep before leaving or reloading. Quiz results and solved-challenge flags use the course's existing browser storage; this lab adds no telemetry.
Before using an assistant
A generative AI model produces text or code using patterns learned from data and the information it receives. A prompt is the request you give it. Its context is the information available for that response, such as your request and any code you share. It may lack details you assumed it knew, invent an explanation, or produce a different answer on another attempt. Its answer is a proposal to check.
Writing code in a chat is different from running Python. A chat explanation is not a test result. Some coding assistants can also edit files or run commands when given access. Before using one, check what it can read, change, execute, or send over the network. Approve only actions you understand, in a small practice project.
Use invented examples while learning. Never paste passwords or API keys (secret access credentials) into prompts. Share private records or other people's code only when you have permission and understand the service's current data policy; for practice, replace them with invented examples. An assistant running on your computer may still send context to a remote service. Today's lab uses invented scores and asks for no credentials.
You are learning to use and check assistance here. Training a model and building an application that calls one are later subjects. You can also choose to work without AI; the same tests and explanations still matter.
1. Predict the required behavior
Our specification is the rule the program must follow. For this exercise, the input is a whole-number score from 0 through 100:
| Score | Return value |
|---|---|
| 90 through 100 | "A" |
| 80 through 89 | "B" |
| 70 through 79 | "C" |
| 0 through 69 | "F" |
The function will be called grade_for(score). Ignore other kinds of input for this lab; input validation comes later. Before looking at a suggested implementation, write the expected grade for 85, 90, and 69, and explain which rule applies to each.
2. Attempt it yourself
Use def, if / elif / else, and return to make a first attempt. An incomplete attempt is useful: write the part you understand and one precise question about what is confusing. Leave the suggestion below closed while you try.
If stuck, a bounded request such as “Ask me which comparison includes the cutoff; do not write the function yet” can preserve your opportunity to think. Later, when you can inspect the results, you might request a small implementation. More assistance is a choice, not a requirement.
3. Inspect the suggestion
Open the example when you have made your predictions and attempt. Before running it, trace one call: substitute the score into each comparison and stop at the first true branch. Compare what the code does with the specification, not with the confident explanation beside it.
Open the example assistant response
Example prompt: “Write grade_for(score) for whole-number scores from 0 to 100. Return A for 90 or above, B for 80–89, C for 70–79, otherwise F.”
Curated response: “This checks the highest grade first and includes every cutoff correctly.”
def grade_for(score):
if score > 90:
return "A"
elif score >= 80:
return "B"
elif score >= 70:
return "C"
else:
return "F"
That explanation is a claim to investigate. A boundary is where a rule changes, such as the cutoff between B and A. Which boundary deserves a closer look?
4. Choose tests, then run and repair
A test case pairs an input with an expected result. Choose cases before clicking Run tests: include an ordinary score, each cutoff, and a score just below it. A counterexample is one case where the code disagrees with the specification. One counterexample is enough to show a bug; many passing cases do not prove there are no bugs.
The editor starts with the same flawed suggestion. Run it unchanged once, compare the failures with your trace, then make the smallest repair. The supplied checks give you feedback; they do not replace choosing your own cases.
You can also write your own executable checks. Python's assert statement checks that an expression is true. If it is false, Python stops with an AssertionError. For example, assert 2 + 2 == 4 succeeds silently, while assert 2 + 2 == 5 fails. After the function, an assertion such as assert grade_for(85) == "B" checks a particular call. Replace the input and expected grade with cases from your plan. Use the specification to choose the expected result, not the function's current answer.
Run the suggestion unchanged, then repair it. Add your own assert checks below the function. A failed assertion appears as an error before the supplied checks can run.
After your attempt: inspect the worked trace
For score = 90, the original first condition is 90 > 90, which is false. The next condition is 90 >= 80, which is true, so the function returns "B". The specification requires "A". Changing the first comparison to >= 90 includes the cutoff. At 89 it remains false, preserving the B case; at 91 it remains true, preserving the A case. Re-run the other cutoffs to check the repair did not change them.
If you used the hint or solution, that is useful practice. Record the help you used and use the independent task below to check what you can now do yourself.
5. Explain what changed
Close the solution and use your own words. Which exact input exposed the error? Why did the original code return the wrong value? Why does your change fix that case while keeping the neighboring case correct? Name one test your plan added beyond simply trying a typical score. If you cannot yet explain a line, trace it again before accepting it.
6. Independent check: a different rule
Now close the example, hints, and solution. Work without an assistant or copying the grade function. You may refer to the earlier lessons for Python syntax. This transfer task checks whether you can apply the idea to a different problem. Its runner supplies feedback but deliberately has no hint or solution button.
Write delivery_fee(total) for a shop. The input is a whole-number order total of 0 or more. Return a number:
- Orders 50 or above have a fee of 0.
- Orders 20 through 49 have a fee of 2.
- Orders below 20 have a fee of 5.
Choose your own boundary cases and expected fees before running. Write at least two assert checks after your function. Explain how you know exactly which branch handles a total of 20. The runner checks behavior, not whether you wrote an explanation or worked independently.
Implement delivery_fee(total), then add your own assertions. Return 0 at 50 or above, 2 from 20 through 49, and 5 below 20. Complete this without assistant help.
If you need help, return to Conditionals or Functions, then retry with the help closed. Mark that attempt as practice. A passing test suite after copying a solution does not establish independent understanding.
Come back in a week
On paper or in your own editor, write ticket_price(age) for whole-number ages of 0 or more: under 6 is free, ages 6 through 17 cost 8, and ages 18 or above cost 12. Without AI or this lab's code, choose boundary tests, explain the branches, and then change the adult cutoff from 18 to 16. Keep your test expectations consistent with the new rule. You can return to Run Python locally later to execute your saved attempt.
These tasks check this boundary-and-branching idea: can I trace an unfamiliar input, find a wrong comparison, choose a failing test, explain a repair, and adapt the rule independently? They do not establish that you can solve every kind of programming problem. Record those observations separately from how quickly you finish. This lab's quiz, solved badges, and Mark complete control are practice records, not certification of those abilities.
Why it matters
The core habit is useful whether code came from you, a teammate, a tutorial, or an assistant. Write down the intended behavior, inspect the implementation, and gather evidence by running checks. Use more assistance only when you can still explain and evaluate the result.
Common pitfalls: trusting a polished explanation; testing only ordinary inputs; letting the same suggestion define both the answer and the expected tests; sharing private data to get help; and mistaking a green badge for the ability to solve the next problem.
Checkpoint
This checks the ideas behind the lab. Complete the independent task as well; a quiz alone cannot demonstrate programming competence.
Checking an AI suggestion
Pass to unlock the Next button belowNext: Lists →