Wie wir 98 Pull Requests in vier Tagen gemerged haben
Wir bauen für uns. Wir bauen für euch.
Wie Brumm Labs in vier Tagen 98 Pull Requests durch eine selbstgebaute KI-Pipeline gemerged hat und warum genau das die Methode ist, mit der wir auch eure Software bauen.
Der Moment, an dem es klar wurde
Es war ein Donnerstag im April. Auf dem Bildschirm tickerten die Discord-Nachrichten im Sekundentakt:
Wir saßen in der Küche, tranken Kaffee, redeten über andere Dinge. Im Hintergrund baute sich unser Produkt selbst weiter. Story für Story, Funktion für Funktion. 35 Merges an einem einzigen Tag. Keine Nachtschichten. Keine "schnell noch deployen". Keine Regressionen.
Das war der Tag, an dem wir wussten: Das hier ist nicht mehr nur ein Werkzeug für uns. Das ist die Art und Weise, wie Software heute gebaut werden sollte. Und wir wollen, dass unsere Kunden davon profitieren.
Das Problem, das wir uns selbst gestellt haben
Brumm Labs ist eine Werkstatt. Wir bauen mehrere Produkte parallel: Vertellen, Brummlabs Backoffice, ein Design-System, einen Discord-Bot, mehrere Webseiten und eure Produkte. Alles davon hat sein eigenes Backlog. Jedes Produkt schreit nach Aufmerksamkeit.
Als Gründer oder Unternehmer kennst du das Gefühl. Die Liste der Dinge, die du bauen willst, wächst schneller als die Liste der Dinge, die du bauen kannst. Du wachst nachts auf und denkst an drei Dinge, die du machen müsstest, an vier neue Ideen, die deine Kunden seit Wochen anfragen, und an den einen Umbau, der alles einfacher machen würde, wenn du nur die Zeit hättest.
KI-Coding-Tools waren die Hoffnung. Cursor, Copilot, Devin. Wir haben sie alle ausprobiert. Und ja: Sie machen das Tippen schneller. Sie helfen beim Ausprobieren und Prototypen bauen. Sie sind brillant im Moment.
Aber: Sie helfen dir nicht beim Lifecycle. Sie schreiben keine Anforderungsdokumente. Sie planen keine Umsetzung. Sie liefern keine strukturierten Änderungen zur Nachvollziehbarkeit. Sie stellen nicht sicher, dass alles, was eben noch in Produktion lief, auch weiterhin funktioniert. Sie überprüfen ihre eigene Arbeit nicht zwei Tage später.
Was uns fehlte, war kein schnellerer Code-Editor. Was uns fehlte, war eine Werkstatt.
Was wir gebaut haben
Wir nennen sie die Guild. Eine Zunft spezialisierter KI-Agenten, jeder mit einer einzigen, klar umrissenen Aufgabe, alle koordiniert über etwas, das jedes Entwicklungsteam ohnehin hat: GitHub-Issues und Labels.
Du schreibst ein Issue. Du setzt ein Label. Du trinkst Kaffee. Die Guild übernimmt den Rest.
Die fünf Gewerke
Scribe, die Schreiberin.
Sie liest dein Issue und übersetzt unscharfe Produktideen in scharfe Spezifikationen: ein Anforderungsdokument, Epics, einzelne Stories mit messbaren Akzeptanzkriterien. Sie macht Annahmen explizit, statt dich mit Nachfragen zu löchern. Erst wenn sie wirklich nicht weiterkommt, klopft sie an.
Smith, die Implementiererin.
Sie nimmt Scribes Stories und schreibt Code. Über mehrere Repos hinweg, in der richtigen Reihenfolge. Tests zuerst. Minimaler Diff. Wenn ein Bug zu komplex ist, eskaliert sie an Scribe. Keine Hero-Stunts.
Warden, die Wächterin.
Sie reviewt jeden Funktion mit drei adversarialen Augenpaaren gleichzeitig: eine Blind-Hunter-Perspektive, eine Edge-Case-Perspektive, eine Acceptance-Auditor-Perspektive. Findet sie etwas Kritisches, fixt sie es selbst. Bis zu zwei Iterationen, dann eskaliert sie. Und nach dem Merge schaut sie nochmal hin, diesmal als Auditor, und macht aus jedem übersehenen Detail eine eigene Aufgabe für später.
Seal, die Siegelbewahrerin.
Sie eröffnet den Funktion, beobachtet die CI-Pipeline, repariert kleine Fehler eigenständig und merged squash-sauber, sobald alles grün ist. Wenn Chromatic eine visuelle Freigabe braucht, pingt sie uns mit einem Screenshot-Diff.
Werkstatt, die Meisterin.
Sie dirigiert. Sie liest Labels, dispatcht den nächsten Agenten, dokumentiert alles und hält uns über Discord auf dem Laufenden. Von der Idee bis zum Live-Deployment, einfach nachverfolgbar für uns am Kaffeetisch.
Im Hintergrund läuft Forge, der mehrere Pipelines parallel orchestriert. Eine Gründerin kann zehn Issues gleichzeitig bearbeiten lassen, ohne dass sich irgendetwas in die Quere kommt.
Was passiert ist
Im Laufe von vier Tagen hat die Guild 98 Pull Requests durch unsere Repositories getragen. Hier sind die Zahlen, ungeschminkt:
Die Headline
Die Tageskurve
Vier Tage. 98 Pull Requests. Das ist kein Marketing-Zauber. Das ist ein Backlog, der über Monate gewachsen war und in wenigen Tagen abgebaut wurde, während wir an strategischen Entscheidungen weiterdachten.
Was die Guild gebaut hat
Nicht nur Bugfixes. Nicht nur Boilerplate. Echte, produktive Arbeit:
- NIS2 Compliance. Analytics API, Annual Report, Cohort Reporting, koordiniert über drei Produkte (Backend, Frontend, Design-System).
- Self-hosted Video-Support. Video-Modell, Agent-API, Blob-Cleanup, Studio-UI in einem Zug.
- Ein neuer Agent. guild-renovator, der automatisch Dependency-Updates testet und merged. Gebaut durch die Guild für die Guild.
Die Sekunde, die das System ehrlich macht
Zehn Prozent aller gemergten Pull Requests waren Audit-Findings. Das heißt: Nachdem Warden eine Änderung durchgewunken hatte, hat sie sich denselben Code später nochmal angesehen, diesmal als unabhängige Auditorin. Sie hat fehlende Tests gefunden. Sie hat duplizierten Code entdeckt. Sie hat einen blockierenden HTTP-Call in einem asynchronen Kontext aufgespürt. Aus jedem dieser Funde ist ein Issue geworden, das die Pipeline anschließend selbst bearbeitet hat.
Die Guild verbessert ihren eigenen Code. Ohne dass wir etwas tun.
Warum das funktioniert
Drei Designentscheidungen tragen das gesamte System.
Labels statt Workflow-Engine
Die Pipeline hat keinen zentralen Server, keine proprietäre Datenbank, kein Lock-In. GitHub-Issue-Labels sind die einzige Wahrheit. Steht ready-for-dev am Issue, weiß Smith, was zu tun ist. Steht ready-for-review, weiß Warden, dass sie dran ist. Wenn morgen jemand die Guild neu schreiben wollte, könnte er es. Es gibt nichts zu migrieren.
Adversariales Review statt Rubber-Stamp
Drei unabhängige KI-Reviewer schauen auf denselben Diff, und jede weiß nichts von den anderen. Eine kennt die Stories nicht und sucht nach Code-Smells. Eine geht systematisch jeden Boundary-Case durch. Eine prüft, ob jedes Akzeptanzkriterium tatsächlich umgesetzt wurde. Wer einen Reviewer überzeugen will, muss drei überzeugen. Das fängt mehr als jedes einzelne Augenpaar.
Hard-Limits statt Endlos-Loops
Jeder Fix-Versuch hat ein hartes Maximum: zwei Iterationen für Warden, zwei für Seal, drei für GreenLight (unsere CI-Reparatur). Danach: Eskalation. Keine Zombie-Jobs, die ewig im Kreis laufen und Tokens verbrennen. Wenn eine Maschine es nicht schafft, sehen wir es sofort und entscheiden.
Was die Guild nicht kann
Hier ist die ehrliche Linie, die wir nicht überqueren:
- Produktstrategie. Was gebaut werden soll, entscheiden Menschen. Die Guild führt aus, sie entscheidet nicht was.
- Tiefe Designarbeit. Visuelles Urteil, User-Research, Markenfühlung, das bleibt menschlich.
- Architektur mit weiter strategischer Tragweite. Wenn eine Entscheidung Jahre nach hinten reicht, sitzen wir am Tisch, nicht eine KI.
- Incident-Response in Produktion. Wenn um 3 Uhr morgens etwas brennt, wirst du keine KI dazwischen haben wollen.
Wir glauben: Genau diese Grenzen ehrlich zu benennen ist der Grund, warum die Guild innerhalb ihrer Grenzen so verlässlich arbeitet.
Das heißt übrigens nicht, dass wir in diesen Bereichen ohne KI arbeiten. Wir haben Agenten für Produktstrategie, für Design-Thinking-Workshops, für User-Research, für Incident-Analyse. Aber das ist eine Geschichte für ein anderes Mal. Entscheidend ist die klare Aufgabentrennung: Jeder Agent hat seinen eigenen Raum, seine eigenen Grenzen, seine eigene Verantwortung. Die Guild baut Software. Andere Helfer denken über anderes nach. Die Trennung ist kein Zufall, sie ist das, was die Qualität trägt.
Ersetzt das Entwickler, Designer oder Stakeholder?
Nein.
Ehrlich gesagt: Die Guild bringt 80 bis 90 Prozent des Weges. Die letzten Prozent, die eine gute Software von einer ausreichenden trennen, kommen von Menschen. Entwickler, die eine architektonische Weiche stellen. Designer, die einen Interaktionsmoment fühlen. Stakeholder, die eine Annahme im Produkt verwerfen, weil sie ihren Markt kennen.
Der Punkt ist: Diese 10 bis 20 Prozent passieren jetzt an der richtigen Stelle. Nicht mehr verteilt über Wochen von Routinearbeit, in der gute Ideen verdünnt werden. Sondern an sauberen Anknüpfpunkten im Workflow, wo ein Blick auf das PRD, ein Kommentar an der Story, ein Override im Review oder eine strategische Rückfrage sofort Wirkung hat.
Das Ergebnis: Mehr Software. In höherer Qualität. Die nachhaltig bleibt, weil sie von Anfang an dokumentiert, getestet und auditiert ist. Und mit Menschen, die ihre Energie dort einsetzen, wo Menschen wirklich unersetzlich sind.
Die Guild ersetzt niemanden. Sie befreit die Arbeit der Menschen, die mit ihr arbeiten.
Was das für euch bedeutet
Wenn ihr mit Brumm Labs zusammenarbeitet, baut diese Werkstatt für euch. Das heißt konkret:
Ihr bekommt mehr Software, schneller.
Was bei klassischen Agenturen Wochen dauert, geht hier in Tagen. Nicht weil wir mehr Menschen haben, sondern weil unsere Menschen mit einer Maschine arbeiten, die nie müde wird, nie Routine-Code abkürzt und nie Tests "vergisst, weil's eilig war".
Ihr bekommt nachvollziehbare Software.
Jedes Feature hat eine Anforderung, jede Story ein Akzeptanzkriterium, jede Funktion ein Review-Protokoll und einen manuellen QA-Plan. Wenn ihr in sechs Monaten fragt: "Warum haben wir das damals so entschieden?", dann liegt die Antwort im Repository. Unverwischbar.
Ihr bekommt Software, die sich selbst pflegt.
Dependencies werden wöchentlich aktualisiert. CI-Failures werden autonom repariert. Audit-Findings werden zu eigenen Tickets. Wenn ihr nach drei Monaten zurückkommt, ist das Projekt nicht verkrustet. Es ist gepflegter, als ihr es verlassen habt.
Und ihr bekommt Transparenz, die ihr noch nie hattet.
Alles ist sichtbar, von der ersten Scribe-Notiz bis zur grünen Deploy-URL. Ihr seht, was passiert, wann es passiert, und warum. Keine Black-Box. Kein "wir melden uns Ende der Woche".
Ihr bekommt mehr Software, schneller.
Was bei klassischen Agenturen Wochen dauert, geht hier in Tagen. Nicht weil wir mehr Menschen haben, sondern weil unsere Menschen mit einer Maschine arbeiten, die nie müde wird, nie Routine-Code abkürzt und nie Tests "vergisst, weil's eilig war".
Ihr bekommt nachvollziehbare Software.
Jedes Feature hat eine Anforderung, jede Story ein Akzeptanzkriterium, jede Funktion ein Review-Protokoll und einen manuellen QA-Plan. Wenn ihr in sechs Monaten fragt: "Warum haben wir das damals so entschieden?", dann liegt die Antwort im Repository. Unverwischbar.
Ihr bekommt Software, die sich selbst pflegt.
Dependencies werden wöchentlich aktualisiert. CI-Failures werden autonom repariert. Audit-Findings werden zu eigenen Tickets. Wenn ihr nach drei Monaten zurückkommt, ist das Projekt nicht verkrustet. Es ist gepflegter, als ihr es verlassen habt.
Und ihr bekommt Transparenz, die ihr noch nie hattet.
Alles ist sichtbar, von der ersten Scribe-Notiz bis zur grünen Deploy-URL. Ihr seht, was passiert, wann es passiert, und warum. Keine Black-Box. Kein "wir melden uns Ende der Woche".
Wir bauen für uns. Genau deshalb können wir es für euch.
Die Guild ist nicht in einem Hackathon entstanden. Sie ist nicht für Marketing gebaut. Sie ist entstanden, weil wir beschlossen haben, mehrere Produkte gleichzeitig zu betreiben, ohne uns selbst aufzugeben.
Jeder Agent, den ihr oben gelesen habt (Scribe, Smith, Warden, Seal, Werkstatt) wurde durch echte Arbeit geschmiedet. Jede Hard-Limit-Regel kommt aus einem Moment, in dem etwas schiefging und wir lernten, was nicht automatisierbar ist. Jede Konvention kommt aus einem Tag, an dem etwas untergegangen wäre, hätten wir keine Struktur gehabt.
Das ist der Unterschied. Die meisten KI-Agenturen verkaufen ein Versprechen. Wir zeigen euch eine Werkstatt.
Wenn ihr wissen wollt, wie sich das anfühlt, wenn sie für euer Produkt arbeitet, schreibt uns. Wir öffnen die Türe gerne.
Brumm Labs ist eine Werkstatt für KI-gestützte Software in Hamburg. Wir bauen Produkte für unsere eigenen Marken — und packen bei Kunden von der ersten Skizze bis zum erfolgreichen Launch an.