The Intuition Track:
teach with AI without teaching students to stop thinking
In-person workshops for students, tutors, teachers and academic operations staff. The through-line across all three formats is one skill: making AI ask the questions instead of supplying the answers — and being able to prove, with a rubric, that it worked.
What you'll be able to do by the end of the track
- →Build a study assistant that interrogates a student's reasoning instead of handing over the answer.
- →Generate tiered practice material and a marking rubric from official syllabus wording.
- →Spot fabricated citations, invented quotes and flattery in AI-assisted student work.
- →Run a model on a school laptop with no student data leaving the building.
- →Write a script that marks short answers against criteria and returns what to revise.
- →Restrict an assistant to the official syllabus, so every answer cites a dot point.
Students, tutors, teachers and academic operations
In the room, laptops open, no lecture videos
1 day browser · 2 days terminal · 3 days build
One day: the browser you already have
6–7 hours, in person
For a staff room or a classroom where everyone has a laptop and nothing else. By the end of the day the chat tool your students are already using has become something that makes them work harder, not less.
This is a complete workshop, not a taster. It is the format we run most often, and for most schools it is the right one — everything below is built and tested in the room, and you take it home working. The longer formats add specific technical skills; they are not a better version of this day.
You will leave able to
- →Write a system prompt that refuses to answer and asks one diagnostic question at a time.
- →Explain to a colleague why a model sounds certain and is still wrong.
- →Turn a syllabus dot point into three tiers of practice questions and a marking key.
- →Audit a piece of student work for fabricated sources and unearned confidence.
- →Pick the right tool for the task instead of defaulting to whichever one is open.
- →Build and demonstrate a working topic coach inside 45 minutes.
How the day runs
Morning — how the thing actually works
- Taking a model apart on the projector Tokens, context, and next-token prediction — shown, not described. We hunt for the point where a fluent answer stops being true, in a subject the room knows well.
- The same question in three tools A live comparison across the major assistants: where a reasoning model earns its slowness, and where a fast one is simply better.
- Lab 1 · in pairs The tutor that won't tell you You write a system prompt that refuses to give answers. Your partner plays the student trying to extract one. You rewrite until it holds.
Afternoon — classroom use and its limits
- Lab 2 From dot point to differentiated worksheet Take raw syllabus wording and produce foundation, intermediate and extension questions with a marking key you would actually hand a colleague.
- Lab 3 Reading student work for AI failure Real submissions, checked for invented citations, misremembered quotes and answers shaped to please the marker rather than to be right.
- Closing sprint · 45 minutes You are handed a topic students reliably struggle with, and you build a coach for it. Everyone demonstrates.
And you take away
Tested against a real student, ready to paste into whichever assistant your school uses.
Templates for tiered worksheets, answer keys and diagnostic feedback.
What to look for in AI-assisted submissions, in a form you can share with a faculty.
Two days: off the browser, onto your own machine
12–14 hours over two days
Day one covers everything above and then opens a terminal. The reason to come is scale and privacy: marking one script by hand is fine, marking two hundred is not, and student work should not be uploaded to a service you have not vetted.
You will leave able to
- →Everything in the one-day format, plus the following.
- →Install and run an open-weight model on your own laptop, offline.
- →Pipe a folder of files through a model and get consistent output back.
- →Keep an API key out of your script, your repo and your shell history.
- →Write a marker that scores short answers against criteria and names what to revise.
- →Break a classmate's guardrails, and repair your own once they break yours.
How the two days run
Day one — foundations, then the terminal
- The one-day material, compressed Mechanics, tutor prompts and model comparison — fast, because the afternoon needs the room.
-
A terminal from a cold start
Moving between folders, storing a key in an environment variable rather than in the file, and joining
commands together (
cat | llm | jq). Nobody moves on alone. - A model running on your laptop Installing an open-weight model locally: no account, no API bill, and no student work leaving the room.
- Lab 1 Notes in, flashcards out Point a local model at a folder of syllabus notes and get back structured flashcards and summaries — with the internet switched off, to prove the point.
Day two — scripts, rubrics and attacks
- Output you can check by machine Calling a model from a script and demanding a fixed shape back, so a missing field is an error rather than a paragraph of apology.
- Lab 2 A marker that explains itself Score short answers against real criteria, and return a band plus the specific dot points the student should go back to.
- Lab 3 Break your neighbour's marker Swap scripts and try to talk them into full marks. Everything that works gets written on the board, and then defended against.
- Closing demo · 3 minutes each Show the room the tool you now have, running on your own machine.
And you take away
A local model installed and running on your laptop, configured with you in the room.
Grades against a rubric, validates its own output, and tells the student what to revise.
The constraints that held up after the room spent an hour trying to break them.
Three days: build something that survives a demo
18–21 hours over three days
Two days of labs, then a full day building in teams. The added skill over the two-day format is grounding: making an assistant answer only from the official syllabus and textbook, and citing which part it used.
You will leave able to
- →Everything in the two-day format, plus the following.
- →Index a syllabus and past papers so a model can retrieve from them.
- →Restrict an assistant to those sources and make it cite what it used.
- →Tell when retrieval returned something plausible but irrelevant.
- →Work in a shared repository under time pressure without losing anyone's work.
- →Present a working system to people whose job is to find its weak point.
How the three days run
Foundations and the terminal
The two-day material at pace: mechanics, prompting, local models, and a working development setup on every laptop by the end of the day.
Grounding in the syllabus
Retrieval over official documents, so answers come from the curriculum rather than the model's memory — plus the guardrails and the team repository you'll build on tomorrow.
Team build and demonstrations
One day, one team, one working prototype — then a live demonstration where the judges use it themselves.
Day three in detail
The brief is deliberately narrow, because a working narrow thing teaches more in a day than a broad thing that never runs.
Choose one brief
Given a student's working, name the misunderstanding behind the error rather than correcting the arithmetic.
Question a student about their own argument until either it holds or they find the gap themselves.
Answer only from official dot points and past papers, with a citation on every claim and a refusal when there is none.
The shape of the day
What the judges are looking for
Published in advance, because the point is to build towards it — not to guess.
And you take away
Built by your team, demonstrated live, not a slide deck about one.
Source, retrieval pipeline, tests and setup — yours to keep and continue.
Scored against the published criteria by judges from education and industry.
Completion of the three-day bootcamp, listing what you actually built.
A single day built from across the formats
Every lab above is self-contained, so a day does not have to come from one format. A staff day might take the tutor-prompt lab and the integrity audit from day one, then the offline model setup from the two-day format — skipping the scripting entirely.
This is common for mixed rooms, where some teachers have never used an assistant and others are already writing scripts. Tell us who will be there and what you want them able to do afterwards.
Two things you can try before booking anything
These are the starting points for Labs 1 and 2. Copy them, run them, and see whether the rest of the day is worth your time.
A tutor that refuses to answer
The lab is spent finding where this breaks — students are very good at extracting answers from it — and rewriting until it holds.
Notes to flashcards, offline
One line. No account, no API bill, and nothing sent anywhere — which is the whole argument for teaching the terminal to a school.