One real project. AI in the loop. Code you can explain.
The curriculum is usually one thing the student builds from nothing, with AI as a working partner rather than a shortcut, and concepts arriving when the project needs them. What follows is the version I would run given a blank page: a worked example, not a package. Which project, how long, how fast, and what gets graded all get rebuilt around the student, the school, and the time we actually have.
Why one app, and not twelve exercises
A folder of disconnected exercises teaches you that programming is a series of puzzles somebody else already solved. Building one real thing over a term teaches you the actual job: deciding what it should do, discovering you were wrong, and changing it.
So there isn't a fixed syllabus behind it. Every student is different, and what they actually want to build is usually the thing worth building.
The example I use throughout this page is a to-do list. It begins as a variable and a print statement. By the end it has a database, accounts, tests, and real users, and at no point did the student learn something whose purpose was "you'll need this later."
The part that matters most comes last. They use what they built for real: the to-do list becomes the list they actually run their week on, and everything that annoys them about it becomes the syllabus, which they are now the one setting.
What it feels like
Fun is the method, and getting your hands on it is the lesson
There is a formal framework under all of this: Merrill's First Principles, written up on my clinical practice page. But two things decide whether any of it lands, and they are easier to show than to argue about, so this part is not a description. It runs, you can edit it, and you are meant to.
Fun is not decoration
A student who is enjoying themselves attempts the harder thing, and attempting the harder thing is the entire mechanism. Play is not the sugar around the lesson. It is what makes somebody willing to be wrong in front of you, which is the precondition for learning anything at all.
Hands on, and unafraid
Running code beside the code that produced it, editable, with nothing punishing a bad edit. Breaking it isn't the point. Being in it is: changing a number because you wondered what it did, and finding out. Things do break, and that is fine; it is the evidence you were actually involved rather than watching. Nothing here scores you or keeps a streak, so there is nothing to protect, and somebody with nothing to protect is still enjoying it an hour later.
The first one below isn't a code demo. Mistakes have to be free before anyone writes a line: trying again is the expected move, not an admission of defeat. Get that wrong and the attempts turn timid, and fear is slow to undo.
Before the code · Learning science
One puzzle, two framings
Two people get the same puzzle. One is told a wrong guess costs five points; the other is just told to try again. Nothing else differs. Play either version, notice how you feel about guessing. The numbers come after.
Play both versions
Framing
A three-digit lock. Enter a guess and each dial tells you whether it's too high or too low. Nothing else. Go.
?
?
?
Nothing tried yet.
0 attempts· 200 points
You got it in 0
That was the experiment
Mark Rober gave the same puzzle to about 50,000 people. The puzzle was identical for everyone. The only thing that changed was one line of wording: whether a failed attempt cost you five points, or just said "that didn't work, try again."
52%succeeded: the group that was penalized
68%succeeded: the group that wasn't
The unpenalized group also tried two and a half times more often. Nobody got smarter. The failure just stopped being about them.
This is why the term is built so that a student deploys in week seven and breaks things in week eight, and why "it crashed" should be an ordinary sentence in the room rather than a confession.
The effect this demonstrates is Mark Rober's, named the Super Mario Effect and shown in his 2018 TEDxPenn talk The Super Mario Effect: tricking your brain into learning more. The idea, the coding challenge and the numbers in it are his; the toys on this page are my own restaging of them for a classroom.
Everything below is code, and the rule you just felt is still the one running underneath it. Change a number, see what it does, change it back. That loop is the whole method, and these are the smallest places I can show it to you.
Loops, state, a little physics
The Super Mario Effect
Mario doesn't tell you you're a bad person when you fall in a pit. He puts you back at the start of the level. Miss this one a few times on purpose, then read the rule beside it and notice what isn't in there: the comment that says // no points lost. no lecture.is sitting on the only line where a punishment could go. Put world.lose(5) on it, or press Punish the miss, and watch the page argue with itself.
Play the level
Jump the pit
Press Space to start. Then press it again to jump.
0attemptspoints lost: 0
The rule, edit it
Shown, not told
A Caesar cipher
A student can be told that % 26 handles the wraparound and write it down without ever seeing it. So instead: shift every letter forward, and watch what happens when z has to become c. Drag the shift, watch the red cells. That is the explanation. The sentence about modulo is just the caption.
Try the cipher
Your message
Encrypted
A↓A
B↓B
C↓C
D↓D
E↓E
F↓F
G↓G
H↓H
I↓I
J↓J
K↓K
L↓L
M↓M
N↓N
O↓O
P↓P
Q↓Q
R↓R
S↓S
T↓T
U↓U
V↓V
W↓W
X↓X
Y↓Y
Z↓Z
shiftLetter(25, 3) → 2 · 'z' becomes 'c'
The rule, edit it
The shape of a term
Eight weeks, one thing, getting harder
One example term, running the to-do list above: each week the app gains a capability, and the student gains the concern that arrives with it. The final assessment is their own app, with real users, not a zip file that only runs on my laptop.
I picked the to-do list because it reaches the concepts in a sensible order without needing a premise explained first, not because it is the thing to build. A different project, a shorter unit, a class that already has a syllabus, or an adult with one evening a week all reorder these rungs, and some terms never reach week seven, which is fine. What carries over is the shape: one thing, gaining a capability at a time, with the student able to explain each one.
Week 1Add a task, see your tasksA prompt, a list in memory, and one decision. It runs in the terminal, and it is already theirs.
Week 2The list in a browserA text box, a button, and the tasks on screen. Somebody other than the author can use it now.
Week 3The list survives a refreshStorage, and the moment a task stops being a string and becomes a record with an id, a title, and a done flag.
Week 4Your list, not everybody'sAccounts and permissions. Who you are and which tasks you may touch turn out to be two different questions.
Week 5Due dates that reach youA calendar or notification API: rate limits, webhooks, and what the list should do when the other service is down.
Week 6Proving "done" means done"The code runs" is not "checking a task off works" is not "the list feels right at 7am."
Week 7Other people's tasksDeployed, with real users putting real errands in it, and a rollback plan for the morning it goes wrong.
Week 8The annoyance listEverything about their own to-do app that irritates them becomes the refactor, and the postmortem gets written down.
Evidence of judgement
The engineering journal
A significant AI-assisted change gets a few sentences. Not to create paperwork, but to leave a trail showing that a person, not a model, made the call. These five questions are the version I use, kept in commit messages, in a doc, or just said out loud to me, whichever one a student will actually keep up.
What did I ask for?
What did the AI change?
What did I verify myself?
What could be wrong?
Why did I accept or reject the change?
Assessment
What I actually grade
Notice what isn't on this list: how much code you produced. In a world where code is cheap, grading volume grades the wrong thing. Where a school has its own rubric, these map onto it rather than replace it, and where nobody is being graded at all, it is simply the list of things we work on.
The quality of their requirements
Their ability to explain generated code
Test coverage, and test quality
Debugging method
Architectural trade-offs
Security awareness
Git and checkpoint discipline
Quality of user feedback
Their final engineering postmortem
Fit
You already have constraints
A class you did not pick, a syllabus you are committed to, a schedule with holes in it, a student who only wants to build one specific thing. None of those are obstacles to this. They are the inputs. The page above settles each of these on one setting so it could say something concrete; here is the range each one actually has.
Who's in the room
Grades 9–12, adults starting from nothing, and working engineers picking up a part of the stack they never touched. The vocabulary and the pace change; the loop underneath does not.
The format
One-to-one, a small group, or a full class. In person, or online across time zones. A weekly hour and a shared screen is enough to run all of it.
The project
A to-do list is the worked example on this page, because it walks through the core concepts in a natural order. A game, a bot, a scoreboard, a tool for a family business. I would rather teach the one you already care about.
The stack
Python or JavaScript to start, then wherever the project actually points: web front to back, databases, APIs, deploys. Claude, ChatGPT and Replit all turn up, and none of them is the point. My own work was large production systems, so following your project costs less than redirecting it.
The clock
A full term, an eight-week unit, a run of Saturdays, or an hour a week for as long as it stays useful. Short formats drop rungs rather than rushing them.
The paperwork
A school's existing curriculum, standards and rubric: this maps onto them rather than competing with them. Or none at all, if you just want the thing to exist.
Ready to see it up close?
Tell me the constraints you actually have: the student, the class, the schedule, the syllabus you're already committed to. Then I'll tell you how I'd run it inside them. If what you want isn't on this page, describe it anyway.
