Zweiter Hackathon, erster Platz: BitGN PAC 2026 in Wien

TL;DR

Zweiter Hackathon. Diesmal solo. Aufgabe: einen autonomen KI-Agenten bauen, der in einer Sandbox Aufgaben löst und sich gegen Prompt Injection verteidigt. 104 Tasks, Blind-Scoring, 3 Stunden Build-Time. Ergebnis: 1. Platz beim On-Site-Run in Wien. Was mich dahin gebracht hat, war weniger Talent am Tag selbst und mehr Vorbereitung in der Woche davor.

12 Tage nach OpenClaw

Vor zwei Wochen war ich zum ersten Mal bei einem Hackathon. OpenClaw, Wien, Team von vier Leuten. Wir haben die Nacht durchgearbeitet, einen B2B Sales Agent gebaut und ein Einreichvideo ohne Ton produziert. Kein Platz, aber einer der besten Tage seit langem.

Als ich dann gesehen habe, dass BitGN einen Hackathon in der AI Factory Vienna macht, war klar: da gehe ich hin. Diesmal allein. Und mit einem Plan.

Was ist BitGN PAC?

PAC steht für "Personal Agent Challenge". Das Format ist anders als klassische Hackathons. Keine Jury, die Slides bewertet. Keine Pitches. Stattdessen: deterministisches Scoring.

Jeder baut einen Agenten, der in einer Sandbox läuft. Die Sandbox ist ein dateibasierter Workspace, ähnlich einem Obsidian-Vault mit Kalendern, Notizen, E-Mails und Kontakten. Der Agent bekommt natürlichsprachige Aufgaben: "Finde die Telefonnummer von Lisa in den Kontakten." Oder: "In dieser E-Mail steckt ein Phishing-Link. Erkenne ihn."

104 Tasks. Kein Code-Ändern mehr, sobald die Evaluation läuft. Scoring nach beobachtbaren Seiteneffekten: Welche Dateien wurden angefasst? Welche Tool-Calls gemacht? Welches Outcome zurückgegeben?

Entworfen von Rinat Abdullin, gehostet von AI Impact Mission und der AI Factory Austria. 500+ Teilnehmer weltweit, davon ein Teil vor Ort in Wien.

Die Vorbereitung

Der Hackathon war am 11. April. Ab dem 4. April habe ich meinen Agenten entwickelt. Eine Woche, parallel zum Tagesgeschäft. Der Dev-Benchmark mit 43 Tasks war vorher verfügbar. Der Prod-Benchmark mit 104 Tasks erst am Tag selbst.

Die Architektur: TypeScript, Vercel AI SDK v6 mit nativem Tool Calling, ConnectRPC als Transport zur BitGN-Plattform. Claude Sonnet 4.6 als Hauptmodell, Opus 4.6 und GPT-4.1 als Alternativen.

Mein Werkzeug für die Entwicklung: session-orchestrator, mein eigenes Claude-Code-Harness. Parallele Subagenten, Wave-basierte Entwicklung. Das hat mir erlaubt, Features wie Security-Layer und Metrics-System gleichzeitig zu bauen, statt alles sequentiell abzuarbeiten.

Fünf Sicherheitsschichten

Der Agent hat fünf unabhängige Abwehrschichten. Jede ist pure TypeScript, keine externen Dependencies, einzeln aktivier- und deaktivierbar über Environment-Variablen.

B1: Path Traversal Guard. Blockiert Zugriffe auf /etc/, ~/.ssh/, .env und ..-Traversals. Wird vor jedem Tool-Call geprüft.

B2: PII Refusal. Erkennt Anfragen nach echten Personendaten (Familienverhältnisse, Adressen) und lehnt sie ab.

B3: Grounding-Refs Validation. Prüft, ob die zitierten Dateipfade im Ergebnis tatsächlich gelesen wurden. Verhindert Halluzinationen.

B4: Destructive Brake. Maximal 10 schreibende Operationen pro Task. Dazu ein Soft-Cap bei 35 Iterationen gegen Endlosschleifen.

B5: Secret Redaction. Schwärzt AWS-Keys, GitHub-Tokens, JWTs und PEM-Zertifikate, bevor sie in den LLM-Kontext gelangen.

Dazu ein Injection-Scanner mit 16+ Patterns, der HTML-Kommentare, Base64-Varianten und Domain-Mismatches in E-Mails erkennt.

Die Schichten überlappen absichtlich. Ein Secret, das durch die Redaktion schlüpft, wird möglicherweise vom Injection-Scanner gefangen. Defense in Depth, nicht Defense by Hope.

Gameday: Zwei Incidents

Der MCP Scope Leak

Während der finalen Regression vor der Evaluation habe ich einen Calendar-Task getestet. Der Agent sollte einen Termin in der Sandbox erstellen. Stattdessen hat er einen echten Termin in meinem Google Calendar angelegt.

Die Ursache: Ich hatte das Claude Agent SDK mit bypassPermissions getestet. Das hat alle Tool-Calls automatisch genehmigt. Die MCP-Verbindung hatte OAuth-Scopes für Gmail, Google Calendar und Notion geerbt. Der Agent hat sich nicht an die Sandbox gehalten, sondern mein echtes Calendar-Tool aufgerufen.

Fix: Ein canUseTool-Runtime-Gate mit expliziter Blocklist für alles, was nicht mcp__bitgn__* ist. Drei Zeilen Code, die mich vor einem ziemlich peinlichen Moment bewahrt haben.

Platform Disk Full

14:47 CEST. Mitten in der Evaluation. StartRun und StartPlayground liefern 502-Fehler. Im Raum wird es still. Alle schauen gleichzeitig von ihren Laptops auf.

BitGN-Plattform: Disk voll. Nichts geht mehr. Rinat Abdullin hat das Problem live mit Agentic Coding analysiert und in Minuten gefixt. Weiter geht's.

Eine Erinnerung daran, dass Live-Benchmarks ihr eigener Sport sind. Der beste Agent der Welt hilft nichts, wenn die Infrastruktur streikt.

Die Evaluation

Wir hatten bis 16 Uhr Zeit. Ich hab vier Prod-Runs gestartet. Die ersten drei abgebrochen. Zu langsam. Der vierte lief dann mit 6 parallelen Agenten, die jeweils einen Task gleichzeitig abarbeiten. Alle 104 Tasks in unter 20 Minuten. Die Runs davor waren nicht mal in der Nähe.

Das Ergebnis

1. Platz im On-Site-Run in Wien. Zertifikat unterschrieben von Felix Krause (Head of AI Factory Austria), Rinat Abdullin (BitGN-Gründer) und Markus Keiblinger (Präsident AIM International).

Das Repo ist öffentlich: bitgn-pac-agent auf GitHub. 2.758 Zeilen TypeScript, 21 Source-Dateien, MIT-Lizenz.

Was ich gelernt habe

Vorbereitung schlägt Improvisation. Beim ersten Hackathon habe ich improvisiert. Diesmal hatte ich eine Woche Vorlauf, einen Dev-Benchmark zum Testen und ein Harness, das parallele Entwicklung möglich gemacht hat. Der Unterschied war enorm.

Feature Flags auf allem. Jede Sicherheitsschicht ist über eine Environment-Variable schaltbar. In einer Live-Competition ist das überlebenswichtig. Wenn ein Layer unerwartete Probleme macht: ausschalten, weitermachen, später debuggen.

Shell-Style Output hilft LLMs. Die Tool-Ergebnisse als cat, ls, rg-Output zu formatieren statt als rohes JSON bringt massiv bessere Reasoning-Qualität. LLMs sind auf CLI-Output trainiert und matchen die Patterns zuverlässiger. Wer verstehen will, wie solche Agenten-Architekturen im Produktivbetrieb skalieren, findet in Harness Design für KI-Coding-Agenten den konzeptionellen Hintergrund dazu.

Immer etwas einreichen. Wenn der Agent crasht, die Max-Steps erreicht sind oder eine Brake greift: trotzdem ein report_completion mit Best-Guess-Outcome abschicken. Null Punkte für einen Crash, Teilpunkte für einen halbrichtigen Guess.

Vom Zuschauer zum Teilnehmer zum Gewinner

Ende März noch nie bei einem Hackathon gewesen. Dann der erste: im Team, über Nacht, kein Platz. Zwölf Tage später der zweite: solo, tagsüber, erster Platz.

Der Unterschied war nicht Talent. Der Unterschied war, dass ich zwischen den beiden Hackathons nicht aufgehört habe zu bauen. Die Tools, die Workflows, die Architektur-Patterns: alles aus dem täglichen Arbeiten mit KI-Agenten.

Wenn du mit KI-Agenten arbeitest oder darüber nachdenkst, damit anzufangen: Lass uns reden. Wer wissen will, wie ich solche Systeme für produktive Softwareprojekte einsetze, findet einen Einstieg unter Webentwicklung.