The road to COMP4020: safety, YOLO and the open web

5 Mar 26

comp4020

Running terminal agents in “YOLO mode”, where they can run arbitrary commands (and delete all your data, or worse) is the sort of thing which you know you shouldn’t do. However, manually approving all the “can I use this tool” or “can I edit this file” requests becomes such a PITA that I (and many other developers I respect) that many developers (myself included) are doing it. Honestly, I have all my files backed up in a couple of different places, and while I have semi-important files on my machine I don’t have the nuclear codes or anything. Most of all, Claude hasn’t let me down yet (famous last words, I guess).

However, that’s me—thinking about teaching my students to use these tools effectively is another matter. If I say “use YOLO mode” then I feel some responsibility if it goes pear-shaped for them. So I’d rather they be safer, but my career in human factors research also tells me that you’ve gotta be pragmatic about what people are actually going to do.

There are a few emerging tools for squaring the “run wild, but don’t break my things” circle. Devcontainers is one of the big ones. However, Fly.io recently released Sprites, which are lightweight (i.e. fast startup) VMs with a) first class snapshot-and-restore functionality and b) automatically spring to life on the open web with a URL and everything. There’s lots you could do with this sort of setup, but I’m particularly interested in them for supportign collaborative student work in COMP4020.

The basic idea would be that for each week’s prototype and studio session the students would do their work in a (fresh) sprite. They could ssh in and do the dev work, and “serving” it on the web is as simple as running the dev server, finding out what the sprite’s URL is and then sharing that with their classmates. More than that, for collaborative work, students could give each other access to their sprite. That’s safe, because it’s got no data/files on it except for that week’s prototype. And because it’s checkpointable even if one student did bork another student’s prototype, they could just roll back to a previous snapshot and keep going¹.

Marking, too, would be as simple as snapshotting at the right time (or perhaps several snapshots—I think that marking the progression of these prototypes is going to be more important than marking the finished prototype). And I really like Fly’s commitment to fast-starting, on the web by default infra. I’ve been a happy user of their platform for a few years now and these sprites seem like a really interesting idea for teaching programming.

None of this works without some unglamorous plumbing underneath. Each week’s provocation—the starting point for that week’s prototype—is a template git repo. Every student forks it, does their work, and pushes. The last push before the deadline is what counts as their submission. This keeps things simple and auditable, and it means CI can check some of the invariants automatically: does the build step exit cleanly, does the served site return 200 OK on the required routes, are the process reflection .md files present in the repo, that sort of thing.

I’ve already got tooling that can batch clone and run tests across all student repos for a given class—plus a “badger” script that I run a few days before the deadline to send a courtesy email to anyone who hasn’t forked the template yet, gently suggesting they get started. Extending all of this to also provision and snapshot sprites per student is the next step, but the bones are there.

@online{swift2026comp4020SafetyYoloAndTheOpenWeb,
  author = {Ben Swift},
  title = {The road to COMP4020: safety, YOLO and the open web},
  url = {https://benswift.me/blog/2026/03/05/comp4020-safety-yolo-and-the-open-web/},
  year = {2026},
  month = {03},
  note = {AT-URI: at://did:plc:tevykrhi4kibtsipzci76d76/site.standard.document/2026-03-05-comp4020-safety-yolo-and-the-open-web},
}