Every new batch of TUM.ai members starts with a weekend away together, somewhere quiet enough that nobody can hide behind their laptop the whole time. TUM.ai runs a selective intake, so this was not a random thirty-five: it was a busload of people who had already shipped real things and earned their place through a competitive application. Two days to turn thirty-five sharp strangers, most of whom had never met, into something resembling a team. My job in all of it was a single slot on the Saturday afternoon: run a hackathon.
I did not want the usual thing. A serious hackathon on day one of someone's time on a team is a quiet disaster. Half the room is intimidated, the strong builders sprint off alone, and everyone learns that the way you earn your place here is by already being good. So I flipped the brief on its head. The task was to build the most absurd thing you possibly could, in two hours, and pitch it.
The twist, and the part I had the most fun designing, was not a judging panel at all. Instead of me standing at the front handing out bonus challenges, I built a small council of exaggerated AI personas that teams pitched their idea to and that argued back, throwing tailored bonus challenges at whatever they had just described. The actual winner was decided by a vote from the room. This is the honest account of why I set it up that way and how it actually played out.
Why absurd is the point
Absurd is a permission slip. The moment the goal is officially to build something useless and weird, the fear of looking stupid evaporates, because looking stupid is the assignment. Nobody is protecting a reputation they have not built yet. A first-year still finding their feet and a master's student who ships for a living are suddenly playing the same game, because however good you are, nobody has a serious head start on absurd. In a room this strong, that leveller matters more, not less: it stops the heaviest hitters from quietly running away with it.
It also does the one thing onboarding is supposed to do, which is get people building and talking to each other fast. You cannot agonise over architecture for an app that ranks how cursed your fridge is. You just start, you argue about it, you laugh, and somewhere in the laughing four strangers turn into a group that has shipped something together. The rule I kept repeating was that useful is allowed, but useful and weird wins the room. Working software is not optional. Taste is.
The council that challenged you
Here is the mechanic I am proud of. Rather than me dictating bonus objectives, each team pitched their idea in a single sentence to a council of five AI personas, each one a caricature of a way of thinking about building software. They did not grade. They argued with each other for about a minute, in character, and then handed back four to six bonus challenges tailored to whatever absurd thing the team had just described. The five voices were:
- The maximalist. More. Stack everything. Every dial turned to eleven, every feature crammed in, restraint is for cowards.
- The minimalist. One thing, executed perfectly. Cut everything else until only the idea is left.
- The chaos agent. Cursed energy. Make it weird, make it wrong, make it the kind of thing people screenshot and send to a friend.
- The pragmatist. The only one in the room asking whether any of this compiles in two hours.
- The theatre kid. But what is the emotional arc? Where is the drama, the reveal, the moment the audience gasps?
The point of five clashing voices was that no single one of them is right, and the teams could feel that. The maximalist and the minimalist cannot both win, so a group had to choose what kind of absurd they were going to be and lean in. Teams could come back to the council as often as they liked, re-pitch a sharpened idea, and get fresh challenges. The council never handed down a verdict, it just kept the conversation going, which is exactly the mood I wanted on day one.
The rules, and how you actually won
I kept the framing deliberately tight, because constraints are what make a short hackathon fun rather than stressful. Four rules, no fine print:
- Two hours, hard cap. From kickoff to demo. The clock does not care about your dreams.
- Groups up to four. Pick rivals or friends, one to four people, your call.
- Two-minute pitch. A hundred and twenty seconds to demo the absurd thing live, in front of everyone.
- Embrace the absurd. Useful is allowed. Useful and weird wins the room.
Scoring topped out at three hundred points from two sources you could stack. Up to a hundred came from the council, but not in equal slices. When the personas handed back a team's challenges they weighted each one, so the heavy, central challenge that defined the whole build might be worth thirty-five points while a throwaway easter egg was worth five, and a full set always added up to a hundred. That rewarded teams that took on the hard, idea-defining work instead of cherry-picking the cheap wins. The other two hundred, the bigger half, came from the room: after the pitches, everyone voted, and that vote was what actually crowned the winner. Splitting it that way mattered. The council's bonus challenges kept teams honest about building, and the community vote made sure the night belonged to whatever genuinely made thirty-five tired people laugh.
A toolbox first
Before the clock started I gave a short, hands-on intro to working with modern AI coding assistants. Most of the room already knew their way around these tools, so this was not teaching from zero. But there are subtle nuances and hard-won tips that separate poking at an autocomplete from letting an agent plan, edit, run, and fix across a whole repo, and those were what I wanted to pass on before the timer hit zero.
I kept it to a handful of ideas that actually move the needle. Write a short project instruction file so you stop re-explaining your stack every session. Plan before you let the agent edit, so it is cheap to redirect when it misunderstands you. Delegate research to a separate agent so your main context stays clean. Lean on reusable commands for the boring repeated steps. None of it is complicated, and all of it is the difference between fighting the tool and flying with it.
The line I left them on was that the model is fast and the bottleneck is your prompt. Be specific, give it the file you mean, read the diff before you trust it, and commit often so you can always undo a bad idea. For a room about to build something deliberately ridiculous under time pressure, that turned out to be exactly the right mindset: move fast, stay reversible, and let the machine do the typing while you do the thinking.
How it actually went
Honestly, it went about as well as I could have hoped. The hackathon had the energy I was after. The council bit landed, teams genuinely re-pitched to argue with it, and a couple of the demos were the good kind of stupid, the kind where the whole room is laughing and quietly impressed that the thing actually runs. Two minutes per group on a stage, a real community vote, and a clear winner is a format I would run again without changing much.
The one thing I would genuinely fix is the API credits. We handed out the model credits teams needed during the event, and distributing them took long enough that some teams had theirs well before others, which is not a fair way to start a timed build. Next time they go out to everyone up front, evenly, before the clock starts. Beyond that, I would not change much about the format itself.
What they actually built
I want to give the demos their due, because the spread of ideas was the best argument for the whole format. Eight teams, two hours each, and not one of them played it safe.
A few that stuck: Meowscript, which turns a single cat photo into a fully formatted academic paper proving an unhinged conspiracy theory, cat cited as a primary source, then reads it aloud in a grave documentary-narrator voice. Tumagochi, a Tamagotchi you keep alive by feeding it your real traumas, scored on rawness and uniqueness. Snoozy, where you argue your alarm clock for the right to keep sleeping and get sentenced for it. And a quick run of the rest: Tinder for pets with a single damning swipe, GeoGuessr for Burghausen with a lying-compass mode, a TUM.ai prediction market whose mascot evolves with your betting accuracy, and a browser extension that ambushes you with the letters K-A-N-Y-E. The council's fingerprints were all over each of them. The brief was absurd. The execution was not.
What I took away
The first thing is that designing an event is its own kind of engineering, and a satisfying one. You are building a system whose runtime is thirty-five people and whose output is how they feel about each other afterwards. The council was a small, slightly silly mechanic, but it did real work, standing in for what would normally be a judging panel and instead acting as a creative partner that only ever handed out challenges, giving nervous newcomers something to react to instead of a blank page. Good constraints do that. They free people up rather than boxing them in.
The second is what a room like this does with two hours and the right tools. Thirty-five people, most of whom barely knew each other that morning, shipped working, genuinely funny software before dinner: a cat that authors academic papers, a Tamagotchi you feed your trauma, an alarm clock you have to out-argue. A few years ago that afternoon would not have been possible at this speed. Handing builders this sharp that kind of leverage on their very first weekend, and watching them realise what they could suddenly make together, was the best possible way to say welcome to the team.
