Jeder neue Jahrgang von TUM.ai startet mit einem gemeinsamen Wochenende, irgendwo ruhig genug, dass sich niemand die ganze Zeit hinter dem Laptop verstecken kann. TUM.ai hat ein selektives Auswahlverfahren, das hier waren also keine zufälligen fünfunddreißig: es war ein Bus voller Leute, die schon echte Dinge geshippt und sich ihren Platz über eine kompetitive Bewerbung verdient hatten. Zwei Tage, um aus fünfunddreißig fähigen Fremden, die sich größtenteils noch nie gesehen hatten, so etwas wie ein Team zu machen. Mein Part in dem Ganzen war ein einziger Slot am Samstagnachmittag: einen Hackathon zu leiten.
Das Übliche wollte ich nicht. Ein ernster Hackathon am ersten Tag im Team ist ein stilles Desaster. Die halbe Gruppe ist eingeschüchtert, die starken Builder sprinten allein los, und alle lernen, dass man sich seinen Platz hier verdient, indem man schon gut ist. Also habe ich die Aufgabe umgedreht. Der Auftrag lautete, in zwei Stunden das Absurdeste zu bauen, das man sich ausdenken kann, und es zu pitchen.
Der Clou, und der Teil, der mir beim Entwerfen am meisten Spaß gemacht hat, war gar keine Jury. Statt dass ich vorne stehe und Bonus-Challenges verteile, habe ich einen kleinen Rat aus übertriebenen KI-Personas gebaut, denen die Teams ihre Idee gepitcht haben und die zurückgestritten und maßgeschneiderte Bonus-Challenges zugeworfen haben. Über den eigentlichen Sieger hat eine Abstimmung im Raum entschieden. Das ist der ehrliche Bericht darüber, warum ich es so aufgesetzt habe und wie es wirklich gelaufen ist.
Warum das Absurde der Punkt ist
Das Absurde ist ein Freifahrtschein. Sobald das offizielle Ziel ist, etwas Nutzloses und Schräges zu bauen, verfliegt die Angst, sich zu blamieren, denn sich zu blamieren ist die Aufgabe. Niemand schützt einen Ruf, den er noch gar nicht aufgebaut hat. Ein Erstsemester, der sich noch zurechtfindet, und ein Masterstudent, der beruflich shippt, spielen plötzlich dasselbe Spiel, denn egal wie gut du bist, beim Absurden hat niemand einen ernsthaften Vorsprung. In einem Raum, der so stark ist, zählt dieser Ausgleich mehr, nicht weniger: er verhindert, dass die schwersten Kaliber das Ganze still an sich reißen.
Es erreicht außerdem genau das, was Onboarding erreichen soll: Leute schnell ins Bauen und ins Reden miteinander zu bringen. Über die Architektur einer App, die bewertet, wie verflucht dein Kühlschrank ist, kann man nicht lange grübeln. Man fängt einfach an, streitet darüber, lacht, und irgendwo im Lachen werden aus vier Fremden eine Gruppe, die zusammen etwas gebaut hat. Der Satz, den ich ständig wiederholt habe: nützlich ist erlaubt, aber nützlich und schräg gewinnt den Raum. Funktionierende Software ist nicht optional. Geschmack schon.
Der Rat, der dich herausgefordert hat
Hier ist der Mechanismus, auf den ich stolz bin. Statt dass ich Bonusziele vorgebe, hat jedes Team seine Idee in einem einzigen Satz einem Rat aus fünf KI-Personas gepitcht, von denen jede eine Karikatur einer Denkweise über Softwarebau war. Sie haben nicht benotet. Sie haben etwa eine Minute lang in ihrer Rolle miteinander gestritten und dann vier bis sechs Bonus-Challenges zurückgegeben, zugeschnitten auf das absurde Ding, das das Team gerade beschrieben hatte. Die fünf Stimmen waren:
- Der Maximalist. Mehr. Alles draufstapeln. Jeder Regler auf elf, jedes Feature reingequetscht, Zurückhaltung ist etwas für Feiglinge.
- Der Minimalist. Eine Sache, perfekt umgesetzt. Alles andere wegschneiden, bis nur noch die Idee übrig ist.
- Der Chaos-Agent. Verfluchte Energie. Mach es schräg, mach es falsch, mach es zu der Sorte Ding, die man als Screenshot an Freunde schickt.
- Der Pragmatiker. Der Einzige im Raum, der fragt, ob irgendetwas davon in zwei Stunden kompiliert.
- Das Theaterkind. Aber wo ist der emotionale Spannungsbogen? Wo ist das Drama, die Enthüllung, der Moment, in dem das Publikum nach Luft schnappt?
Der Sinn von fünf widerstreitenden Stimmen war, dass keine einzelne recht hat, und die Teams konnten das spüren. Der Maximalist und der Minimalist können nicht beide gewinnen, also musste eine Gruppe entscheiden, welche Art von absurd sie sein wollte, und sich darauf einlassen. Teams durften so oft zum Rat zurückkommen, wie sie wollten, eine geschärfte Idee neu pitchen und frische Challenges abholen. Der Rat hat nie ein Urteil gefällt, er hat nur das Gespräch am Laufen gehalten, und genau diese Stimmung wollte ich am ersten Tag.
Die Regeln, und wie man wirklich gewonnen hat
Den Rahmen habe ich bewusst eng gehalten, denn Einschränkungen sind das, was einen kurzen Hackathon eher unterhaltsam als stressig macht. Vier Regeln, kein Kleingedrucktes:
- Zwei Stunden, harte Grenze. Vom Kickoff bis zum Demo. Die Uhr schert sich nicht um deine Träume.
- Gruppen bis vier. Wähle Rivalen oder Freunde, ein bis vier Personen, deine Entscheidung.
- Zwei-Minuten-Pitch. Hundertzwanzig Sekunden, um das absurde Ding live vor allen vorzuführen.
- Lass dich aufs Absurde ein. Nützlich ist erlaubt. Nützlich und schräg gewinnt den Raum.
Die Wertung war bei dreihundert Punkten gedeckelt, aus zwei Quellen, die man stapeln konnte. Bis zu hundert kamen vom Rat, aber nicht in gleichen Scheiben. Wenn die Personas einem Team seine Challenges zurückgaben, gewichteten sie jede einzelne, sodass die schwere, zentrale Challenge, die den ganzen Build ausmachte, fünfunddreißig Punkte wert sein konnte, während ein nebensächliches Easter Egg fünf wert war, und ein vollständiger Satz ergab immer hundert. Das hat Teams belohnt, die die harte, ideenprägende Arbeit angegangen sind, statt sich die billigen Punkte herauszupicken. Die anderen zweihundert, die größere Hälfte, kamen aus dem Raum: nach den Pitches haben alle abgestimmt, und diese Abstimmung hat den Sieger tatsächlich gekürt. Diese Aufteilung war wichtig. Die Bonus-Challenges des Rats hielten die Teams beim Bauen ehrlich, und die Community-Abstimmung sorgte dafür, dass der Abend dem gehörte, was fünfunddreißig müde Leute wirklich zum Lachen gebracht hat.
Zuerst ein Werkzeugkasten
Bevor die Uhr lief, habe ich eine kurze, praktische Einführung ins Arbeiten mit modernen KI-Coding-Assistenten gegeben. Die meisten im Raum kannten sich mit diesen Werkzeugen schon aus, das war also kein Unterricht bei null. Aber es gibt subtile Feinheiten und hart erarbeitete Kniffe, die das Herumstochern in einer Autovervollständigung davon trennen, einen Agenten über ein ganzes Repo planen, editieren, ausführen und Fehler beheben zu lassen, und genau die wollte ich weitergeben, bevor der Timer auf null sprang.
Ich habe es auf eine Handvoll Ideen beschränkt, die wirklich etwas bewirken. Schreib eine kurze Projekt-Anweisungsdatei, damit du nicht jede Sitzung deinen Stack neu erklärst. Plane, bevor du den Agenten editieren lässt, damit es günstig ist, ihn umzulenken, wenn er dich missversteht. Lager Recherche an einen separaten Agenten aus, damit dein Main Context sauber bleibt. Stütz dich für die langweiligen Wiederholungsschritte auf wiederverwendbare Befehle. Nichts davon ist kompliziert, und alles davon ist der Unterschied zwischen gegen das Werkzeug kämpfen und es für sich arbeiten lassen.
Der Satz, mit dem ich sie entlassen habe: das Modell ist schnell, der Flaschenhals ist dein Prompt. Sei konkret, gib ihm die Datei, die du meinst, lies das Diff, bevor du ihm vertraust, und committe oft, damit du eine schlechte Idee immer rückgängig machen kannst. Für einen Raum, der gleich unter Zeitdruck etwas bewusst Lächerliches bauen würde, war das genau die richtige Haltung: schnell sein, umkehrbar bleiben und die Maschine das Tippen erledigen lassen, während du das Denken übernimmst.
Wie es tatsächlich lief
Ehrlich gesagt lief es ungefähr so gut, wie ich es mir erhofft hatte. Der Hackathon hatte die Energie, die ich wollte. Der Rat-Teil kam an, Teams haben tatsächlich neu gepitcht, um mit ihm zu streiten, und ein paar der Demos waren die gute Sorte absurd, die, bei der der ganze Raum lacht und still beeindruckt ist, dass das Ding wirklich läuft. Zwei Minuten pro Gruppe auf einer Bühne, eine echte Community-Abstimmung und ein klarer Sieger sind ein Format, das ich wieder laufen lassen würde, ohne viel zu ändern.
Das Einzige, was ich wirklich ändern würde, sind die API-Credits. Wir haben die Modell-Credits, die die Teams brauchten, während des Events verteilt, und das hat lange genug gedauert, dass manche Teams ihre deutlich früher hatten als andere, was kein fairer Start in einen Build auf Zeit ist. Nächstes Mal gehen sie vorab an alle raus, gleichmäßig, bevor die Uhr läuft. Davon abgesehen würde ich am Format selbst nicht viel ändern.
Was sie tatsächlich gebaut haben
Ich will den Demos ihre Anerkennung geben, denn die Bandbreite der Ideen war das beste Argument für das ganze Format. Acht Teams, jeweils zwei Stunden, und kein einziges ist auf Nummer sicher gegangen.
Ein paar, die hängenblieben: Meowscript, das aus einem einzigen Katzenfoto ein vollständig formatiertes wissenschaftliches Paper macht, das eine völlig abgedrehte Verschwörungstheorie beweist, Katze als zitierte Primärquelle, und das Ganze dann mit der ernsten Stimme eines Dokumentationssprechers vorliest. Tumagochi, ein Tamagotchi, das du am Leben hältst, indem du es mit deinen echten Traumata fütterst, bewertet nach Rohheit und Einzigartigkeit. Snoozy, wo du mit deinem Wecker um das Recht auf Weiterschlafen diskutierst und dafür verurteilt wirst. Und schnell der Rest: Tinder für Haustiere mit einer einzigen vernichtenden Wischrichtung, GeoGuessr für Burghausen mit Lügenkompass-Modus, ein TUM.ai-Vorhersagemarkt, dessen Maskottchen sich mit deiner Wett-Treffsicherheit weiterentwickelt, und eine Browser-Erweiterung, die dich mit den Buchstaben K-A-N-Y-E überfällt. Die Fingerabdrücke des Rats waren überall an diesen Sachen. Der Auftrag war absurd. Die Umsetzung war es nicht.
Was ich mitgenommen habe
Das Erste ist, dass das Entwerfen eines Events eine eigene Art von Engineering ist, und eine befriedigende dazu. Du baust ein System, dessen Laufzeit fünfunddreißig Menschen sind und dessen Ergebnis ist, wie sie danach übereinander denken. Der Rat war ein kleiner, etwas alberner Mechanismus, aber er hat echte Arbeit geleistet, ist an die Stelle getreten, wo sonst eine Jury säße, und war stattdessen ein kreativer Partner, der nur Challenges verteilt hat, und hat nervösen Neulingen etwas gegeben, worauf sie reagieren konnten, statt eines leeren Blatts. Gute Einschränkungen tun das. Sie befreien Leute, statt sie einzusperren.
Das Zweite ist, was ein Raum wie dieser mit zwei Stunden und den richtigen Werkzeugen anstellt. Fünfunddreißig Leute, die sich an diesem Morgen größtenteils kaum kannten, haben vor dem Abendessen funktionierende, wirklich witzige Software geshippt: eine Katze, die wissenschaftliche Paper verfasst, ein Tamagotchi, das du mit deinem Trauma fütterst, ein Wecker, den du erst niederreden musst. Vor ein paar Jahren wäre dieser Nachmittag in diesem Tempo nicht möglich gewesen. Buildern dieses Kalibers schon an ihrem allerersten Wochenende diesen Hebel in die Hand zu geben und zuzusehen, wie ihnen klar wird, was sie plötzlich zusammen bauen können, war die bestmögliche Art, willkommen im Team zu sagen.
