Cycles of Learning
← All writing
Oct 7, 2026·6 min read

Building the T4SG Class Hub

Back in 2017 I wrote about my first assistive technology course, a two-week Intersession built on MakeyMakeys and Arduinos. The idea that stuck with me from that class was simple: when you hand a teenager a soldering iron and a real person to design for, the work stops being about the grade.

Nine years later, that idea is a full course. Tech for Social Good (formerly Design for Social Good) is a semester of adaptive switches, sensors, and controllers built for specific people with specific goals. And now the whole class lives in one place: a hub I built myself at t4sg-at-sa.vercel.app.

The T4SG hub's Projects page, showing Project 0 through Project 2 as rows of benchmark cards The Projects page. Every benchmark is a card, and every card shows how many students have dropped work into it.

What kept bugging me

For years this class ran on a patchwork. Instructions in a Google Doc, code in the Arduino IDE, wiring diagrams in Tinkercad Circuits, CAD in a different tab, photos in a camera roll, videos in a Drive folder. Students did beautiful work, and then it scattered. When it came time to grade a final product, I was chasing six files across five platforms per kid, and the kids were spending more energy on logistics than on the person they were designing for.

The other thing that bugged me was the arc. Each project felt like its own island. Students would build a lever switch, take it apart, and start over with a sensor. Nothing accumulated, so nothing compounded.

So I did what I wrote about in Build the Tool, Don't Find the Tool. I stopped looking for a platform and built one.

One connected project, not four islands

The hub organizes the semester into five projects: Project 0: Meet the Mission, Project 1: Basic Adaptive Switches, Project 2: No-Force Sensors, Project 3: Hands-Free Controls, and Project 4: Adaptive Controller Hub. Project 0 opens the mission through five short stories. Projects 1 through 4 are each a chain of two-point benchmarks (Button, Lever, LED, and so on) that ends in a 50-point Product.

The rule that holds it all together: nothing gets unplugged. Your Project 1 final product is where Project 2 starts. Your Project 2 final product, with Project 1 still inside it, is where Project 3 starts. By the time students reach the hub in Project 4, they are carrying one board with every input they have ever built still wired in and still working. The arc is literally on their breadboard.

The person comes first

Every Product opens with a brief, not a rubric. A short story, then a How might we question, then the constraints.

The Project 1 Product brief, with a How Might We question and six constraint cards The Project 1 Product brief. The person is the first thing students see.

Then students choose who they are designing for. Each card leads with what the person wants to do and what their body CAN do reliably. The diagnosis sits at the bottom, in small type, as context, not as an identity.

Four Project 1 user cards, each with a goal, a reliable motion, and an action map Four people, four very different motions, so designs diverge across the class.

Where the AI actually lives

Here is the part I have been thinking about the most.

The hub is a very human thing. It exists so that a teenager can build a switch that lets someone play Geometry Dash with her brother. But I built every line of it by vibe coding: describing what I wanted to an AI coding agent, testing it in my classroom, and going back with what broke. The Arduino Code Loading Tool, Wiring Schematic, Idea Board, Image Capture, Rubric & Drop, Exhibit, and daily warm-ups. None of it would exist if I had to write it by hand, and none of it would exist if I hadn't spent years in this room learning what these kids actually need.

For students, the AI sits in one very specific spot: writing Arduino code. Each benchmark gives them a short, precise prompt to paste into Gemini or ChatGPT, along with a starter prompt that tells the AI exactly which board and parts they have and to keep the code as simple as possible.

The Lever benchmark step with a copyable prompt asking the AI to add an A key on a lever switch without changing existing wiring Every prompt has guardrails: keep what you already have, add only the new part, simplest possible code.

Then they paste the code into the hub and upload it straight to their Arduino from the browser.

The Arduino Code Loading Tool, with a starter prompt banner, a code editor, Upload, Serial Monitor, and Save to benchmark buttons The Arduino Code Loading Tool. Write the code with an AI, paste it here, click Upload.

I want to be honest about how I got here. My first version had an AI chat built right into the hub. It seemed like the obvious move. It wasn't. One student wrote in their Project 1 reflection that the built-in tool "kept making weird code," so they took it to Gemini, got it fixed, and brought it back. By the end, they wrote that the project taught them a lot about how AI coding agents differ. On September 26 I pulled the built-in AI out entirely. Students now prompt the tools the rest of the world uses, and the hub stays focused on what only it can do.

That is the nuance I keep landing on. AI is incredible at the parts of this work that are pure syntax. It has no idea what it feels like to press a button with your forearm. The sketch, the user, the mount, the testing, the redesign: that is all human, and the hub is built to protect that time, not to automate it.

The artifacts are theirs

Every Product asks for the same seven pieces: a sketch made before building, the CAD file, the code, a wiring schematic, a photo, a video of the device in use, and a written reflection. The tools inside the hub (Idea Board, Wiring Schematic, Arduino Code Loading Tool, and Image Capture) each have a Save to benchmark button, so the work lands in the right slot without a single download.

The Rubric & Drop panel, listing Sketch, CAD, Code, Wiring, Image, and Video with point levels and a drop slot for each The rubric IS the checklist. Each row is a slot students drop into.

Here is what that looks like in one Project 1 submission, start to finish. The design gives the user a way to tell a teacher "I need a break" without speaking, plus a second button for "I'm ready to continue."

An Idea Board sketch, a Wiring Schematic, and the finished 3D-printed box with two engraved buttons reading I NEED A BREAK and READY TO CONTINUE

Sketch, schematic, build. One student's Project 1 Product.

Their reflection made me smile. After really struggling with the code on the Lever and LED benchmarks, this time "the code was perfect on the first try." The hard part was soldering. That is exactly the kind of struggle I want them to have.

Eighteen students turned in a Project 1 Product, and no two look alike.

Six different student Project 1 products: a two-button board, a two-pad green base, a Geometry Dash setup, a large black dome switch, a padded round switch, and a white button engraved Press Same parts bin, same rubric, six very different answers to "who is this for?"

Where it goes from here

The best work ends up in the Exhibit, a quiet wall of past student builds, Instructables, and websites that new students can browse.

Two cards in the T4SG Exhibit linking to past assistive technology builds A corner of the Exhibit. Past work becomes the hook for the next class.

I honestly don't know yet what this class looks like when it reaches Project 4 and every student is soldering their cumulative board into a single hub. I am sure something will break, and I'll vibe code a fix that night. What I do know is that, for the first time, the tool fits the class instead of the other way around. The AI wrote a lot of code this year. The students made all of the things that matter.

ShareXLinkedIn

Keep reading

New writing, when there is something worth sharing.

Notes on curiosity, inquiry, science teaching, and building the lesson.

No spam. Unsubscribe anytime. Prefer RSS?