Today is the most important week for your independence. Up to now the AI wrote and you checked by using the app. This week you read the code, debug it with the AI switched off, write a feature yourself, and write your first automated test. Reassure them early: nobody expects them to write apps from scratch. Reading and fixing is a different, learnable skill. Slides 1–15 are the Studio A talk. Slides 17–18 are two short Studio B mini-lessons.
Anthropic's randomized trial (January 2026): 52 mostly junior engineers learned a new programming library, with or without an AI assistant. The AI group scored 50% on the follow-up quiz versus 67% for the group without AI, was not significantly faster, and fell furthest behind on debugging questions. https://www.anthropic.com/research/AI-assistance-coding-skills The AI users who scored well asked for explanations, asked conceptual questions, or fixed errors themselves. Low scorers handed everything over.
Geng et al. watched 19 students build a web app with an AI agent while thinking aloud. Only 7.4% of their actions involved looking at the code or the logs. Only 2.2% of their checks tried edge cases, no student wrote or ran a unit test, and 61% of their prompts asked the AI to debug for them. https://arxiv.org/pdf/2507.22614 This week you do the opposite: look at the code, the Console and the edges, and write a test.
Sankaranarayanan (2026), 78 learners who grew up with AI tools: on a 30-minute maintenance task with the AI blacked out, 77% of those who had used AI without restrictions failed, versus 39% of those whose tool had required a short explanation before generated code could be added. https://arxiv.org/abs/2602.20206 That's why the course has teach-backs in PROMPTS.md, and why you'll write code yourself in Studio B. CMU's course found the same pattern from the other side: understanding peaked on the assignment where students read and partly wrote the code (self-reported; a signal, not proof). https://www.cs.cmu.edu/~113/bestPractices.html
Every static app in this course has these five parts. When something breaks, first ask: which part? CSS rarely crashes; it just looks wrong. If your app looks broken but the Console is clean, suspect CSS. If it behaves wrongly, suspect JavaScript. In the lab's Part 1 you find all five in your own Project 1.
An element is one piece of the page: a heading, a button, an input box. The id must be unique on the page, and JavaScript must spell it exactly the same way. Keep that in mind for the Debug Clinic.
A variable is a labeled box that holds a value: here, a list (an array) of books. A function is a named recipe. addBook(...) runs it: we say we "call" it. { title: title } is an object: a bundle of name: value pairs, separated by commas. An event is something the user does: click, type, submit. addEventListener says "when this happens, run this code". The DOM (Document Object Model) is the live version of your HTML that JavaScript can read and change. Important detail for later: input.value is always text, even in a number box.
State is the data your app is keeping track of right now, in variables. It disappears when you reload. localStorage keeps text in the browser across reloads. JSON.stringify turns your data into text. JSON.parse turns the text back into data. Always use them as a pair. You can see what's saved: DevTools → Application → Local Storage.
Open DevTools with F12 (or Ctrl+Shift+I, Cmd+Option+I on a Mac) and click Console. Red lines are errors, yellow lines are warnings. The first word is the type of error. SyntaxError: the file couldn't be read at all. TypeError: a value wasn't what the code expected. ReferenceError: a name doesn't exist. Click app.js:42 to jump to the line. CMU students' own advice: spend 20 seconds reading an error before pasting it anywhere.
Read from the top down. render broke on line 113. It was called by saveAndRender, which was called by addSampleBooks, which ran when someone clicked a button. The bug is often not on the top line. The top line is where the problem showed up.
Reproduce: make it happen on purpose, with exact steps. Isolate: narrow it down to a file, a function, a line. Hypothesize: say out loud what you think is wrong and why. Test: check the idea before changing code: type a variable in the Console, or add console.log. Fix: the smallest change that fixes the cause. Verify: repeat the steps, and check you didn't break anything else. Most beginners jump from Reproduce to Fix. Don't. I'll demo it now.
The normal case usually works, because it's the case the AI was thinking about. After the clinic you'll check your own Project 1 for the same five kinds of bug, and in the homework you'll write three edge-case tests in TESTS.md.
The clinic is practice. Points are for fun, not your grade; taking part is. Driver types, navigator reads and asks questions, swap every bug. Tutor mode = a chat assistant with the course's hint-only prompt. It gives hints, not fixes. AI limited. Feeling uncomfortable without the AI is normal and expected. That discomfort is the skill being built.
Inline suggestions: grey "ghost text" that appears as you type. Switch them off while you write, so the thinking is yours. Ask: a chat that answers questions and doesn't change your files. It reviews your diff. Agent: edits files and runs commands by itself. That needs the habits you're building now, so it waits until week 6. Ask mode uses your monthly Copilot allowance too (numbers in TOOLS.md). Check the Copilot icon in the status bar. Each card has a criterion, a plan and a skeleton with blanks. You find your own names (your list, your draw function, your storage key) and fill them in. That's the feature you wrote yourself for Project 1.
Last week your checks were things you tried by hand. From this week, a check can be code: an automated test. You'll take one pure function out of your app (the "is this input OK?" check), write five tests for it first, see them fail because the function doesn't exist yet, then write it and see them pass. Why first? When an AI writes tests after faulty code, the tests tend to agree with the faults: in a 2026 study they caught 14% of faults, against 25% for tests written independently (Konstantinou et al., https://arxiv.org/abs/2607.05139). Week 5's starter has tests like this, and in week 6 you'll use them to check an agent's work.
Open the lab. Two codespaces today: your Project 1 and the clinic. Stop both at the end; free hours are limited (TOOLS.md). Never copy the kit into your Project 1 codespace.
Studio B, before Part 6. Demo in the demo repository. git log: one line per save point, newest first. q gets you out of the pager. git diff: red removed, green added. In walkthrough 1, it's a second way to find the line the examiner changed. git restore [file]: throw away uncommitted changes. No undo. git revert: a new commit that undoes an old one. History stays honest. Never git reset --hard or git push --force. Walkthroughs start after this part, once everyone has practiced.
Studio B, before Part 8. Demo red: the tests exist, the function doesn't. Read the message aloud. Then green after creating lib/validate.js. Then break it on purpose (<= to <) and read which test failed, what it expected and what came back: a boundary bug, like the clinic's, caught in a second. Three small files: package.json, tests/validate.test.js, lib/validate.js. Using it in your app (type="module") comes after.
Walkthrough slots start after Part 6. If you're called, commit first, close AI chat panels, and come back to where you were afterwards. Exit ticket at the end: AI off, graded on completion, not correctness.
The homework page has the checklist and a time plan (about 9½ hours). This is the first graded project. Minimum to keep up: npm test runs at least one passing test. Week 5 starts from a Node project with tests.