Code that runs and is wrong

The most dangerous output in this course

Generated code has a property nothing else in this course has: it will happily run, produce plausible output, and be wrong, and you will only find out later. A wrong essay sentence gets marked. A wrong line of code gets a result you then build on.

Students new to programming are the most exposed, because the failure requires you to read the code to detect, and reading code is precisely the skill not yet acquired.

The characteristic failures

Off-by-one and boundary errors. Loops that miss the last element, ranges that include an endpoint they should not. The code runs; the answer is slightly wrong.

Invented APIs. A function, method or parameter that does not exist in the library, with a completely plausible name. This is fabrication in a different costume, and it is common enough to have its own security concern: attackers register package names that models frequently hallucinate. If a package name comes from a model, check it exists on the real index before installing it.

Version drift. Correct code for an older version of a library. Deprecated arguments, renamed functions, changed defaults. The model’s training has no clean sense of which version you have installed.

Silent type problems. Integer division where you wanted float, string concatenation where you wanted addition, a pandas operation returning a copy when you expected a view.

Working code, wrong problem. The most expensive one. It solves what the model understood you to mean, which is not what you meant, and it works perfectly.

The rule

Read every line before you run it, and be able to say what each line does. If you cannot, you have not received help; you have received a liability. Run it, then test it on a case where you already know the answer, including an edge case: empty input, one element, a negative number, a duplicate.

That last habit is worth more than any other in this lesson. Generated code is usually tested by the person who received it against exactly the case they had in mind. Testing the boundary takes ten seconds and catches most of the off-by-one class.

Debugging, which is the excellent use

This is where these tools are transformative and where using them well is unambiguously good.

Here is the error, the full traceback, and the relevant function. Do not rewrite my code. Tell me what the error means, and what would cause it here. I will fix it.

Do not rewrite my code is the essential clause. Without it you get a rewritten file and no idea what was wrong. With it you get an explanation, and the ability to recognise that error unaided next time, which is the actual skill: professional programmers spend far more time reading errors than writing new code.

Also excellent: pasting a piece of unfamiliar code and asking what it does, line by line. This is reading practice with an infinitely patient annotator, and it is one of the fastest ways to get comfortable in a new codebase or language.

Version control is your process record

git is free, and for a student it does two jobs at once. It is how you avoid losing work, and it is a dated, granular record of your work developing, which is exactly the evidence Module 7 says you want to have before anyone asks for it.

The minimum that helps:

git init
git add -A && git commit -m "first attempt at the parser, failing on nested cases"

Commit at the end of every session, including the bad ones. A history of forty commits showing an idea developing, with failures in it, is worth more than any argument you could construct afterwards. GitHub and GitLab both host free private repositories.

What to keep doing yourself

For a computing student, this list is not optional:

• Writing a function from a specification, unaided, regularly.
• Reading a stack trace and locating the fault before asking anything.
• Reasoning about complexity: why this is quadratic and that is linear.
• Writing the tests. If the model writes both the code and the tests, the tests check the code’s assumptions rather than the specification’s.

That last point is subtle and important. Tests written by whatever produced the code will pass by construction. Write the tests first, yourself, from the spec, then let the model help with the implementation. That order preserves the check.

Free tools, named

Python, VS Code or VSCodium (the same editor without the telemetry), git, and Google Colab for a free notebook with GPU access. For learning to read errors, no tool beats print statements and a debugger you have actually opened. Copilot-style completion in the editor is convenient and, for a learner, actively risky: it produces code before you have formed the intention, which removes the design step from the task. Turn it off while you are learning the language, and turn it on later when you can tell instantly whether what it suggested is right.