Workflow

The prompts are the method

A teacher who wants to build their own exercises does not need to learn to code. What needs learning is saying the right thing to the machine: what the students should discover, what the exercise must not do, and what is wrong when the first version does not work.

So this station follows the prompts. They are all real, taken from the conversations behind the sites, and only shortened where it says […]. They were written in Danish and are translated here. The times come from the conversations and the git history. The teacher’s words are in pencil. What the machine wrote is in violet ink.

One exercise, one evening

Intended purpose on ex.samle.dk, for a course in medical device design on a health technology engineering programme, was built on 26 September 2026 between 22.37 and 23.48 and corrected the following afternoon.

1. Before anything

   The problem and the brief

   The assignments from an earlier cohort showed that students wrote the intended purpose as a product description. Contraindications were missing in 16 of 18 groups. The brief, just under a thousand words, says what they should discover (one word in the purpose can move the class, the users and the labelling) and what the exercise must not do: no data collection, no explaining next week’s rules, no invented article numbers. It ends with share your proposal before you build.

2. 26 Sep, 22.37

   The handover

   The teacher

   I’d like an intended purpose exercise as attached. Don’t take the instructions too literally, but ask if anything clashes with what is on ex.samle.dk.

   Claude Code, two minutes later

   I have read the brief, the README, the catalogue, the lesson notes and the error patterns from O1. Here is my proposal, and at the bottom four things that clash with the site or need deciding before I build.

   It also read the site’s CLAUDE.md, as it does at the start of every conversation: 187 lines, revised 15 times since August, with the rules every exercise inherits. The brief says what this exercise must do. CLAUDE.md says what every exercise must do.

3. 22.44

   The answer in four lines

   The teacher

   1. It’s fine to repeat, but maybe the device should be a different one. Suggest some, so we don’t overlap with the previous lesson.
   2. No lesson numbers. Content can be referred to, lesson numbers can’t.
   3. Include the term switch.
   4. Yes to images of the device used. […]

   The smartwatch from the brief became a fictional pressure-sensing insole. The brief was a starting point, not an order, and it said so.

4. 23.01

   The prototype and the caveat

   2,012 lines in twelve files. They came with a warning:

   Claude Code

   The answers in part B are my professional judgements. That applies especially to which fields are marked “debatable”.

   That is where the pencil goes in. The machine can write the sentence, but it is the teacher who vouches for it being right.

5. 23.23

   First run-through

   The teacher

   The exercise is very wordy, and the follow-ups in particular have an odd layout where only the left two-thirds of the box is used. Is that by design? […] “The marked phrases can be turned” is an odd way to put it. “Can be replaced” would be more logical. […] There was a fair bit of confusion about intended purpose at the end and all the required fields above. “How can they be written into 2–3 lines?” were the words. Please address that.

   Four fixes in 25 minutes, each with its own commit. Only one was technical: a display: grid that overrode hidden. The rest were too many words, a term nobody had learnt, and a company name that was never introduced. The next day the question came back, now from the teacher: Is all of it called intended use? The answer now sits above the card.

What the pupils found

Some mistakes are only visible to the people the exercise is for. 3dklinikken was tried out with a class of 12- and 13-year-olds, and afterwards came this prompt:

1. 25 Sep, 07.23

   A report from the class

   The teacher

   I tried the site with year 7 pupils, and there were some problems: […] One pupil got everything wrong, repeated exactly the same thing or didn’t place supports at all, after which the attached image appeared, which is exactly the opposite of the truth. I think the problem is that the build plate is the wrong way round. In the print animation (step 4) the part is rotated 180°.

   The answer key was wrong, and it looked right. No test would have caught it, because the code did what it was told. It took a pupil answering wrongly in the right way, and a teacher who saw why. The fix came ten minutes later: Correct the workshop’s support tasks so the answer key matches what the pupils see.

2. 27 Sep, 16.57

   A pattern a pupil taught the teacher

   A pupil had earlier beaten an exercise by picking the longest answer every time. The right answer was always the longest. The teacher took the pattern to another exercise, on usability, on ex.samle.dk:

   The teacher

   In the exercise “What was overlooked?”, step 2, the right answers are without exception the longest. Partly they are written far too close to the specific failure, partly the distractors are too short and vague. Please revise the step 2 exercises.

   The machine writes the right answer carefully and the wrong ones quickly, and then the answer can be found from length alone. Now the three options are the same length to within a few words. It is a mistake that keeps coming back, so it is worth looking for in anything with answer options.

The sentences that moved things most

Building it took an evening. Getting it right took the teacher.

Almost none of the teacher’s time went into code. It went into saying what should be made and seeing what was wrong. The same kinds of sentence keep coming back:

• Attach the material. The brief, the lesson’s slides, screenshots of the real device. The machine builds better on what exists than on a description of it.
• Give it permission to push back. Don’t take the instructions too literally, but ask if anything clashes.
• Ask for a proposal first. Share your proposal before you build. It costs two minutes and saves an evening.
• Say what it must not do. No lesson numbers. Point forward, don’t explain. Never invent an article number.
• Correct the teaching, not the code. I’d prefer each step to have a task where the students try to carry it out, note where it went wrong, and then report on the problems they found. About a cognitive walkthrough exercise that only asked students to find the faults.
• Describe what you see. Only the left two-thirds of the box is used. Is that by design? A question leaves room for there having been a reason.
• Say what you expected. I assumed you would ask the students to carry out the task, e.g. set pressure, without the answer.
• Measure the answer options. The right answers are without exception the longest. What the machine knows is right, it writes most thoroughly.
• Bring the class’s words. “How can they be written into 2–3 lines?” were the words. One pupil got everything wrong …

The workflow in short

1. The problem. What do the students get wrong, and what should they discover? Preferably something you have seen in assignments.
2. The description. A page on the purpose, the parts and what the exercise must not do. Ask for a proposal before anything is built.
3. The contract. A CLAUDE.md for the site with the rules that apply to every exercise. Revise it every time something bites.
4. The prototype. Read everything the machine marks as its own judgement.
5. The run-through. Yourself first, then with some of the people it is for.
6. The fixes. One commit per mistake, with a message that says why.
7. Use. In class, with the follow-up the exercise cannot do without.
8. Evaluation. Against the problem that started it all. For Intended purpose it comes when next year’s assignments show whether contraindications are still missing in 16 of 18.