Last week the course demonstrated that context matters. It never taught how to build one. That is this session, and the studio output is literally two of their four notebook files.
Add/drop is today — expect roster movement. Do not ask anyone to commit to anything; the domain claim is deliberately next week.
Prep check: live client repo open in a second window, six-part handout printed, two concept-video/product pairs queued, one paper with a strong limitations section.
Next week's volunteers before you leave today.
First one of the term, so it sets the norm. If they present a tidy fiction, ask one specific question about the mess — "where did the file actually live?" — and the honesty level for the rest of term is set right here.
Ten beats in 45 minutes. The two that must not be cut are beat 04 (the live repo) and beat 06 (iterate the instructions, not the output). If you are behind at 9:15, compress 07 through 09 into one slide and keep the scanning beat short.
The model has no memory of your project, no access to it, and no stake in it.
Everything it knows about your work, you put there. Everything you leave out, it invents — smoothly, in the same confident register as the parts it got right.
That is not a flaw to be fixed with better phrasing. It is the operating condition.
Resist the urge to anthropomorphise here, and resist the urge to over-correct into "it's just autocomplete." Both are shortcuts that stop them thinking. The useful frame is the practical one: what is in the room when you ask.
| Goal | What are we actually doing, and for whom |
|---|---|
| Constraints | What is fixed, what is off-limits, what cannot move |
| References | Examples of good. And examples of bad. |
| Non-goals | What we are deliberately not doing |
| House rules | The mistakes not to repeat |
| State | Where the work actually is right now |
Six parts. Most people supply one, and it is usually a compressed version of the first.
Hand out the one-pager here, not at the end. They should be holding it while you talk through the table.
Push on references, both kinds. Examples of bad are the part everyone skips and the part that does the most work — "not like this" is far more legible than any adjective.
Lives in a file that loads every time. Who the project is for, the constraints, the house rules, the standing non-goals. Written once, corrected as you learn.
Belongs in the message. What you are doing right now, the specific material in front of you, the one-off constraint.
Most people put everything in the message and rebuild the whole situation from scratch every session. That is the single most expensive habit in this room, and it is invisible because each individual instance only costs two minutes.
Six memory files, maintained across months. A file that refuses to start work until it knows which client. A rules file where every entry exists because something broke once.
It has a commit history. You can see when each rule was added and what went wrong the week before it appeared.
Ten minutes, live, not screenshots. This is the most credible ten minutes available in the course and no other instructor at the school can run it.
Scroll the history. Open one rule and tell the story of the failure that created it. That single move teaches beat 06 before you get to beat 06.
Fallback if you cannot get online: screenshots of the file tree, one rules file, and one history panel. Capture them the night before.
Two examples of the output you want do more than a paragraph describing it. Three do more than a page.
This is not a fact about models. Hand a paragraph of adjectives to a junior designer and you get the same result: something that satisfies every word you wrote and none of what you meant.
The line the session hangs on. It is the difference between someone who prompts and someone who builds a system.
Make it concrete immediately: "you fixed the tone in message four and again in message eleven. The second fix was free to make and cost you the whole thread. Put it upstream once and it stops happening for the rest of the project."
There is a difference between telling a model about your data and letting it read your data. They produce very different work and very different risks. One sentence for now; we do this properly in week eight.
Not dumped. Stale decisions, contradictions, and everything-you-happen-to-have all make output worse. What you leave out is a design decision.
Apple, Knowledge Navigator, 1987 · via DigiBarn / Internet Archive · CC BY-NC-SA 3.0
Show the two concept-video/product pairs fast — thirty seconds each. The gap does the teaching. Then hold up the paper with the good limitations section and read two sentences of it aloud.
The file is local and plays with the wifi off — that is deliberate, and worth thirty seconds of your own credibility to point out. Space and the arrow keys belong to the player while it has focus, so scrubbing will not jump the slide. Click once on the video first.
Pair one, and the only one fully rights-clean: Apple's Knowledge Navigator, 1987. Play about thirty seconds — the agent in the bow tie, the professor asking it to pull papers. Then ask what shipped. Almost all of it, thirty-eight years later, except the part the video is actually about: that it understood him. The concept video promised comprehension and delivered retrieval.
Pair two: Magic Leap, reusing last week's demo against MIT Tech Review's 2018 hands-on. ⚠️ Not committed — the only copy is a YouTube reupload, so it needs the network or an advance download. Do not build the beat on it.
What you write in the next hour isbrief.md and patterns.md — two of the four files in your graded notebook.
You do not have a domain yet, so write it for the project you think you might do. You will revise it after week three. Revision is visible in the history and revision is the point.
Say the "not an exercise" line explicitly. It is what stops the notebook reading as documentation homework for the rest of term.
GOAL what we are doing, for whom, and why it matters CONSTRAINTS what is fixed. money, time, bodies, law, physics REFERENCES two things that are good. two things that are bad. NON-GOALS what we are deliberately not doing HOUSE RULES starts empty. it fills up as you get things wrong. STATE where the work actually is today
If a section is honestly empty, write “not known yet.” That is real information. Inventing a constraint to fill a heading is worse than leaving it blank.
Walk the room. The most common failure is a goal written as an aspiration — "improve the experience of X." Push for a deficiency: what specifically is bad, for whom, and how would you know it got better.
brief.md supplied first. Save that too.State the consequence plainly: an untraced claim in a graded notebook is treated like an uncited quote. Not as a threat — as a definition, so nobody can say they did not know.
[unverified] is a completely acceptable answer and carries no penalty. Say that clearly or they will quietly drop the claims they could not source, which is the opposite of what you want.
Not everyone — sample six or seven and keep it moving. Note who had a genuinely thin brief; they are the ones to check on during week three.
brief.md and patterns.md tonight, even if they are rough. The history matters more than the polish.Reiterate that the domain is thirteen weeks and that the alternate-format options from week one apply to everything, so nobody should pick a safe domain to avoid exposure.
These slides are a fixed 16:9 canvas. In portrait they shrink to an unreadable strip; landscape gives you the whole slide.