This chapter gives a working overview of Deploying in Class: From Build to Lesson, focusing on the ideas a reader needs
This chapter gives a working overview of Deploying in Class: From Build to Lesson, focusing on the ideas a reader needs before moving to the next chapter. The chapter moves through Learning outcomes, Opening, Deployment options, The three-check verification protocol, and related ideas. Read it for the main argument, the vocabulary it introduces, and the practical judgment it asks you to develop. The simulation works in your terminal. Now it has to work with thirty students who have never seen it.
The teacher projected the sorting simulator on the classroom screen for the first time.
The teacher projected the sorting simulator on the classroom screen for the first time. Twenty-eight ninth-graders. First period, Monday morning. The simulation loaded. The colors looked right on the projector. The teacher clicked through one bubble-sort pass to demonstrate. The students watched.
Before the verification protocol: how the simulation reaches the students' devices. Claude Artifacts. Fastest path to a shareable URL. From your Claude.ai workspace (or from Claude Code via the Artifacts MCP tool), generate the simulation as an Artifact. Claude produces a URL that opens the simulation in the student's browser without any installation. Best for one-off lessons or for prototypes you will revise after observation. Limitation: the URL is tied to your Claude session; for stability across the semester, prefer GitHub Pages.
Total time: 20, 30 minutes the day before class. Done once per simulation; re-done after any significant revision. A student who has never seen this simulation, and who knows nothing about how it was built, opens the URL. Can they figure out what to do in 30 seconds without any instructions?
The most important deployment property of a classroom-facing tool. The pattern: Detect the failure mode before it happens , check the inputs, the browser capability, the resource availability before invoking the operation that depends on them. Produce a user-readable message , plain language, specific, names the issue and the next action. Provide a path forward , a button, a reload, a fallback mode. The student should never be stuck without an option.
The framework applied to classroom-observed failures. Step 1: observe. During or immediately after the class, note what failed. Specifics matter. "Three students could not figure out the first interaction." , useful. "Some students had trouble." , not useful for revision.
A pedagogical move worth naming.
When the simulation fails in front of your students , and at some point it will , you have a choice. Hide the failure. Or use it. The chapter's recommendation: use it. Open the terminal in front of the class. Open Claude Code. Walk through the interrogation aloud. Walk through the plan-mode review. Switch out of plan mode. Watch the agentic loop run. Reload the simulation. Verify the fix.
Apply the chapter's discipline to your simulation from Chapter 11. Choose a deployment. Claude Artifacts for fastest; GitHub Pages for stable; class website for integration. The chapter recommends GitHub Pages as the default.
A meta-lesson worth offering once.
When your simulation fails in front of students (and it will, at least once), tell the students: "the simulation had a problem just now. I want to show you how I'd fix it. We'll work through it together." Open Claude Code on the projector. Walk through the revision-build cycle aloud , observe, interrogate, decide, respecify, re-suggest, re-verify. Re-deploy. Use the revised simulation immediately to continue the lesson.
"If it works on my machine, it'll work in class." No. The chapter-opening failures are exactly this misconception in action. Three checks; 20 minutes; the alternative is the failed lesson and the parent emails. "Pre-deploy testing is overkill." Three checks. Twenty minutes total. One failed class is fifty minutes of student time plus the recovery cycle plus the trust cost. The math favors the checks.
Maria Montessori (1870–1952) — Italian physician and educator whose method, articulated in The Montessori Method (1912)
Maria Montessori (1870, 1952) , Italian physician and educator whose method, articulated in The Montessori Method (1912) and elaborated through forty years of practice, was built on a principle she called control of error , that educational materials should be designed so the student can identify and correct their own mistakes without teacher intervention. A Montessori knobbed cylinder set has cylinders of graded sizes that fit into matching holes; if the child puts a cylinder in the wrong hole, the last cylinder will not fit.
Maria Montessori (1870, 1952) , Italian physician and educator whose method, articulated in The Montessori Method (1912) and elaborated through forty years of practice, was built on a principle she called control of error , that educational materials should be designed so the student can identify and correct their own mistakes without teacher intervention. A Montessori knobbed cylinder set has cylinders of graded sizes that fit into matching holes; if the child puts a cylinder in the wrong hole, the last cylinder will not fit. The material announces the error.
Claude Code for Teachers · Ch.14 · Chapter 12 — Deploying in Class: From Build to Lesson
That is the framework. Claude Code for Teachers, chapter 14: Chapter 12 , Deploying in Class: From Build to Lesson. The patterns are now in place. Apply them.