Alle BeiträgeVom Prototyp zum Produkt

Der Entwickler ist weg und niemand kennt mehr die Architektur. Was jetzt?

Raphael Jasjukaitis

Kurz gesagt: Das ist ein häufiger und lösbarer Zustand. Wenn das Wissen über Ihre Software mit einer Person gegangen ist oder in Dutzenden nicht dokumentierten KI-Sessions verstreut liegt, haben Sie kein Technikproblem, sondern ein Kontrollproblem. Der Ausweg besteht nicht darin, alles neu zu bauen, sondern darin, jemanden das bestehende System kartieren zu lassen: verstehen, was da ist, sichern, was kritisch ist, dokumentieren, was fehlt. Danach gehört Ihnen Ihre Software wieder, unabhängig davon, wer sie ursprünglich gebaut hat.

Wenn Sie gerade das ungute Gefühl haben, dass niemand im Haus erklären könnte, wie Ihr wichtigstes Tool eigentlich funktioniert, lesen Sie weiter.

Warum das kein technisches, sondern ein Machtproblem ist

Software, die niemand versteht, funktioniert oft noch monatelang klaglos. Genau das ist die Falle. Solange nichts kaputtgeht, scheint alles in Ordnung. Aber Sie können nichts ändern, nichts sicher erweitern und im Ernstfall nichts reparieren, ohne zu raten. Sie besitzen die Software auf dem Papier, aber Sie verfügen nicht über sie. Jede kleine Anpassung wird zum Risiko, jede Abhängigkeit von der einen Person, die noch etwas weiß, wird zur Schwachstelle.

In der Sprache der Softwareentwicklung nennt man das den Bus-Faktor: die Zahl der Menschen, die ausfallen müssten, damit das Wissen über ein System verloren ist. Bei vielen Prototypen liegt dieser Faktor bei eins. Manchmal, wenn alles aus KI-Sessions stammt, die niemand festgehalten hat, liegt er bei null, weil das Wissen nie an einem Ort war.

Die zwei Wege, wie Sie in diese Lage geraten sind

Der erste Weg ist der klassische. Ein Entwickler, intern oder extern, hat das System gebaut und ist gegangen. Mit ihm ging alles, was nur in seinem Kopf stand: warum etwas so und nicht anders gelöst wurde, wo die empfindlichen Stellen sind, wie man deployt. Zurück bleibt Code, der läuft, aber schweigt.

Der zweite Weg ist neuer und wird schnell häufiger. Das System ist über viele KI-Sessions entstanden, mal von Ihnen, mal von wechselnden Leuten, jede Session hat ein Stück hinzugefügt. Weil die KI in jedem Gespräch bei null anfängt und niemand die Entscheidungen festgehalten hat, existiert die Gesamtarchitektur nirgends als zusammenhängendes Bild. Sie ist die Summe vieler kleiner Entscheidungen, die niemand mehr überblickt.

Beide Wege führen an denselben Punkt: ein laufendes System ohne Landkarte.

Was zuerst zu tun ist, und was nicht

Der erste Reflex ist oft, alles neu bauen zu lassen, um endlich wieder zu verstehen, was man hat. Das ist fast immer der teuerste Weg und selten nötig. In dem bestehenden System steckt viel wertvolle Arbeit und viel Fachwissen über Ihr Geschäft, das in den Code eingeflossen ist. Das wegzuwerfen, nur weil es undokumentiert ist, wäre so, als würde man ein Haus abreißen, weil der Bauplan verlegt wurde.

Der richtige erste Schritt ist eine Bestandsaufnahme. Jemand, der solche Systeme liest, verschafft sich Zugriff und erstellt die fehlende Landkarte: Wie ist die Anwendung aufgebaut, welche Teile hängen woran, wo liegen die Daten, wo sind die kritischen Stellen, wo die Risiken. Am Ende steht ein Bild, das vorher niemand hatte, und ab da können Sie wieder Entscheidungen treffen, statt zu hoffen.

Von der Landkarte zur Kontrolle

Aus der Bestandsaufnahme ergibt sich fast von selbst, was als Nächstes wichtig ist. Meist sind es drei Dinge. Erstens die Sicherung der kritischen Stellen, damit ein Fehler oder ein Angriff nicht sofort das ganze System trifft. Zweitens Tests für die wichtigsten Abläufe, damit man wieder Änderungen vornehmen kann, ohne blind zu raten, was dabei zerbricht. Drittens eine Dokumentation, die so geschrieben ist, dass auch Ihr nicht-technisches Team Setup, Betrieb und typische Fehlerbilder versteht.

Nach diesen Schritten ist der Bus-Faktor kein Ein-Personen-Risiko mehr. Das Wissen liegt nicht mehr in einem Kopf oder in verlorenen Chatverläufen, sondern an einem Ort, zu dem Sie und jedes künftige Team Zugang haben. Genau das meint Unabhängigkeit: Sie sind weder von der Person angewiesen, die gegangen ist, noch von uns, noch von den ursprünglichen KI-Sessions.

Warum Sie damit nicht warten sollten

Der Zustand ist deshalb gefährlich, weil er ruhig bleibt, bis er es nicht mehr ist. Solange nichts passiert, gibt es keinen Anlass zu handeln, und genau deshalb handelt niemand. Der teure Moment kommt unangekündigt: eine dringende Änderung, die niemand sicher umsetzen kann, ein Ausfall, den niemand einordnet, ein Sicherheitsvorfall in einem System, das keiner mehr überblickt. Die Bestandsaufnahme ist dann nicht mehr eine ruhige Investition, sondern eine Feuerwehraktion unter Druck. Der günstige Zeitpunkt ist immer der, an dem gerade noch alles läuft.


Niemand im Haus kennt mehr das ganze System? Wir kartieren im Vibecode-Audit Ihr bestehendes System, sichern die kritischen Stellen und dokumentieren es so, dass Sie und jedes künftige Team wieder die Kontrolle haben, ohne alles neu zu bauen.

Vibecode-Audit anfragen Mit einem Entwickler sprechen