Last updated: 2026-10-26

U
Undergraduate level
APL
Applied / Methodological — Knowledge with a 5–10 year half-life — stable practice

Independent Learning and AI

Part of Object Orientation as the Beginning of Software Engineering. Writing a class is also an occasion for noticing what you learned while writing it, and for deciding how a generative AI tool fits into that process — neither of which happens automatically just because the code compiles.

Turning Programming Into Evidence Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

A few questions turn ordinary programming activity into something you can show someone else as evidence of learning, rather than just a working program: what assumption in your original design turned out to be false? What defect took the longest to track down, and why? Which test, if it had existed earlier, would have caught it sooner? What did you look into on your own initiative, and how did you judge the source you found to be credible? Which technique did you consider and reject, and on what grounds? What would break first if the system had to hold a hundred thousand items instead of a dozen?

Compare two ways of answering the first question.

I initially stored available and currentBorrower separately. A test produced a state in which the item was marked available while still holding a borrower reference. I removed the duplicated state and calculated availability from the borrower reference instead. This reduced the number of possible contradictory states, although using null still leaves the absence of a borrower implicit.

Against:

I learned that encapsulation is important and would manage my time better next time.

The first is stronger because it names a specific piece of evidence (the test result), the decision made in response to it, and a limitation that remains even after the fix. The second could have been written without having built anything at all. See Reflective Writing for the fuller treatment of what separates the two.

AI as an Inspectable Aid, Not an Authority Applied / MethodologicalKnowledge with a 5–10 year half-life — stable practice

A generative AI tool is neither banned here nor a shortcut to automatically better code. The useful question is never "did you use one?" — it is what you did with what it gave you.

Exercise. Ask an AI tool to suggest improvements to EquipmentItem. For each suggestion it offers, classify it as useful, unnecessary, incorrect, unsafe, or not yet understood, and record the suggestion, its claimed benefit, what you checked to confirm or reject it, whether you accepted it, and what effect it had on the code and on your own understanding. A plausible set of suggestions to evaluate this way:

  • use a builder pattern for a two-field constructor;
  • replace every class with an interface;
  • add a third-party annotation library to generate boilerplate;
  • make all fields public, for easier testing;
  • hold the borrower as Optional<Borrower> instead of a nullable field;
  • introduce a database immediately;
  • add synchronisation to every method;
  • generate a getter for every field.

Some of these are genuinely reasonable at a larger scale and overkill here; some are close to backwards (public fields for "easier testing" undoes the whole invariant-protection argument on the main page); none of them should be adopted because a tool suggested them, and none should be rejected for that reason either.

Note well. If you cannot explain, test, and maintain a generated contribution, it has not yet become part of your own engineering capability — whatever it did to the code.

Worth watching for specifically, because each has caught real developers out: a hallucinated method or class that does not exist in the actual API; an example drawn from an older library version than the one in use; a fabricated-sounding reference offered with real confidence; code that would leak assessment material or personal data if run as suggested; a security weakness introduced along with the fix; complexity added that the original problem never asked for; and the question of what you can honestly claim authorship of once a tool has contributed text you kept.

See AI-Assisted Development and Vibe Coding: What Actually Predicts Success for the fuller treatment of verification habits and what the evidence says actually separates effective AI-assisted work from the rest.