What I Learned Running a Claude Hackathon with Erasmus AI Society

On 9 April, 130 students sat down at Erasmus University Rotterdam with Claude Code, a few hours and no shared definition of what “technical” was supposed to mean.

Some had built software before. Some had never opened a terminal. By the end of the day, 28 projects had been submitted.

That sounds like a story about a tool. It was really a story about permission.

Beginner-friendly cannot mean friction-free

The Erasmus Artificial Intelligence Society designed the event for curious students, not only computer science students. The invitation was simple: bring an idea you care about, form a team, use Claude to turn it into a working prototype, and show the room what you made.

I ran the technical side and joined the jury. My job was not to make the day look smooth. It was to help people keep moving when the interface, the code or their own idea stopped cooperating.

And the day was not smooth.

With that many builders in one room, support becomes a routing problem. Several teams get stuck at once. One person needs help understanding the terminal. Another has a broken data flow. A third has built exactly what they described and has just realised the idea is not useful.

A beginner-friendly buildathon should make those moments survivable. It should not pretend they will not happen.

Teach the loop, not the syntax

The useful unit of progress was not “learn Claude Code.” It was a much shorter loop:

• Describe the problem in plain language.

• Ask for the smallest version that can be tested.

• Run it.

• Look at what actually happened.

• Change the instruction or the product.

• Repeat.

People who understood that loop could recover. They did not need to know every command. They needed to know that the first output was evidence, not an answer.

This matters because AI tools create a peculiar kind of confidence. The first twenty minutes can feel miraculous. A page appears. Buttons work. The product has a name. Then the builder asks it to do something real and discovers the gap between a generated interface and a coherent system.

That gap is where the learning begins.

The room changed who could participate

The clearest moment came from the audience-award team. They arrived with no coding experience, were visibly confused during the tutorial, and still ended the day on the podium.

That was not proof that engineering no longer matters. It was proof that the entrance to building has moved.

The strongest teams were not simply the ones that produced the most code. They could decide what to leave out. They could explain the problem without hiding behind the technology. They could ask for help without handing the problem away.

In a seven-hour programme, roughly six hours of building forced those decisions into the open.

Working products made the judging better

Ten finalists showed the room what they had made. The winning projects covered very different problems:

• AI Scheduler helped students plan weekly tasks.

• Nodus turned learning material into a knowledge graph and a gamified path.

• EUR Connect explored how students could meet and communicate on campus.

• Village used a game mechanic to help friends stay connected over distance.

• Fluid Friction introduced physical resistance into scrolling to interrupt automatic behaviour.

The demos were imperfect. That was useful. A working product gives the jury something specific to question: who is this for, what happens at the edge case, what data does it need, and would someone use it twice?

A slide deck can glide past those questions. A product cannot.

One outcome continued well beyond the room. The builder behind Fluid Friction later released the app on iOS and Android and reported its first subscription. Not every buildathon project should become a company. But continuation is a better signal than applause.

What I would keep

Four decisions earned their place in the format.

One tool, one day

A narrow toolset reduced theatre. We did not run a parade of AI products. Claude Code was the working environment, and the challenge was to use it well enough to make an idea tangible.

Teams with mixed confidence

People learned from the person beside them, not only from the stage. A builder who understood product could improve the brief. Someone comfortable with code could unblock the system. A newcomer could ask the question everyone else had skipped.

A hard demo deadline

The deadline turned ambition into choices. Teams had to decide what the prototype needed to prove by the end of the day.

Prizes for different kinds of value

Alongside the main ranking, the audience and societal-impact awards made room for products that connected with people for different reasons. That helped keep “technical polish” from becoming the only definition of quality.

What I would change

I said after the event that it had been more chaotic than planned and that I could not help everyone the way I wanted. That remains the honest version.

Next time I would make the support system more explicit:

• a visible queue for technical help;

• short diagnostic prompts teams complete before asking for a mentor;

• clearer checkpoints for problem, working flow and demo;

• a rescue lane for first-time builders who lose too much time to setup;

• a continuation step for projects that want to keep going.

More mentors would help, but structure scales better than heroic support.

The real lesson was agency

The event was organised by Erasmus Artificial Intelligence Society with Anthropic, Yunus Noah Oberst, Elena Avramenko and the wider student team. The original event listing promised a beginner-friendly afternoon of building. The Erasmus AI Society recap and my own field note from the day record what followed.

But the number I keep returning to is not 130 or 28.

It is one: the first product someone built after assuming this work belonged to somebody else.

That shift is why I keep running these rooms. AI does not remove the need for technical judgment. It gives more people a way to enter the work, experience the constraints and decide whether they want to go further.

If your team needs that kind of entry point, see how we run AI workshops and buildathons. Bring a real problem. We will build from there.