Die Bibliotheks-Extraktion, die alles verändert hat

Der Moment, in dem ein Produkt zur Plattform wird

Es gibt einen bestimmten Moment im Leben jedes Produkts, an dem es aufhört, eine einzelne Anwendung zu sein, und beginnt, eine Plattform zu werden. Für uns war dieser Moment der 26. November 2025 — fünf Tage nach dem ersten Commit.

Dann haben wir unsere Chat-Oberfläche, das virtuelle Dateisystem und die Kern-Utilities in drei separate, wiederverwendbare Pakete extrahiert: @fulldiveVR/chat-ui, @fulldiveVR/vfs-ui und @fulldiveVR/core-ui-utils.

Das klingt nach einer ingenieurtechnischen Entscheidung. Es war tatsächlich eine geschäftliche Entscheidung.

Warum wir es am fünften Tag und nicht am fünfzigsten gemacht haben

Die gängige Meinung sagt: Extrahiere Bibliotheken nicht zu früh. Warte, bis du einen zweiten Anwendungsfall hast. Warte, bis die API stabil ist. Warte, bis du “weißt, was du baust.”

Wir haben das alles ignoriert.

Hier ist der Grund: Wir wussten, dass wir mehrere Produkte haben würden, die dieselbe Chat-Oberfläche nutzen. Wir wussten, dass die Benutzeroberfläche für die Dateiverwaltung in verschiedenen Kontexten benötigt werden würde. Und wir wussten, dass je länger wir warteten, desto enger diese Komponenten an die spezifischen Bedürfnisse des Dashboards gekoppelt wären.

Am fünften Tag war das chat-ui-Paket etwa 2.000 Zeilen Code. Sauber. Gut abgegrenzt. Leicht zu extrahieren.

Hätten wir bis zum fünfzigsten Tag gewartet, wären es 10.000 Zeilen mit Dutzenden von impliziten Abhängigkeiten vom dashboard-spezifischen Zustand, Routing und Konfiguration gewesen. Die Extraktion hätte dann ein mehrwöchiges Projekt statt eines zweitägigen Projekts bedeutet.

Was wir extrahiert haben

chat-ui — Das gesamte Chat-Rendering-System. Nachrichtenblasen, Streaming-Antworten, Dateianhänge, Agentenwechsel, Tool-Call-Anzeigen. Alles, was ein Benutzer sieht, wenn er mit einem AI-Agenten spricht.

vfs-ui — Die Benutzeroberfläche des virtuellen Dateisystems. Dateibäume, Ordnererstellung, Datei-Vorschauen, Drag-and-Drop, Upload-Dialoge. Alles, was ein Benutzer sieht, wenn er seine Dateien verwaltet.

core-ui-utils — Gemeinsame Utilities. Theme-Tokens, gängige Hooks, Layout-Primitiven. Die Dinge, die sowohl chat-ui als auch vfs-ui benötigen, aber die keiner besitzen sollte.

Jedes wurde zu einem versionierten npm-Paket, veröffentlicht bei GitHub Packages, und vom Dashboard wie jede andere Abhängigkeit konsumiert.

Die kumulativen Erträge

Bis Februar 2026 war unser chat-ui-Paket auf Version 2.0.12. Das sind Dutzende von Releases — jedes verbessert das Chat-Erlebnis in jedem Produkt, das es nutzt.

Als wir Hintergrundaufgaben-Nachrichten zu chat-ui hinzugefügt haben, erhielt jedes Produkt Hintergrundaufgaben-Nachrichten. Als wir zusammenklappbare Benutzernachrichten hinzugefügt haben, erhielt jedes Produkt zusammenklappbare Benutzernachrichten. Als wir einen Rendering-Bug behoben haben, erhielt jedes Produkt den Fix.

Das ist die kumulative Rendite der frühen Extraktion: Verbesserungen multiplizieren sich.

Aber es geht über die Wiederverwendung von Code hinaus. Die Extraktion dieser Bibliotheken zwang uns, über unsere Schnittstellen nachzudenken. Was muss ein Chat-Komponente wissen? Was braucht ein Dateimanager von seiner Host-Anwendung? Diese Fragen, früh gestellt, lieferten sauberere Antworten, als sie Monate später gekommen wären, als alles miteinander verwoben war.

Der unerwartete Vorteil: Geschwindigkeit

Hier ist, was uns am meisten überrascht hat. Nach den anfänglichen Extraktionskosten (etwa zwei Tage Refactoring) erhöhte sich unsere Entwicklungsgeschwindigkeit.

Warum? Weil die Grenzen klar waren. An der Chat-Erfahrung zu arbeiten bedeutete, in chat-ui zu arbeiten. An der Dateiverwaltung zu arbeiten bedeutete, in vfs-ui zu arbeiten. Es gab kein “Ich habe den Chat geändert und es hat den Dateimanager kaputt gemacht”, weil es buchstäblich separate Pakete mit definierten Schnittstellen waren.

Neue Teammitglieder konnten an chat-ui arbeiten, ohne den gesamten Dashboard-Code zu verstehen. Fehlerberichte konnten sofort dem richtigen Paket zugeordnet werden. Das Testen war schneller, weil jedes Paket seine eigene Test-Suite hatte.

Die Lektion für andere Entwickler

Wenn du eine Box um eine Komponente ziehen kannst — wenn sie klare Eingaben, klare Ausgaben und einen klaren Zweck hat — extrahiere sie früh. Warte nicht auf den mythischen “richtigen Zeitpunkt.” Der richtige Zeitpunkt ist, wenn die Extraktion klein und günstig ist. Dieses Zeitfenster schließt sich schneller, als du denkst.

Wir haben in der ersten Woche drei Bibliotheken extrahiert. Achtzig Tage später wurden sie über hundert Mal aktualisiert. Jedes Update machte jedes Produkt besser. Das ist die Art von Hebelwirkung, die ein kleines Team in ein produktives verwandelt.