The road to COMP4020: the weekly questions
26 Mar 26
The core mechanic of COMP4020 is the weekly studio crit: students build a prototype in response to a provocation, then bring it to a facilitated group session where everyone engages with each other’s work. But a crit only works if students arrive ready to talk about what they made and why. Especially in this (School of Computing) context: art school students are used to ripping each other a new one during crits, but I think for Computing students doing this for the first time there’s a risk it’ll be a lot of “yeah, it’s fine” and “I dunno” with awkward pauses in-between.
So even with experienced facilitation, the weekly crits need a scaffold. Something that structures reflection without turning it into a worksheet; something students do every single week, the same questions each time, until the thinking becomes habitual. After a lot of back and forth I’ve landed on three questions.
The first is why this? Why did you build what you built in response to the week’s provocation? Why should this thing exist? This is about intentionality: not “what does it do” (we can see that) but “what were you going for?” A student who built a data visualisation might say they wanted to make a particular dataset legible to non-experts. A student who built something weird might say the provocation reminded them of a thing they’d always wanted to try. Either answer is fine; the important thing is to have an answer.
The second is what made it better? This one draws directly on the three feedback loops from my earlier post about climbing the “good” gradient. What signals helped you figure out which direction was uphill? Maybe your test suite caught a subtle bug before you even saw it in the browser (agent ↔ code). Maybe hot-reloading let you iterate on a layout until it felt right (human ↔ artefact). Or a friend’s confusion when you showed them told you something you couldn’t see yourself (human ↔ community). The question forces students to identify the specific feedback that moved them forward, and over the semester, to get better at designing those feedback loops deliberately.
Often this will be a tool or blog post from someone else in the world trying to figure out this brave new world of agentic coding. And there’s a lot of advice out there. A big part of what I’m excited about for this course is to have hundreds of students road-testing the various ideas (even the unhinged ones) that are flying around, and then sharing with their classmates what they found. Gonzo GasTown, if you will.
The third is any good?—the hardest question, and the most important one. Is this prototype good? For whom? What does “good” even mean here? And if you could keep going, which direction would you head? This is where students practise the skill that agentic coding makes simultaneously more important and easier to neglect: judgement or taste. The course gives students weekly practice making and defending quality claims about their own work, in front of their peers.
Each week, alongside their prototype, students submit the answers as three
skeets: one per question, 280 characters max, with an
optional image. That’s it. Actually, they don’t actually have to post them
publicly (they will just be in a skeets.md file in the source repo they
submit), but the “genre” is of the skeet/tweet (280 characters max, with 1-4
optional images). Memes welcome, too.
I’m trying a short format so students can bring one specific observation to the crit without writing another essay each week.
Students can also attach an image: a before/after screenshot, a diagram of the workflow that finally clicked, or a photo of a whiteboard sketch.
There’s a long tradition of this kind of reflective practice in education. Donald Schön’s The Reflective Practitioner is the canonical reference, and studio-based disciplines like architecture and fine art have been doing structured crits for decades. The skeets are my adaptation: lightweight enough to sustain weekly, compressed enough to force precision, and native to the kind of short-form writing that this generation of students already knows how to do well.
The visibility of those skeets is staged, following the same release model as the source code and deployments. Before your studio crit, your skeets are visible only to you: you’ve done the thinking, but you haven’t been anchored by anyone else’s reflections. When your crit begins, they become visible to your studio group. The tutor can reference them (“you wrote that the test suite was the thing that saved you this week—tell us more about that”), and your peers can see what you were going for before they offer feedback.
After all the crits in a studio group are done, everyone in the group can see everyone’s skeets. And once all groups have finished for the week, they’re visible class-wide. This is the same rhythm as the code itself: private until your crit, group-visible during, fully open after.
The staged release prevents early anchoring: students write their reflections independently, so you get diversity of thought rather than twenty variations on whatever the first person said. The tutor also gets material to work with during the crit, which is especially valuable for drawing out quieter students who might struggle to articulate their thinking on the spot but wrote something sharp in their skeet. And over the semester it builds a growing, browsable archive of the class’s collective reflection.
The reflections give students material to discuss when the crit starts. Over ten weeks, I hope the three questions become habits they use while building.
Cite this post
@online{swift2026comp4020TheWeeklyQuestions,
author = {Ben Swift},
title = {The road to COMP4020: the weekly questions},
url = {https://benswift.me/blog/2026/03/26/comp4020-the-weekly-questions/},
year = {2026},
month = {03},
note = {AT-URI: at://did:plc:tevykrhi4kibtsipzci76d76/site.standard.document/2026-03-26-comp4020-the-weekly-questions},
}