Home/ Materials/ How these tools were made

Colophon · for the curriculum designers who asked

How these tools were made

Several people asked how the camp's tools were designed — what the rules were, where they came from, and how to make more. This is the answer: one principle, the constraints and the exact reason behind each, the two lineages they came from, and the method baked into every tool so you can build your own. The story of when it got built is the build story; this is the why.

§ A · The one principle

the test every tool has to pass
The whole design brief, in one line

Every tool makes one invisible mechanism something you can see, change, and break.

Not "teach about AI" in general — take one hidden thing (a probability distribution, a denoising step, drift across frames) and turn it into a knob you can move. A tool that explains is a slideshow; a tool that lets you turn one knob and watch the output move is an instrument. The camp builds instruments. The companion rule: the tools are simulations on purpose — frozen examples and hand-authored distributions, not a live model — so the mechanism stays legible and the demo is identical every time. A live model would be more impressive and less teachable.

§ A.1 · The shape of it

what "an instrument" cost, in parts
25single-file tools, no build step
0required accounts or API keys
1CSS system, 4 switchable skins
identical re-runs of any demo

§ B · The constraints & what each one buys

every rule is a pedagogical decision in disguise

Seven rules shaped every tool. None is about taste — each one buys something specific: it keeps the demo reliable live, keeps the tool equitable to reach, keeps the mechanism legible, or keeps the file alive for years. The column on the right names what each constraint is really protecting.

Reliability Equity / access Legibility Longevity

What the rule-set optimizes for, counted

Tally the right-hand column and the priorities show themselves — this is a curriculum that would rather be dependable and reachable than clever.

§ C · Where they came from

two bodies of work, joined
The mechanisms

A generative-AI course

ELIZA-vs-LLM comparisons, next-token prediction, image Default Tests, diffusion and latent-space activities, Temporal Telephone, A/B/C prompt testing. The activities that survived contact with real students were the ones strong enough to adapt for adults — which is why the camp's tools feel classroom-tested: they are.

The format

CC Fest Coding Camp

Free, virtual, community-centered workshops — beginner-friendly but intellectually serious, with recaps, asynchronous access, guest speakers, assignment tiers, and a closing showcase. Learning Machines is the two lineages fused: classroom-tested mechanisms, delivered the CC Fest way. The full account is in the Project Brief.

§ D · The method inside each tool

the loop the tools are shaped to support
01Predictbefore you press go 02Change one variablehold everything else 03Comparethe two outputs 04Name itdefault · failure · pattern repeat — the tool changes, the method stays SESSION SCALE · hypothesis → controlled A/B/C test → output comparison → evidence-based claim → ethical & pedagogical reflection

The take-home isn't any one tool — it's the loop. Predict, change one variable, compare, name precisely what the machine did. Each session widens the same four beats into a full investigation. Participants forget the URLs; they keep the method.

§ E · Make your own

the "Explain" studio pathway

Because every tool is a single readable file with no dependencies, the most direct way to understand one is to open its source and change it — swap the frozen examples for your own, relabel a knob, or fork the structure into a new mechanism. Building an explanatory tool, poster, or concept bridge is one of the camp's final-project pathways.

The whole philosophy fits in a sentence: if you can read the file, you can teach the idea — and if you can change one line and watch the output move, so can your students.