Was ein Release mit 127 Commits wirklich ist

Es gibt eine Version dieses Beitrags, die einfach alles auflistet, was in GeekBye v1.7.0 steckt — ein neu gestalteter Startbildschirm, ein Kalibrierungsflow, eine einklappbare Seitenleiste, neue Einstellungen und so weiter. Sie wäre korrekt und würde dir nichts beibringen. Denn die ehrliche Geschichte eines Releases mit 127 Commits ist nicht die Liste. Es ist die Form.

Hier ist die Form. Hundertsiebenundzwanzig Commits klingen nach hundertsiebenundzwanzig Kleinigkeiten. Das sind sie fast nie. v1.7.0 waren zwei große Features, parallel auf langlebigen Branches über etwa elf Tage gebaut, am Ende ineinander verwoben. Ein großes Release zu verstehen heißt, diese beiden Stränge zu verstehen — und die eine Stelle, an der wir etwas am falschen Ort gebaut haben und es im Flug wieder herausreißen mussten.

Strang eins: Kalibrierung

Der erste Strang war die Kalibrierung — eine KI-Sprachbewertung deiner Kommunikationsfähigkeiten. Du startest einen Live-Call mit einem KI-„Karriere-Coach", arbeitest dich durch einen strukturierten Satz von Phasen (Aufwärmen, Verhalten, technische Kommunikation, Reaktion unter Druck, Zielsetzung), und am Ende wirst du in sechs Dimensionen bewertet: Selbstvertrauen, Klarheit, Konkretheit, Engagement, Fassung, Relevanz. Darunter misst sie auch konkrete Sprechmetriken: dein Sprechtempo, die Häufigkeit von Füllwörtern, ob deine Pausen als strategisch oder zögerlich gelesen werden.

Das Ergebnis ist keine Note, es ist ein Ausgangspunkt. Die Kalibrierung liefert deine Stärken, deine Wachstumsfelder und — entscheidend — einen empfohlenen Schwierigkeitsgrad, mit dem du zu üben beginnen solltest. Sie kalibriert, wo das Produkt dich abholen soll. Jede Fähigkeit kommt als ausklappbare Feedback-Karte zurück, mit einer Zusammenfassung, einem konkreten Vorschlag und einem tatsächlich zitierten Satz aus deinem eigenen Call als Beispiel. Es ist das Feature, auf dem der Rest der Übungserfahrung aufbaut.

Strang zwei: ein ganz neues Fenster

Der zweite Strang war ein Premium-Redesign — und es Redesign zu nennen, wird ihm nicht gerecht. Es war kein Reskin der bestehenden Screens; es war faktisch ein zweites Anwendungsfenster, in sechs expliziten Phasen ausgebaut: eine einklappbare Seitenleiste im Notion-Stil, ein Header-Dropdown, das die alte Sitzungsliste ersetzte, browserartige Navigation mit Verlauf und Breadcrumbs, und Premium-Neubauten von Start, Profilen, Meetings und Einstellungen.

Zwei große Features. Das waren 127 Commits in Wirklichkeit. Und das Schwerste beim Ausliefern war nicht, das eine oder das andere zu schreiben — es war das Verweben. Die beiden Branches waren voneinander abhängig; einer wurde in den anderen gemergt, und der Kalibrierungs-Branch musste den main-Branch vier separate Male hereinziehen, nur um nicht abzudriften, während sich das Redesign darunter bewegte. Die Commit-Zahl sind nicht die Kosten eines großen Releases. Langlebige Branches und die Integrationsreihenfolge schon.

Der Teil, der die Lektüre wert ist: Wir haben die Kalibrierung am falschen Ort gebaut

Hier ist der Fehler, und es ist ein guter, weil er so verbreitet ist.

GeekBye hat eine feste Architekturregel: Alle KI-Operationen leben im Backend. Der Client ist eine dünne Hülle, die mit einem Server spricht. Alle wussten das.

Und trotzdem wurde die Kalibrierung zuerst in der lokalen Datenbank des Clients gebaut. Eine eigene Tabelle, eine Datenbankmigration, ein Repository mit 254 Zeilen, IPC-Handler und eine Bank mit 515 Zeilen Bewertungsfragen — alles auf der Maschine des Nutzers. Es funktionierte. Es verletzte auch stillschweigend den Vertrag, auf dem die ganze App aufbaut.

Drei Tage später löschte ein Commit 680 Zeilen über acht Dateien hinweg, um alles ins Backend zu verschieben, wo die Kalibrierungsdaten zu einem echten serverseitigen Modell wurden und die Fragenlogik und das Scoring zu einer Server-Angelegenheit. Ein weiterer Commit löschte die 515-Zeilen-Fragenbank des Clients komplett. Der Diff ist fast lustig: eine Einfügung, sechshundertachtzig Löschungen.

Niemand setzte sich hin, um 680 Zeilen Wegwerf-Code zu schreiben. Es passierte so, wie das immer passiert: Der Client-Shortcut ist direkt da, es geht schneller, lokal zu prototypen, und „wir verschieben es später ins Backend" fühlt sich harmlos an. Aber wenn deine Architektur dir bereits sagt, wo die Single Source of Truth lebt, ist es kein Shortcut, es woanders zu bauen — es ist Nacharbeit, die du dir selbst im Voraus eingeplant hast. Die Lektion, die haften blieb: Bau es dorthin, wo der Vertrag es sagt, beim ersten Mal, auch wenn die lokale Version schneller aufzusetzen ist.

Der Bug, den nur die Integration finden konnte

Noch ein Beleg, denn es ist das charakteristische Fehlermuster großer Releases. Sobald Kalibrierung und die neue Navigation verdrahtet waren und tatsächlich liefen, begann die App, ein Rate-Limit auszulösen — HTTP 429 — ohne offensichtlichen Grund.

Die Ursache war pure Integration. Der Kalibrierungsstatus wurde auf Komponentenebene abgerufen, also holte ihn jede Navigation erneut — und Reacts Strict Mode, der Effects in der Entwicklung absichtlich doppelt aufruft, um Bugs aufzudecken, verdoppelte das noch einmal. Das Ergebnis waren vier bis acht identische Kalibrierungs-Requests pro Bildschirmwechsel, genug, um den Rate-Limiter des Servers auszulösen. Der Fix konsolidierte das Fetching auf ein paar Aufrufe beim Mounten.

Diesen Bug hättest du nicht finden können, wenn du die Kalibrierung allein oder die Navigation allein getestet hättest. Er existiert nur an der Naht — dort, wo zwei jeweils korrekte Features aufeinandertreffen. Das ist die Steuer, die ein großes Release erhebt: Die letzte Meile ist nicht das Bauen der Features, sondern das Entdecken all dessen, was nur kaputtgeht, wenn sie endlich im selben Raum sind.

Drei Dinge, die ein großes Release lehrte

1. Ein Release mit 127 Commits sind zwei oder drei große Themen, nicht hundert kleine. Finde die Stränge. Die Arbeit — und das Risiko — liegt darin, wie sie sich verweben, nicht in der Zahl.
2. Setze die Single Source of Truth dorthin, wo der Vertrag sagt, dass sie lebt, beim ersten Mal. Wir haben 680 Zeilen gelöscht, um die Kalibrierung vom Client ins Backend zu verlagern. Der lokale Shortcut ist im Voraus eingeplante Nacharbeit; die Architektur hatte dir die Antwort schon gegeben.
3. Die Integration fördert Fehler zutage, die die Isolation nicht kann. Der 429-Sturm lebte an der Naht zwischen zwei korrekten Features und tauchte erst auf, als sie zusammen liefen. Plane einen Integrationsdurchgang ein, nicht nur Tests pro Feature.

Das hier ist ein Cousin aus der v1-Ära einer Geschichte, die wir in viel größerem Maßstab noch einmal erzählen würden — siehe was eine Version 2 wirklich braucht: 206 Commits ehrlicher Zustände (v2.0.0), wo sich dieselbe Wahrheit — „eine große Zahl sind in Wirklichkeit ein paar große Ideen" — über die gesamte v2-Neufassung entfaltet. Für das vorige Kapitel der v1-Geschichte, wie man einen Live-Bericht ohne das Flackern streamt (v1.6.13); und für den ganzen Bogen, die Anatomie, Software bis zur Perfektion auszuliefern.