Zum Hauptinhalt springen

632 Commits in 84 Tagen: Was wir beim täglichen Versenden gelernt haben

Der Rhythmus, das Chaos und die kumulativen Effekte des unermüdlichen täglichen Versands.

84 Tage Versand

632

Gesamtcommits

7.5

Durchschnitt pro Tag

84 Tage

Längste Serie

0

Tage ohne Commits

Die Zahl, die die Geschichte erzählt

632 Commits. 84 Tage. Null Tage ohne einen Commit.

Vom 21. November 2025 bis zum 13. Februar 2026 haben wir jeden einzelnen Tag Code ausgeliefert. Wochentage. Wochenenden. Feiertage. Weihnachten. Neujahr. Jeden Tag.

Es geht nicht um Hustle-Kultur oder ständiges Arbeiten. Es geht darum, was passiert, wenn man das Momentum bei einem Produkt aufrechterhält, das schneller wächst, als man geplant hat.

Der tägliche Versandrhythmus

So sieht ein Durchschnitt von 7,5 Commits pro Tag tatsächlich aus:

Morgen: Überprüfen, was über Nacht ausgeliefert wurde (denk dran, die KI löst Probleme um 3 Uhr morgens). Staging überprüfen. Identifizieren, was als Nächstes kommt.

Mittag: Das Hauptfeature des Tages ausliefern. Das ist normalerweise ein PR mit 3-5 Commits: das Feature, ein Fix, der während der Entwicklung entdeckt wurde, und ein Versions-Update.

Abend: Polieren, Randfälle beheben, Abhängigkeiten aktualisieren. Die Commits, die nicht glamourös sind, aber das Produkt reibungslos am Laufen halten.

An manchen Tagen gab es einen Commit. An anderen Tagen zwanzig. Der 22. November — Tag zwei — hatte zwölf Commits. Der Tag, an dem wir E2B-Sandboxes integriert haben, hatte über ein Dutzend. Das Muster variiert, aber die Serie wurde nie unterbrochen.

Wie kumulativer Versand aussieht

Das Interessanteste am täglichen Versand ist nicht jeder einzelne Commit. Es ist der kumulative Effekt.

Woche 1: Chat-Schnittstelle + Dateisystem + Arbeitsbereiche. Ein funktionales Produkt.

Woche 2: Abrechnung + Internationalisierung + UI-Bibliotheken. Ein nachhaltiges Produkt.

Woche 4: Planung + Onboarding + Code-Ausführung. Ein nützliches Produkt.

Woche 8: Bilderzeugung + Fähigkeiten + Modellauswahl. Eine Plattform.

Woche 12: Sandboxed-Ausführung + Hintergrundagenten + autonome CI. Eine autonome Plattform.

Jede Woche baut auf der vorherigen auf. Features existieren nicht isoliert — sie kombinieren sich. Planung + Sandboxes = Ausführung von Hintergrundaufgaben. Abrechnung + Bilderzeugung = nachhaltige kreative Werkzeuge. Fähigkeiten + Sandboxes = sicherer Automatisierungsmarktplatz.

Der kumulative Effekt bedeutet, dass die Ergebnisse der Woche 12 qualitativ anders sind als die der Woche 1, nicht nur quantitativ größer. Wir bauen nicht nur mehr Features. Wir bauen fähigere Kombinationen von Features.

Die wichtigsten Commits

Wenn du durch unsere Git-Historie scrollst, findest du drei Arten von Commits:

Die Builder. “feat: Sandbox-Agentenmodul hinzufügen,” “feat: Arbeitsbereichseinstellungen hinzufügen,” “feat: Fähigkeiten-System mit ClawHub-Import hinzufügen.” Das sind die großen Features. Sie bekommen die Blogbeiträge. Sie erscheinen in den Änderungsprotokollen.

Die Fixer. “fix: unendliche Nachrichtenabfrage-Schleife verhindern,” “fix: Cascade-Löschereignisse bei Sitzungslöschung,” “fix: Bild-URLs in Markdown einbetten, um LLM-URL-Korruption zu verhindern.” Diese sind weniger glamourös, aber arguably wichtiger. Jeder von ihnen repräsentiert ein echtes Problem, das ein echter Nutzer hat.

Die unsichtbaren Upgrades. “chore: @fulldiveVR/chat-ui auf 2.0.12 aktualisieren,” “refactor: alle Judge-Aufrufe über OpenRouter leiten,” “perf: PERF-Trace-Logs hinzufügen.” Diese ändern nicht, was die Nutzer sehen, aber sie ändern, wie gut es funktioniert. Leistungsverbesserungen. Sicherheitsupdates. Abhängigkeitsaktualisierungen.

Das Verhältnis ist ungefähr 30% Builder, 40% Fixer, 30% unsichtbar. Dieses Verhältnis fühlt sich gesund an. Zu viele Builder und nicht genug Fixer bedeuten wachsende Bugs. Zu viele Fixer und nicht genug Builder bedeuten Stagnation. Zu wenige unsichtbare Commits bedeuten, dass sich Schulden ansammeln.

Die Feiertage

  1. November (Thanksgiving): 14 Commits. Verbesserungen der Vorlagen, UI-Bibliotheksfixes, Agentenmodernisierung.

  2. Dezember (Weihnachten): 6 Commits. Automatische Problemlösung, Abonnementschutz, Workflow-Automatisierung.

  3. Januar (Neujahr): 8 Commits. Favicon-Fixes, Sitzungsverbesserungen, Dateifreigabe.

Wir prahlen nicht damit, an Feiertagen zu arbeiten. Einige dieser Commits waren geplante Merges. Einige waren die KI, die Dinge autonom reparierte. Einige waren ein Gründer, der nicht aufhören konnte, an einen Bug zu denken.

Es geht nicht darum, “wir haben an Weihnachten gearbeitet.” Es geht darum, “das Produkt hat sich an Weihnachten verbessert.” Ob diese Verbesserung von einem Menschen oder einer KI kam, ist den Nutzern egal. Sie sehen einfach ein besseres Produkt, wenn sie es das nächste Mal öffnen.

Was wir gelernt haben

Versende die kleinste sinnvolle Einheit. Nicht das ganze Feature. Das kleinste, was das Produkt besser macht. Ein Button, der funktioniert. Ein Fehler, der behandelt wird. Ein klarerer Label. Kleine Commits sind einfach zu überprüfen, einfach zurückzusetzen und leicht verständlich.

Behebe Bugs am Tag, an dem sie gefunden werden. Unsere durchschnittliche Zeit von der Bugmeldung bis zur Behebung wird in Stunden gemessen, nicht in Tagen. Das ist nur möglich, weil wir jeden Tag ausliefern. Ein Team, das wöchentlich ausliefert, hält Bugs eine Woche lang. Ein Team, das täglich ausliefert, behebt sie heute.

Lass dich von der Serie motivieren. Es gibt etwas Psychologisches an einer täglichen Serie. Sobald du 30 Tage hintereinander ausgeliefert hast, willst du sie am Tag 31 nicht brechen. Die Serie wird zur eigenen Motivation. Sie ist nicht für immer nachhaltig — und wir werden Pausen einlegen — aber in einer Launch-Phase ist sie mächtig.

Kumulierung ist real. Der Commit am Tag 84 ist qualitativ anders als der Commit am Tag 1. Nicht, weil wir schlauer sind. Weil wir auf 83 Tagen Fundament aufbauen. Jeder Tag macht den nächsten Tag produktiver. Das ist die wahre Kraft des täglichen Versands.

632 Commits. 84 Tage. Ein Produkt, das von nichts zu einer autonomen KI-Agentenplattform wurde.

Die nächsten 84 Tage werden noch besser.

Wie 84 Tage täglicher Versand aussehen

  1. 1

    Woche 1-2: Fundament Sprint

    Chat, Dateien, Arbeitsbereiche, Abrechnung, Internationalisierung, Bereitstellung. Das Kernprodukt hat sich in 14 Tagen materialisiert.

  2. 2

    Woche 3-4: Funktionsexplosion

    Terminplanung, Einarbeitung, Lokalisierung, Code-Ausführungstools. Das Produkt hat sich von 'es funktioniert' zu 'es ist nützlich' entwickelt.

  3. 3

    Woche 5-8: Plattformreife

    AI-Studio, Bildgenerierung, Marktplatz für Fähigkeiten, Modellauswahl. Das Produkt wurde zu einer Plattform.

  4. 4

    Woche 9-12: Die Sandbox-Ära

    E2B-Integration, Hintergrundagenten, Bewertungsframework, CI/CD-Automatisierung. Die Plattform wurde autonom.

Fragen zur Versandgeschwindigkeit

Wie haltet ihr die Qualität aufrecht, während ihr so schnell liefert?

Automatisierte Tests, Code-Überprüfung (sowohl menschlich als auch AI) und sandboxed Ausführung, die den Blast Radius einschränkt. Wir liefern auch zuerst an die Staging-Umgebung und befördern nach der Überprüfung in die Produktion.

Wie groß ist das Team?

Klein. Wir werden keine genauen Zahlen nennen, aber denk an einstellige Werte. Die Tools, die wir verwenden — KI-unterstützte Entwicklung, wiederverwendbare Bibliotheken, automatisierte Tests — vervielfachen unsere Produktivität erheblich.

Kommst du bei dieser Geschwindigkeit nicht in technische Schulden?

Einige, ja. Aber wir gehen das kontinuierlich an, nicht in großen „Tech-Debt-Sprints“. Jede Woche beinhaltet Refactoring zusammen mit neuen Funktionen. Der Schlüssel ist, dass unsere Architektur gut mit Veränderungen umgeht – das Hinzufügen einer Funktion erfordert selten, dass bestehende geändert werden.

Wie läuft euer Deployment-Prozess ab?

Push zur Hauptversion, automatisierter Build, Docker-Container, Bereitstellung in der Staging-Umgebung. Nach der Überprüfung in die Produktion befördern. Der gesamte Zyklus dauert etwa 15 Minuten.