AI can make you a better programmer or a worse one, and the difference is not the AI — it is how you use it. Used as a tutor, AI deepens understanding; used as an answer machine, it quietly replaces the thinking you were supposed to be doing, and the gap shows up later, when you must explain your own code and cannot. This course names three modes of AI use — AI Off, AI as Tutor, AI as Collaborator — and every unit tells you which mode is in force. The mode is not a punishment or a reward. It identifies the kind of learning you are doing right now, and what that learning needs.
This article explains the three AI modes used in all of Mr. MacKenty's courses: what each mode allows, why each exists, and how to work well inside each one. It also covers the AI use log — the structured record you keep in Mode 2 and Mode 3 — and what separates a log entry that shows thinking from one that just proves AI was used.
| Level | What it covers | When to read it |
|---|---|---|
| Basic idea | What the three modes are; what is allowed in each; how the pre-ask protocol and the AI use log work | Right now — before your first Mode 2 session. |
| At a deeper level | Why each mode exists; what strong AI use looks like in practice; what makes a log entry weak or strong | Once you have written your first log entries. |
| At the deepest level | The learning science behind the modes; how this maps onto professional practice; why accountability travels with autonomy | When you want to understand why the course is built this way. |
1 The Three Modes at a Glance
Every unit — sometimes every week — names one of three modes. The mode tells you what AI use is appropriate for the learning happening right now.
No AI. You trace code by hand, predict before running, find bugs on paper, and write short programs independently. This is where the mental muscle gets built — and like a gym, having a machine lift the weight for you defeats the purpose entirely.
AI is available, with structure. Before asking, you explain your own thinking: what you are trying to do, what you already tried, and your best guess at the problem. You ask for explanation, examples, or critique — not finished answers. You keep a structured AI use log, and you can explain every response in your own words.
Full AI access on larger projects, approximating professional practice. AI may generate code — but you must justify every design decision, answer live questions about any line, and keep an analytical log of significant interactions. The freedom is real; so is the accountability.
One rule sits above all three: assessment is always AI-off. Quizzes, code-reading challenges, and oral defenses measure what you can do independently, whatever mode the surrounding unit is in.
The modes are matched to content deliberately, and the pattern is worth seeing: new mental models are built in Mode 1; existing models are deepened in Mode 2; established skills are exercised at scale in Mode 3. This is why SQL was taught in Mode 1 — no one had a mental model of databases yet, and hand-writing SELECT and INSERT is how that model forms — while the mini data project that followed was Mode 2, because by then you had something real for a tutor to sharpen. The mode switches are not arbitrary; each one answers the question "what does this learning need right now?"
The central question of this course is: can you understand, build, test, and explain a working computational artifact? The word that AI threatens is explain. AI can produce code that runs; it cannot produce your understanding of it. The oral defense and desk checks exist to make that visible — you will be asked live questions about your own code, and no log, mode, or tool answers those for you. Every mode rule traces back to protecting the thing that is actually assessed.
The structure rests on research about how learning works. Cognitive science is clear that durable skill comes from retrieval, prediction, and productive struggle — doing the hard thing yourself, at the moment it is hard. It is equally clear that novices learn well from worked examples, explanation, and feedback — which is exactly what a tutor provides. The modes separate these because they conflict when mixed: unguided AI access during model-building replaces the struggle that builds the model, while forbidding AI during large projects withholds the feedback and leverage that make ambitious work possible.
International guidance on generative AI in education (UNESCO among others) reaches the same conclusion from the policy side: AI supports learning when its purpose, limits, and accountability are explicit, and undermines it when access is unstructured. The three modes are that explicitness, written into the course.
2 Mode 1: AI Off — Building the Muscle
In Mode 1, you do not use AI for the work at all — not for hints, not for checking, not for "just explaining." The activities in Mode 1 weeks are chosen because doing them yourself is the entire point: tracing code by hand, predicting output before running, finding bugs on paper, writing short programs from a blank file.
Mode 1 is not a statement that AI is bad. It is a statement about timing: this particular skill, right now, has to form inside your head, and it forms through the effort. There is no route to it that skips the effort.
The honest question students ask is: "If AI can do this, why must I learn it by hand?" The SQL weeks are the clearest answer this course can offer. Students who hand-wrote SELECT and WHERE in December looked at SQLAlchemy in January and recognised it instantly — the ORM reveal landed because the SQL was already theirs. A student who had let AI write their queries would have seen only unfamiliar code generating other unfamiliar code, and would be helpless the first time either misbehaved. Mode 1 is where the ability to judge AI's output later is built. You cannot catch an error in a language you never learned.
The same applies to every Mode 1 skill. Code tracing is what lets you check AI-generated code instead of trusting it. Predict-before-run is what tells you an answer is wrong before it costs you an afternoon. Mode 1 does not compete with AI use — it is the prerequisite for good AI use.
The learning-science name for what Mode 1 protects is the generation effect, which you have met before in this knowledge base: producing an answer yourself builds far stronger memory and understanding than reading or receiving the same answer. Struggle at the right difficulty is not an unfortunate cost of learning; it is the mechanism. This is also why assessment is always AI-off — a measurement of what you can generate is only valid if you generated it.
There is a professional version of this argument too. Experienced engineers increasingly describe their value not as typing code — AI types faster — but as judgment: knowing what to build, recognising when generated code is wrong, and debugging what no tool can. Judgment is compressed experience of doing the work yourself. Mode 1 weeks are where your compressed experience begins accumulating.
3 Mode 2: AI as Tutor — The Pre-Ask Protocol
In Mode 2, AI is available as a tutor — and the difference between a tutor and an answer machine is what you bring to the conversation. Before any AI interaction, you write a short pre-ask, three lines:
- What I am trying to do. The specific goal, not "make it work."
- What I already tried. Concretely: "I tried X and got error Y."
- My best guess. Your hypothesis about what the problem is — before you hear AI's.
Then you ask — for explanation, an example, or critique of your approach, rather than a finished solution. After the response, you complete a full entry in your AI use log before changing any code. The log entry records the interaction and, more importantly, your evaluation of it: was the answer correct, how do you know, and what did you actually change?
The pre-ask protocol looks like bureaucracy until you see what each line is doing:
- "What I am trying to do" forces a precise question. Vague goals produce vague prompts produce vague answers. Half the value of a tutor — human or AI — is that preparing to ask well requires understanding your own problem better.
- "What I already tried" prevents answer-shopping. If you have tried nothing, you are not stuck — you have not started. The protocol makes AI the second resort, after your own attempt, which is exactly where a tutor belongs.
- "My best guess" turns the answer into feedback. With a hypothesis on record, AI's response tells you something about your thinking: your guess was right, or wrong in an instructive way. Without one, the answer arrives in a vacuum and teaches nothing about your own model. This is predict-before-run, applied to conversation.
A course habit that pairs with Mode 2: when stuck for more than fifteen minutes, explain the problem out loud to a partner before opening AI. A large fraction of bugs dissolve during the explanation — the act of verbalising forces the precision that finds them. If the bug survives the explanation, you now have an excellent pre-ask already drafted.
Mode 2's design has a specific target: the failure mode researchers observe with unstructured AI access, sometimes called answer-seeking — reaching for a solution at the first moment of friction, accepting it if it appears to work, and moving on. Each individual instance feels efficient. The accumulated effect is a student who has completed everything and learned little, which stays invisible until an AI-off assessment or an oral defense makes it visible all at once.
The protocol interrupts answer-seeking at its trigger point — the moment of friction — by inserting a small amount of the very thinking that answer-seeking skips. It is deliberately lightweight: three lines, not an essay. The theory of the course is that the habit, practised until automatic, is what Mode 3 later assumes. Students who internalise the pre-ask in Mode 2 direct AI naturally in Mode 3; students who treated it as paperwork find Mode 3's freedom is where their work quietly falls apart.
4 The AI Use Log: Evidence of Thinking
The AI use log is the record you keep of every significant Mode 2 interaction. It is not a confession, and it is not a decorative appendix — it is evidence of thinking: what was asked, what came back, what you changed, what you checked, and what you now understand better. A full entry has eight parts:
| Section | What it must say |
|---|---|
| Date and context | When this happened and what you were working on. |
| Before: what I tried | A specific description of your attempt. "I tried X but got error Y" is acceptable; "I was stuck" is not. |
| Before: my best guess | Your hypothesis about the problem, written before AI's answer. |
| Question to AI | The exact prompt you sent — paste it. |
| AI's answer, in your own words | Your summary of the response. Not a paste — if you cannot summarise it, you do not yet understand it. |
| My evaluation | Do you think the answer is correct? Why? Did you test it? |
| What I changed | What you actually did. Used it directly, modified it, or rejected it — and why. |
| What AI got wrong (if anything) | Any error in the response, described specifically. The most valuable section — and the one most often left empty. |
The log template is in your course folder. One entry per significant tutoring interaction — not per message, and not per session.
The log is graded, and the difference between levels is not length — it is specificity. Compare:
| Section | Weak | Strong |
|---|---|---|
| What I tried | "I was stuck on sorting." | "I tried list.sort() but it modified the original list, which broke my comparison logic." |
| Evaluation | "It worked!" | "I ran it with input X and got Y, which matches the expected output." |
| What AI got wrong | "AI was very helpful." | "AI suggested sorted(), but that returns a new list — I needed in-place sorting for the function contract to hold." |
| What I changed | "I used it." | "I used AI's structure but changed the condition on line 7 because the original didn't handle an empty list." |
The pattern behind every strong example: a weak log reads as a receipt of AI interactions; a strong log reads as a thinking journal that happens to involve AI. Notice also that testing AI's answer — with real inputs, against expected outputs — keeps appearing in the strong column. Everything from the testing articles applies to AI output, because AI output is just code.
Why is "What AI got wrong" the most valuable section? Because it is the one entry that cannot be produced without genuine engagement. Summaries can be padded and evaluations can be vague, but naming a specific error in an AI response requires having read it critically, tested it, and caught it — the exact skills the mode exists to build. The bug-injection exercise, where you analyse AI-generated code seeded with plausible-looking logic errors, exists to prove the underlying point viscerally: AI produces confident, professional-looking code that is wrong often enough that uncritical trust is a genuine risk, not a hypothetical one.
The log also does honest work for academic integrity, but note the direction: it does not exist to catch you using AI — Mode 2 explicitly permits that. It exists so that your AI use is visible and defensible. In the oral defense, a student with a strong log can walk through exactly what was theirs, what was AI's, and how they verified the difference. That is not a student avoiding an accusation; that is a student demonstrating command of their own work — which is the course's central question, answered.
5 Mode 3: AI as Collaborator — Autonomy with Accountability
In Mode 3, the structure comes off: full AI access, no mandatory pre-ask, AI may generate code for your project. This is the closest the course comes to professional practice. In exchange, the accountability rises to match:
- You must be able to justify every design decision as yours.
- You must answer live questions about any line of your code in the oral defense.
- You keep an analytical AI use log: significant interactions, categorised by type (clarification, code generation, debugging, design, evaluation, explanation), with a pattern analysis at the end of the project.
The test is no longer "can you follow the Mode 2 rules." It is: can you direct AI well, catch what it gets wrong, and stand behind every decision in your code?
Mode 3 feels like freedom. It is actually the more demanding environment. In Mode 2, the protocol made you reflect; in Mode 3, nothing makes you — and five weeks of full AI access can produce a polished-looking product its builder cannot explain, which the oral defense then exposes all at once. The students who thrive in Mode 3 are the ones for whom the Mode 2 habits became automatic: they still articulate the problem before prompting, still test generated code before trusting it, still note what AI got wrong. The protocol was scaffolding; Mode 3 is the building standing without it.
Two failure modes are worth naming, because both are real. Over-reliance: AI generates, you assemble, and understanding quietly never forms — visible in a thin log and a shaky defense. Under-use: doing everything manually out of distrust or habit, which also misses the point, because directing AI effectively is the Mode 3 learning objective. The target is neither dependence nor abstinence; it is direction — you deciding what to build, AI accelerating parts of it, you verifying and owning all of it.
The categorised log turns your own AI use into data. At the end of a Mode 3 project, the pattern analysis asks: which categories dominated? A log that is mostly code generation with little evaluation or clarification describes a different working relationship with AI than one balanced across categories — and seeing your own pattern is the first step to changing it. This is metacognition applied to tool use, and it is a professional skill: the engineers who benefit most from AI are, observably, the ones who have thought about how they use it.
The deepest principle of the whole system is that autonomy and accountability travel together. Each mode grants more freedom and demands more ownership, ending at the professional norm: complete freedom of tools, complete responsibility for the result. No engineer explains a production failure with "the AI wrote that part." The three modes are a staircase to that norm — which is why the sequence ends not with a rule about AI, but with a five-minute conversation in which you, without any tools at all, explain your work.
- Name the three AI modes and the nickname for each. For each mode, state in one sentence what kind of learning it protects or builds.
- Why is assessment always AI-off, regardless of the surrounding unit's mode?
- SQL was taught in Mode 1 while the mini data project that followed was Mode 2. Using the idea of mental models, explain why each mode was chosen.
- Write out the three lines of the pre-ask protocol from memory. For each line, explain what it prevents or provides.
- A classmate says the pre-ask protocol is just extra paperwork before getting the answer. Make the strongest case against that view, using the connection to predict-before-run.
- List the eight sections of a Mode 2 log entry. Which section is described as the most valuable, and why is it the hardest to fake?
- Rewrite this weak log fragment as a strong one (invent plausible specifics): "I was stuck on my loop. I asked AI. It helped. I used it."
- Explain the difference between the Mode 2 log and the Mode 3 analytical log. What does the end-of-project pattern analysis reveal that individual entries cannot?
- Describe the two opposite failure modes in Mode 3. Why does the course consider under-use a failure and not just excessive caution?
- "Autonomy and accountability travel together." Explain what this means across the three modes, and why the sequence ends with an oral defense rather than a rule.