What a builder club at HUST should look like

Hanoi University of Science and Technology has around 35,000 students and no shortage of clubs where people build software together. The number of them where students regularly ship things with AI agents — not "ask ChatGPT for homework", but build a working tool on top of a model and put it in front of other people — is close to zero.

That's not because HUST students can't. It's because nobody's set up the room.

I've spent close to three years setting up rooms: GDG on Campus at HUST from late 2023, then the GDG Hanoi core team from 2024, then leading the Northern region of a nationwide student hackathon in 2026. And for the last year I've been building with Claude Code every day, including OpenMem, an open-source memory layer for it. This post is the club I'd build if I combined the two. I'm writing it down because plans that exist only in my head don't survive contact with a semester.

The one rule

Nothing counts until it's in front of someone else.

Not a slide. Not a repo nobody's cloned. A thing that another student used, or a demo a room watched. Everything below is designed to force that.

Four rituals, one semester

A club that meets "whenever" dies by week six. A club with a fixed rhythm survives midterms. Here's the rhythm:

1. Build Night — every other week, 2 hours, laptops open

No talks. Everyone comes with something they're building and leaves with it further along. The first 15 minutes is a lightning round: each person says in one sentence what they're stuck on. The next 90 minutes is people pairing on those. The last 15 is show-what-changed.

The AI angle is concrete: every Build Night has a "prompt of the night" — a workflow someone found useful this week (a Claude Code skill, an MCP server, an eval trick) demoed in five minutes at the start. Fluency spreads by watching someone's screen, not by reading a guide.

2. Workshop — once a month, 90 minutes, one skill

Hands-on, one skill per session, and the skill is chosen because it unblocks what people are building. The first four I'd run:

1. From chat to agent — give Claude a tool. Function calling, one MCP server, one real API. Everyone leaves with an agent that does one thing.
2. Memory and retrieval — why your agent forgets, and how to fix it. FTS vs vectors, when you need neither. (I have opinions.)
3. Evals before demos — write the 20 test cases first. The workshop where people find out their agent was wrong 30% of the time and didn't know.
4. Shipping — Cloud Run, a domain, a URL you can text to a friend.

Where the Claude Campus program helps: guest speakers from Anthropic on one or two of these, and API credits so students aren't paying to learn. Where I help: I've taught versions of 1, 2 and 4 already, informally, and I know which parts people get stuck on.

3. Demo Night — end of month, open to the whole campus

Five minutes per project, a projector, anyone can come. This is the ritual that does most of the work: it's the deadline that makes Build Nights matter, the recruiting event that brings new people in, and the thing that makes the club visible to faculty.

I've run demo day for 98 teams across the Northern region. The rules that make them good: hard time limit, live demo required (video only if the demo needs hardware), and one question from the audience per project. Judging optional; applause mandatory.

4. The Hackathon — once a semester, 48 hours

By month three the club has 20–30 people who've each shipped something small. The hackathon is where they ship something big, in teams, with a theme. It's also where the club stops being mine.

I know how to run these. What I'd do differently from the big regional ones: smaller (30–60 people), themed around a real problem on campus (the timetable system, the library, the canteen queue — students know what's broken), and with mentors who are club members from last semester rather than outside guests. A hackathon run by the people it's for.

What "succeeded" would mean

I'm allergic to community metrics that count attendance. The numbers I'd actually track:

• Projects with a URL — things that exist outside a laptop. Target: 15 in the first semester.
• Demo-to-demo retention — did the people who demoed in month 1 demo again in month 2? If not, the Build Nights aren't working.
• Second-semester leads — at least three people who aren't me running rituals by the end of semester one. This is the hackathon rule applied to the club itself: it's not finished until someone else can run it.
• Cross-pollination — at least one project where a non-CS student (there are 20 other schools at HUST) built something with a CS student. AI fluency isn't a CS thing.

What I'd need

Honestly: not much. A room with a projector every other week (the university has these; the paperwork is the work). API credits so cost isn't a barrier to learning. A couple of guest sessions from people who build these systems for a living. And a stipend that lets me treat this as a job for a year instead of a thing I do after my job.

The rest — the runbooks, the check-in sheets, the demo-night format, the "what to do when the speaker's slides won't load" — I already have, from three years of running bigger rooms than this one.

Why I'm writing this now

Because I've watched a lot of students say "I'm interested in AI" and never ship anything, and I've watched a few ship something in a weekend and get hired for it. The difference was never talent. It was having a room, a deadline, and someone next to them who'd done it once before.

I'd like to be that someone at HUST. If you're a student here and this sounds like the club you wish existed, email me — tell me what you'd build in the first month, and I'll tell you which Build Night to come to.