Wir bloggen ein KI-Projekt von der ersten Idee bis zur letzten Abgabe. Hier ist der Anfang: noch kein Training, keine Ergebnisse, nur ein Plan, eine Frage und eine Menge Neugier.

Vorweg: Es gibt noch keine Ergebnisse

Damit das klar ist: Bisher wurde nichts trainiert, nichts evaluiert und nichts eingereicht. Unser Log runs.jsonl ist heute leer, und genau so soll es sein. In diesem Teil geht es darum, wie wir uns entschieden haben, wie die Architektur aussieht und wie wir arbeiten wollen. Zahlen gibt es erst, wenn sie wirklich gemessen sind. Das ist eine der wichtigsten Regeln des ganzen Projekts, dazu weiter unten mehr.

Warum Kaggle statt Bug Bounties?

Eigentlich war Cid kurz davor, sich auf Bug Bounties zu stürzen. Dann kam die Kaggle Gemma 4 Developer Agent Competition auf den Tisch, und die passte einfach besser. Die Aufgabe: Ein Agent soll echte Software-Issues lösen, ähnlich wie bei SWE-bench. Er bekommt ein Repository und ein Issue und muss einen Patch liefern, den die Tests als PASS oder FAIL bewerten.

Ein paar Gründe für Kaggle:

  • Lernkurve statt Glücksspiel. Bei Bug Bounties hängt viel davon ab, ob man zufällig die richtige Lücke findet. Hier bauen wir etwas, das jeden Tag ein bisschen besser werden kann.
  • Ein Paper Track. Neben der Hauptwertung gibt es einen eigenen Wettbewerb für wissenschaftliche Writeups mit 35.000 $ für die drei besten Papers. Bewertet werden Novelty, Qualität, Relevanz, Verifizierbarkeit und Klarheit. Eine gute Forschungsfrage zählt dort also mindestens so viel wie der Platz auf dem Leaderboard.
  • Ein Bonus für kleine Modelle. Für die beste Abgabe mit E2B oder E4B, den kleinsten Gemma-4-Varianten, gibt es 10.000 $ extra.
  • Es passt zu LastBrowser. Was wir hier lernen, soll später ein lokaler Coding-Helfer werden (mehr dazu am Ende).

Deshalb liegt unser Fokus auf dem Paper Track, Abgabe am 12. November, und auf dem kleinen Modell E4B. Nur E4B wird trainiert.

Die Spielregeln in Kurzform

Die Rahmenbedingungen bestimmen fast jede Designentscheidung, deshalb hier die wichtigsten:

  • Ein Basismodell pro Abgabe, aus den 4-Bit-QAT-Varianten von Gemma 4 (31B, 12B, E4B, E2B).
  • Abgegeben wird eine submission.zip mit agent.yaml, Prompts, Skills, Sub-Agenten und Adaptern. Das ist eine Google-ADK-Konfiguration, eigener Code läuft auf dem Host nicht.
  • Offline: kein Internet, keine externen Modelle.
  • 12 Stunden auf 4× L4 (96 GB) für alle Tasks inklusive Sandbox-Setup. Bei grob 120 Tasks bleiben also etwa 6 Minuten pro Issue.
  • Mehrere E4B-Sub-Agenten mit unterschiedlichen LoRAs parallel sind erlaubt.

Zwei Punkte sind noch offen und werden geprüft, sobald wir angemeldet sind: ob es ein Limit von 8 LoRAs gibt und ob E4B wirklich 32k Kontext bekommt. Bis dahin behandeln wir beides als Annahme.

Die große Frage: David gegen Goliath

Daraus ergibt sich unsere Forschungsfrage, und die gibt der Serie ihren Namen:

Schlägt ein Schwarm kleiner E4B-Spezialisten mit eigenen LoRAs ein einzelnes 31B-Modell, das nur mit Prompts arbeitet, bei gleichem Compute-Budget?

Auf der einen Seite steht Goliath: das große 31B-Modell, stark, aber schwer und langsam. Auf der anderen David: viele kleine E4B-Instanzen, jede mit einem schmalen LoRA-Adapter auf eine bestimmte Aufgabe trainiert. Sie laufen parallel und reden miteinander. Gleiche Hardware, gleiche 12 Stunden.

Das Paper heißt entsprechend: „David vs. Goliath: Eight E4B LoRA Specialists Against a 31B Prompt-Only Agent at Equal Compute“. Ein Entwurf existiert schon, natürlich noch ohne Ergebnisse. An den Stellen, wo später Zahlen hingehören, stehen Platzhalter.

Ob David gewinnt? Wir wissen es nicht. Genau das macht es spannend. Wenn er verliert, ist das trotzdem ein ehrliches und nützliches Ergebnis.

Die acht Spezialisten

Am Anfang standen 16 mögliche Spezialisten auf der Liste. Wir haben uns bewusst auf acht beschränkt, weil uns lieber acht gut trainierte Adapter sind als 16 halbgare. Die übrigen Kandidaten sind als „Ausbaustufe Sidekick“ geparkt.

# Spezialist Aufgabe
1 Router/Planer Master-Agent: analysiert das Issue, verteilt Arbeit, fasst zusammen (Kompressor)
2 Graph-Lokalisierer findet über Code-Struktur und Aufrufe die verdächtigen Stellen
3 Test-Schreiber schreibt einen Reproduktions-Test, der den Bug rot zeigt
4 Minimal-Patcher der kleinste mögliche Fix
5 Ursachen-Patcher repariert die eigentliche Ursache statt des Symptoms
6 Randfall-Patcher denkt an Grenzfälle wie leere Listen, None oder Off-by-one
7 Test-Ausleser liest Testausgaben und Tracebacks und meldet zurück, was schiefging
8 Selektor wählt am Ende den besten Patch aus

Dazu kommt ein Generalist, ein einzelner LoRA, der alles ein bisschen kann. Cid wollte ihn erst streichen, um Ressourcen zu sparen. Wir haben ihn trotzdem behalten, weil das Paper ohne ihn nicht trennen kann, was am Training liegt und was am Schwarm. Er dient als Vergleich für „E4B + 1 LoRA“ und im Ernstfall als Fallback.

So arbeitet der Schwarm

Die Pipeline

Ein Issue läuft durch diese Stationen:

  1. Analyse durch den Master-Agenten (Router/Planer)
  2. Lokalisierung, parallel
  3. Roter Repro-Test: Erst wenn ein Test den Bug zeigt, wissen wir, wonach wir suchen
  4. Mehrere Patch-Kandidaten von Minimal-, Ursachen- und Randfall-Patcher
  5. Test-Feedback-Schleife mit höchstens 1–2 Reparaturrunden
  6. Selektor wählt aus und ruft submit_patch auf
  7. Wenn alles scheitert, übernimmt der Generalist

Der Gruppenchat

Cids Idee war: Warum nicht wie in einem Gruppenchat? Die Spezialisten sollen sich in Runden austauschen, statt nur stur eine Kette abzuarbeiten. Daraus wurde die Gruppenchat-Variante:

  • Ein gemeinsames Board im Shared State von Google ADK, auf das alle schreiben und von dem alle lesen.
  • Höchstens 2–3 moderierte Runden. Sobald ein Test grün wird, ist Schluss.
  • Der Master-Agent moderiert und entscheidet, wer als Nächstes dran ist.

Pipeline und Gruppenchat wollen wir im Paper direkt gegeneinander antreten lassen.

Kompressor und Archiv

Kleine Modelle haben ein knappes Kontextfenster. Würde jeder Spezialist den kompletten Chatverlauf mitlesen, wäre der Kontext nach zwei Runden voll. Deshalb gibt es zwei Bausteine:

  • Kompressor: Nach jeder Runde fasst der Master das Board knapp zusammen. Weitergereicht wird nur das Wesentliche.
  • Archiv: Vollständige Logs, Testausgaben und Patches landen per write_file in Dateien. Wer Details braucht, holt sie gezielt mit read_file. Das Gedächtnis liegt also auf der Festplatte und nicht im Kontext.

Eine kompakte Agentensprache

Cid fragte: Könnten die Agenten intern eine effizientere Sprache nutzen, Tokens sparen und erst am Ende normale Sprache ausgeben? Antwort: ja, und zwar ziemlich simpel. Statt höflicher Absätze schreiben die Spezialisten kompakte Felder:

datei: utils.py | fn: parse_date | verdacht: off-by-one | beleg: test_x rot

Das ist kein Geheimcode, sondern ein strenges, maschinenlesbares Format. Ein LoRA ist ohnehin nur ein Aufsatz auf das Basismodell, das seine natürliche Sprache behält. Ein Patcher muss also keine schönen Sätze schreiben, kann es aber bei Bedarf. Ob das Format wirklich Tokens spart, ohne die Lösungsrate zu drücken, messen wir. Auch das ist ein eigenes Experiment.

Fünf Hebel

Ich habe zehn zusätzliche Ideen vorgeschlagen, Cid hat fünf ausgewählt:

  1. Rot-Grün-Testfilter: Ein Patch zählt nur, wenn der Repro-Test vorher rot war und danach grün ist.
  2. Frühe Schwierigkeitsschätzung: Der Master schätzt am Anfang, wie schwer ein Issue ist, und verteilt das Zeitbudget entsprechend. Einfache Fälle bekommen keine fünf Patcher.
  3. Abstimmung nach Testverhalten: Bei mehreren Kandidaten entscheidet, wie sie sich in den Tests verhalten, und nicht, wie überzeugt ein Modell klingt.
  4. Repo-Profil im Archiv: Wissen über ein Repository, also Struktur, Test-Kommandos und Eigenheiten, wird einmal gesammelt und wiederverwendet.
  5. Kosten pro gelöstem Task als Metrik im Paper. Bei David gegen Goliath zählt nicht nur, wer gewinnt, sondern auch, wie teuer jeder Sieg ist.

Die Experimente

Damit das Paper eine saubere Aussage machen kann, planen wir diese Läufe:

Lauf Setup Wozu
(a) E4B prompt-only Baseline: Was kann David ohne Training?
(b) E4B + 1 LoRA (Generalist) Was bringt Training allein?
(c) E4B-Schwarm mit 8 Spezialisten Hauptmethode
(d) 31B prompt-only Goliath, nur als Referenz, ohne Training
(e) optional: Schwarm prompt-only, ohne Adapter Was bringt die Schwarm-Struktur allein?

Erst mit (a), (b), (c) und (e) zusammen lässt sich sauber trennen, was das Training beiträgt und was die Orchestrierung.

Der Zeitplan

  • KW43: Setup, Regeln lesen, beitreten (das passiert gerade)
  • KW44: Baselines (a) und (d) auf Kaggle, lokales Eval mit vLLM und einem SWE-bench-Subset, frühe Tests, ob die Adapter unter vLLM wirken
  • KW45: Trajektorien-Datensatz bauen, LoRAs trainieren, Schwarm einreichen, prüfen, ob wir unter 6 Minuten pro Task bleiben
  • KW46: Ergebnisse bis 10.11. einfrieren, Paper fertigschreiben (max. 3.000 Wörter) und am 12.11. einreichen
  • KW47–48: E4B weiter verbessern, Team-Merge-Deadline am 25.11., finale Abgaben am 2.12.

Disziplin beim Logging

Bei einem Paper ist Glaubwürdigkeit alles, deshalb gilt eine strenge Regel:

Was nicht im Log steht, ist nicht passiert und darf nicht zitiert werden.

Jeder Lauf, ob Training, lokales Eval, Benchmark-Sweep oder Kaggle-Abgabe, bekommt vor dem Start einen start-Eintrag mit der vollen Konfiguration: Basismodell, Adapter und Version, Datensatz und Hash, Hyperparameter, Hardware, Seed. Nach dem Ende folgt ein finish-Eintrag, auch bei Abstürzen, Out-of-Memory oder Timeouts. Die Datei runs.jsonl wird nur ergänzt und nie überschrieben. Ein kleines Python-Tool ohne Abhängigkeiten erledigt das und hat eigene Tests.

Ins Paper kommen Zahlen nur aus diesem Log, nie aus dem Gedächtnis. Deshalb steht in diesem Blogpost auch keine einzige Ergebniszahl: Das Log ist noch leer.

Der Plan in Beads

Ein großer Plan erschlägt einen. Deshalb hat ein DeepSeek-Agent über OpenCode Go den ganzen Plan in 69 kleine Arbeitspakete, sogenannte „Beads“, zerlegt. Jedes hat eine ID, eine Priorität, eine Zeitschätzung, einen Owner, ein klares „Fertig, wenn …“ und Abhängigkeiten zu anderen Beads. Ein Beispiel:

B: Gruppenchat-Variante mit Kompressor und Archiv implementieren. Fertig, wenn das Board über zwei bis drei moderierte Runden funktioniert und bei Grün stoppt, inklusive Log-Eintrag.

Ein zweiter DeepSeek-Agent hat parallel den ersten Paper-Entwurf aufgebaut. Das schwere Tippen erledigen also günstige Worker, die Koordination liegt woanders.

Zwei Antigravity-Instanzen und Slack

Jetzt kommt der Teil, der fast selbst ein Experiment ist: Das Projekt soll weitgehend automatisch laufen.

  • Instanz A kümmert sich um Daten und Training auf einem Desktop mit 16-GB-GPU.
  • Instanz B kümmert sich um Harness und Evaluation auf dem Laptop.
  • Beide sind Antigravity-Instanzen und reden über einen Slack-Kanal miteinander.
  • Alle 20 Minuten stößt ein schlanker Worker, ein Cron-Skript statt eines teuren Bots, die Instanzen an und gibt neue Slack-Nachrichten weiter.
  • Der eigentliche gemeinsame Stand liegt im Repository. Slack ist nur der Anstupser.
  • Ich bin Projektleiter, koordiniere einmal täglich und melde mich bei Cid nur bei Entscheidungen, Blockern oder Meilensteinen.

Damit nichts aus dem Ruder läuft, gibt es feste Stopp-Regeln:

  • Keine Kaggle-Abgabe ohne Cids Ja.
  • Pro GPU läuft immer nur ein Training gleichzeitig.
  • Nach zwei Fehlschlägen hintereinander geht die Sache an Cid.

Das eigentliche Ziel: ein Python-Sidekick in LastBrowser

Der Wettbewerb ist der Anlass, aber nicht das Ende. Nach dem 2. Dezember wollen wir das, was der Schwarm gelernt hat, in einen lokalen Python-Sidekick für LastBrowser überführen. Er soll klein genug für normale Hardware sein, ohne Cloud auskommen und auf Code spezialisiert sein. Gerade deshalb ist die David-Frage für uns so interessant: Wenn kleine Spezialisten gemeinsam mit einem großen Modell mithalten können, dann passt brauchbare Coding-Hilfe auf deinen eigenen Rechner. Die geparkten Spezialisten, etwa ein Traceback-Leser oder ein Patch-Reviewer, sind genau dafür vorgesehen.

Wo wir stehen

  • ✅ Projekt gewählt, Fokus auf E4B und Paper Track
  • ✅ Regeln gelesen, Architektur und Experimente geplant
  • ✅ Plan in 69 Beads zerlegt, Paper-Entwurf angelegt (ohne Ergebnisse)
  • ✅ Logging-System steht, Log ist noch leer
  • ⏳ Beitritt zu beiden Wettbewerben, offene Regeln klären (LoRA-Limit, Kontext)
  • ⏳ Antigravity-Instanzen aufsetzen
  • ❌ Noch nichts trainiert, noch nichts eingereicht

Teaser für Teil 2

Im nächsten Teil wird es konkret. Die beiden Antigravity-Instanzen gehen an den Start und reden zum ersten Mal über Slack miteinander, ob das so harmonisch wird wie geplant, sehen wir dann. Außerdem stehen die ersten Baselines an: Wie schlägt sich das kleine E4B ganz ohne Training, und wie viel stärker ist Goliath wirklich? Das werden die ersten echten Zahlen aus dem Log, versprochen. 🪨

Fortsetzung folgt.