KI-Produkt nach dem Launch pflegen: Git, Rollback und Backups

Mehr über die Arbeit mit Modellen erfährst du in der Ailoot-Dokumentation.

Warum beginnt die teuerste Arbeit erst nach dem Launch?#

Du hast an einem Abend eine App gebaut, einen Link veröffentlicht und ihn an deine Freunde geschickt. Sie funktioniert. Dann taucht eine Woche später die erste echte Person auf, klickt etwas auf die falsche Weise an und die Hälfte der Funktionen funktioniert nicht mehr. Du bittest Claude, das zu reparieren – es behebt eine Sache und macht eine andere kaputt. Kommt dir das bekannt vor?

Und genau dann stellt sich die Hauptfrage: Was machst du nach dem Launch eines Produkts, wenn die Euphorie über den ersten funktionierenden Prototyp vorbei ist und du es irgendwie weiter pflegen musst? Man könnte das Vibe Coding für Erwachsene nennen. Entwickeln bedeutet Begeisterung und Tempo. Wartung verlangt einen kühlen Kopf: Du verstehst, was du änderst, und behältst es unter Kontrolle. Die meisten scheitern an diesem zweiten Teil, weil sie niemand darauf vorbereitet.

Eine Branchenstudie hat mehr als eine Million Codeänderungen aus 2.444 Teams analysiert und berechnet, wohin das für KI-Entwicklung ausgegebene Geld tatsächlich fließt. So sieht das Bild aus:

Der Leitfaden „Die versteckten Kosten von Vibe Coding“ erklärt diese Zahlen ausführlicher. Dort ging es um die Frage, wofür du bezahlst. Hier ist die Frage eine andere: 44 Cent von jedem Dollar fließen in die Fehlerbehebung – und dieser ganze Artikel handelt davon, diesen Anteil nicht wachsen zu lassen. Die Arbeit, ihn unter Kontrolle zu halten, nennt man Wartung.

Der Unterschied zwischen jemandem, der Vibe Coding für Erwachsene betreibt, und jemandem, der nur ein neuronales Netz babysittet, zeigt sich nach dem Launch. Beim Ersten wächst die Codebasis, Verbesserungen werden umgesetzt, und nichts geht kaputt. Einen Monat später ist das Produkt der zweiten Person zu einem undichten Gebilde geworden, das sie nicht anzufassen wagt. Im Folgenden erkläre ich, wie du zur ersten Gruppe gehörst.

Was geht tatsächlich kaputt: 5 Katastrophen nach dem Launch#

Das sind öffentliche Nachberichte zu echten, mit KI entwickelten Produkten – mit Zahlen und Daten. Stell sie dir als Minenfeldkarte vor: Jede Mine ist bei jemandem bereits explodiert, und der Weg daran vorbei ist bekannt.

Alle fünf Fälle haben dieselbe Ursache. Standardmäßig sorgt KI dafür, dass Dinge jetzt funktionieren, nicht sicher einen Monat später unter Last. Während der Entwicklung auf deinem Computer kannst du den Unterschied nicht erkennen. Er wird sichtbar, wenn der erste Fremde mit schlechten Absichten auftaucht.

Das Problem ist nicht, den Code nicht von Hand zu schreiben – viele arbeiten so. Das Problem ist, nicht zu fragen: „Ist die Datenbank geschützt?“ Im Folgenden zeige ich dir einen Prompt, der diese Frage für dich stellt.

Das erste Sicherheitsnetz sind Git und die Rückkehr zu „wie es gestern war“#

Wenn Claude etwas kaputt macht, brauchst du eine Schaltfläche „Stell es wieder her, wie es gestern war“. Technisch heißt diese Schaltfläche Git, und es ist einfacher, als es klingt.

Drei Begriffe, die Nicht-Programmierer verstehen sollten:

1. Repository – dein Projektordner, der in der Cloud gespeichert ist (meistens auf GitHub). Eine Kopie deines gesamten Codes, die nicht nur auf deinem Computer liegt.
2. Commit – ein Rückkehrpunkt. Du sagst dem Code damit sinngemäß: „Speichere diesen Zustand.“ Jeder Commit ist eine Markierung, zu der du zurückkehren kannst.
3. Deploy – eine Übertragung. Der Code war lokal auf deinem Computer und funktionierte nur für dich. Beim Deploy wird er an einen externen Server geschickt, damit er für alle funktioniert.

Solange du aktuelle Commit-Punkte hast, kannst du jeden Schaden mit einem Satz rückgängig machen. Wirklich.

Ich habe etwas kaputt gemacht – gestern hat alles funktioniert, heute aber nicht mehr. Finde den letzten Commit, bei dem alles in Ordnung war, zeig mir, was sich seitdem geändert hat, und setze das Projekt auf diesen Stand zurück.

Zwei Regeln, die du sofort umsetzen solltest, bevor andere das Produkt sehen:

• Das Repository muss privat sein. Nicht öffentlich. Sonst kann jeder deinen Code und alles darin lesen.
• Setze die Geheimnisdatei auf die Ignorierliste. Schlüssel, Passwörter und Zugangsdaten für die Datenbank liegen in einer separaten Datei (meistens .env), und diese Datei kommt niemals ins Repository. Füge in .gitignore eine Zeile für .env ein, dann bleiben die Geheimnisse bei dir.

Es gibt einen separaten Leitfaden zum sicheren Zurücksetzen von Änderungen in Claude Code: Änderungen in Claude Code zurücksetzen. Ohne Rückkehrpunkte balancierst du auf einem Drahtseil ohne Netz, und früher oder später fällst du.

Was setzt /rewind zurück – und was nicht?#

Claude Code erstellt vor jeder Änderung, die es vornimmt, einen Snapshot des Zustands. Der Befehl /rewind (oder zweimaliges Drücken von Esc) setzt sowohl Dateien als auch die Unterhaltung auf einen ausgewählten Punkt zurück. Das ist praktisch: Wenn du vor fünf Minuten eine Funktion kaputt gemacht hast, kannst du fünf Minuten zurückgehen.

Doch es gibt eine Falle, durch die Anfänger Daten verlieren. /rewind setzt nicht alles zurück:

Anthropic bringt es selbst auf den Punkt: Snapshots sind eine lokale „Rückgängig“-Schaltfläche, während Git die dauerhafte Historie ist. Snapshots ergänzen die Versionsverwaltung, ersetzen sie aber nicht.

Die praktische Erkenntnis für Nicht-Programmierer: /rewind rettet dich vor „Claude hat gerade eine Funktion kaputt gemacht“. Wenn Claude aber eine Datenbankzeile gelöscht oder Code in die Cloud hochgeladen hat, können nur Git und ein Datenbank-Backup ihn zurückbringen. Behalte also beide Ebenen: Snapshots für schnelle Rücksetzungen, Commits für die dauerhafte Projekthistorie.

Wie kannst du Verbesserungen vornehmen, ohne zu beschädigen, was bereits funktioniert?#

Jede zweite Person gerät in diese Schleife. Du bittest KI, einen kleinen Fehler zu beheben. Sie schlägt eine vernünftige Änderung vor. Diese Änderung macht etwas anderes kaputt. Du bittest sie, das neue Problem zu beheben, und schon tauchen zwei weitere Probleme auf. Und so weiter.

Die Schleife entsteht, weil Vibe Coding nichtdeterministisch ist. Derselbe Prompt liefert dir zweimal unterschiedlichen Code. So kann jede Bearbeitung unbemerkt die umgebende Logik verschieben: Die Rabattschwelle steigt von 10 auf 12 Prozent oder eine Validierungsregel verhält sich anders – ohne dass du etwas prüfst und ohne eine einzige Warnung. Das nennt man schleichende Veränderung der Logik. Sie beschädigt unbemerkt genau die Dinge, die Geld einbringen: Preise, Zugriffsrechte und Zahlungen.

Es gibt eine Regel, die vor solchen Veränderungen schützt, und sie ist einfach genug, um sie an die Wand zu hängen: Committe keinen Code, den du einer anderen Person nicht Wort für Wort erklären könntest.

In der Praxis wird daraus eine fertige Anweisung, die du vor jeder Änderung an funktionierendem Code verwenden kannst. Sie bringt KI dazu, kleine Schritte zu machen und dir genau zu zeigen, was sich geändert hat.

Bevor du den Code änderst, gehe so vor:

Speichere den aktuellen funktionierenden Zustand als separaten Rückkehrpunkt (Commit).

Beschreibe mit Worten genau, was du ändern willst und in welchen Dateien.

Nimm die kleinstmögliche Änderung vor – nur das, was meine Aufgabe löst, sonst nichts.

Zeig mir, was sich geändert hat, und erkläre jede Änderung so, dass ich sie einer anderen Person erklären könnte.
Fass die Logik für Preise, Zugriffsrechte oder Zahlungen nicht an, außer ich bitte dich darum.

Ein weiteres Prinzip, das Wochen spart, ist Disziplin bei den Aufgabengrenzen. Ein Schmerzpunkt, eine Änderung, eine schnelle Umsetzung. Bitte KI nicht, das halbe Projekt in einem Prompt neu zu schreiben. Professionelle Entwickler fangen manchmal an, einen ganzen Uber zu bauen, obwohl sie nur eine Schaltfläche brauchten – und ziehen das monatelang in die Länge. Das brauchst du nicht.

Alles, was ich beschreibe, beruht auf einer Sache: Kontextmanagement. Damit KI keine benachbarte Logik kaputt macht, muss sie sich an die Regeln deines Projekts erinnern.

Wie prüfst du eine Änderung, bevor du sie veröffentlichst?#

Zwischen „Auf meinem Computer funktioniert es“ und „Für alle funktioniert es“ gibt es einen Zwischenschritt, den Anfänger überspringen: eine Testkopie. Das ist ein separater Schnappschuss deiner Produktionsumgebung, in dem du eine Änderung prüfst, bevor echte Menschen sie sehen. Der Arbeitsablauf sieht so aus:

1. Erstelle die Änderung und prüfe sie selbst (Entwicklung).
2. Stelle sie in Staging bereit – einer Kopie der Produktionsumgebung, aber ohne echte Nutzer.
3. Führe die wichtigsten Szenarien durch und vergewissere dich, dass sich nichts verschoben hat.
4. Erst jetzt stellst du sie in der Produktionsumgebung bereit.

Warum das nach dem Launch wichtig ist: Jede Veröffentlichung birgt ein Risiko. Eine kleine Codeänderung kann die Anmeldung bei einem Konto beschädigen. Eine fehlende Einstellung kann das gesamte Produkt lahmlegen. Staging fängt solche Probleme folgenlos ab; in der Produktionsumgebung verlierst du Kunden.

Damit du nicht jedes Mal alles von Hand prüfen musst, gib KI einen Prompt, mit dem sie das Verhalten der neuen Version in den entscheidenden Bereichen mit dem alten vergleicht.

Ich möchte eine Änderung bereitstellen. Gehe die wichtigsten Szenarien des Produkts der Reihe nach durch und prüfe, ob jedes weiterhin wie zuvor funktioniert:

Registrierung und Anmeldung eines neuen Nutzers.

Zahlung und Freischaltung des Zugangs nach der Zahlung.

Zugriffsrechte – ein normaler Nutzer kann weder die Daten anderer Personen noch den Admin-Bereich sehen.

Die wichtigsten Kennzahlen der Geschäftslogik (Preise, Rabatte, Limits) haben sich nicht geändert.
Wenn sich etwas anders als in der vorherigen Version verhält, halte an und zeig mir genau, was sich geändert hat.

Wo liegen deine Geheimnisse? Die größte Sicherheitslücke für Anfänger#

Ich erkläre die größte Stolperfalle ausführlich, weil sie mehr Produkte zu Fall bringt als jede andere. Wenn KI Code schreibt, ist es am einfachsten, einen Schlüssel dorthin zu setzen, wo er sofort funktioniert – direkt in den Code der Seite, die im Browser geöffnet wird. Während der Entwicklung bemerkst du den Unterschied nicht. Doch jeder kann alles lesen, was den Browser erreicht, indem er die Entwicklertools öffnet.

Der Gründer, dessen Kunden mit $87,500 belastet wurden, sagte später, ein einziger Prompt hätte das verhindern können. Die Belastungen wurden schließlich rückgängig gemacht, aber die nicht erstattungsfähigen Gebühren und die verlorene Ruhe blieben. Hier ist dieser Prompt.

Prüfe das gesamte Projekt und stelle sicher, dass kein geheimer Schlüssel im Browser landet:

Finde alle Schlüssel für die Datenbank, das Zahlungssystem und externe Dienste.

Stelle sicher, dass jeder davon nur auf dem Server in Umgebungsvariablen gespeichert ist und nicht im Seitencode steht.

Prüfe die Projekthistorie – ist früher versehentlich ein Schlüssel hineingeraten?
Zeig mir eine Liste aller Stellen, an denen du Geheimnisse gefunden hast, und was jeweils damit zu tun ist.

Die nächste Stolperfalle in der Nähe ist, Zugriffsrechte nur auf der Browserseite zu prüfen. Wenn dein Produkt im Seitencode entscheidet, ob es „den Admin-Bereich anzeigen“ soll, kann jeder diese Entscheidung umgehen. Zugriffsrechte müssen immer auf dem Server geprüft werden. Die Datenbank darf Daten nur an diejenigen zurückgeben, die dazu berechtigt sind – dafür gibt es Row-Level Security (RLS), die für jede Tabelle aktiviert sein muss.

Bevor du Zugänge verkaufst oder andere hineinlässt, führe eine allgemeine Sicherheitsprüfung des Produkts durch.

Gehe das Projekt wie ein Angreifer durch und suche nach Sicherheitslücken:

Sind geheime Schlüssel in Code gespeichert, der an den Browser ausgeliefert wird, oder in der Projekthistorie?

Ist Row-Level Security (RLS) für jede Datenbanktabelle aktiviert, und werden Zugriffsrechte auf dem Server statt nur im Browser geprüft?

Ist ein automatisches Datenbank-Backup eingerichtet, und habe ich jemals geprüft, ob ich daraus wiederherstellen kann?

Ist die Produktionsdatenbank von der Umgebung isoliert, in der der KI-Agent läuft?
Sag mir für jeden Punkt, ob alles in Ordnung ist oder was genau behoben werden muss.

Es gibt einen separaten, vollständigen Leitfaden zur Sicherheit beim Vibe Coding: Eine Vibe-Coding-App absichern. Die Regel ist einfach: Betrachte alles, was KI standardmäßig getan hat, als ungesichert, bis du das Gegenteil überprüft hast.

Wo solltest du dein Produkt hosten: die Hosting-Leiter#

Du musst nicht sofort einen eigenen Server mieten und von Hand konfigurieren – am Anfang ist das eine komplizierte Aufgabe, die deine Zeit verschlingt. Du kannst die Leiter erklimmen, während das Produkt wächst:

1. Kostenloses Hosting (zum Beispiel Vercel) – für dich selbst, Tests und kleine Projekte. Es funktioniert, wenn die Plattform für deine Zielgruppe verfügbar ist und du keine personenbezogenen Daten speicherst.
2. Eine Plattform mit Bereitstellung per einem Befehl (Railway) – wenn du ein Backend und eine Datenbank hast. Du stellst das Produkt mit einem Befehl bereit und musst keinen Server konfigurieren. Die Einstiegshürde ist minimal.
3. Dein eigener dedizierter Server – wenn die Auslastung hoch ist und du die volle Kontrolle brauchst. Wechsle später dorthin, wenn du an die Grenzen der Plattform stößt.

Für Nicht-Programmierer, die gerade erst ein Produkt veröffentlicht haben, ist eine Plattform mit Bereitstellung per einem Befehl ohne manuelle Serverkonfiguration die einfachste Option. Wechsle später zu einem eigenen Server. Wenn du diesen Weg an einem konkreten Beispiel nachvollziehen möchtest, findest du hier den Leitfaden zum Deploy eines Vibe-Coding-Projekts auf einem eigenen Server mit Coolify.

Wann solltest du App, Datenbank und Backups voneinander trennen?#

Drei Dinge sollte man nicht in denselben Korb legen: die App, die Datenbank und Backups. Solange es wenige Nutzer gibt, ist alles zusammen untergebracht, und das ist in Ordnung. Doch es gibt ein klares Signal dafür, wann es Zeit ist, sie zu trennen.

• Lege App und Datenbank auf verschiedene Rechner. Das Signal: Bei Spitzenlast bleiben CPU- und Speicherauslastung über 70–80 Prozent, Anfragen werden langsamer und App und Datenbank konkurrieren um dieselben Ressourcen. Nach der Trennung kannst du die Datenbank stärken, ohne die App anzufassen, und umgekehrt.
• Halte dich an die 3-2-1-Backup-Regel. Drei Datenkopien auf zwei verschiedenen Medientypen, davon eine an einem anderen Standort. Das schützt vor Hardwareausfällen und Ransomware. Entscheidend ist, dass Backups automatisch erstellt werden.

Wie häufig Backups nötig sind, hängt davon ab, wie kostspielig es wäre, Daten aus mehreren Stunden zu verlieren. Ist bei einem Online-Abonnementdienst der Verlust einer Stunde Zahlungsdaten untragbar, muss das Backupintervall kürzer als eine Stunde sein. Alternativ brauchst du geprüfte Transaktionsprotokolle mit zeitpunktgenauer Wiederherstellung (PITR). Lege das Intervall nach dem maximal tragbaren Datenverlust fest und teste die Dauer der Wiederherstellung separat. Für einen Blog reicht einmal täglich. Die Logik ist einfach: Entscheide, wie viele Daten du dir leisten kannst zu verlieren, und richte die Backups entsprechend ein.

Hilf mir zu entscheiden, ob mein Produkt auf eine leistungsfähigere Infrastruktur umsteigen sollte. Prüfe jeden Punkt und frag mich danach:

Wie stark sind CPU und Arbeitsspeicher bei Spitzenlast ausgelastet – bleibt die Nutzung über 70–80 Prozent oder nicht?

Liegen Datenbank und App auf demselben Rechner oder auf verschiedenen?

Ist ein automatisches Datenbank-Backup eingerichtet, und habe ich die Wiederherstellung daraus getestet?

Gibt es eine separate Kopie der Umgebung (Staging), um vor dem Deploy zu prüfen?
Gib mir auf Grundlage der Ergebnisse eine klare Empfehlung: Was kann bleiben, wie es ist, was sollte zuerst getrennt werden und warum?

Eine weitere Frage lautet: verwaltete Datenbank oder eigene? Für ein kleines Team ist eine verwaltete Datenbank fast immer besser: Eine eigene ist bei der Hardware günstiger, kostet aber viele Stunden Wartungsarbeit. Wenn du allein arbeitest und dein Produkt keine Infrastruktur ist, kosten diese Stunden mehr als der Unterschied beim Serverpreis.

Wie kannst du die Wartung automatisieren?#

Manuelle Wartung ist anstrengend. Du kannst dir die Arbeit auf zwei Arten abnehmen lassen: durch Monitoring und einen Kontroll-Agenten.

Beim Monitoring übernehmen zwei verschiedene Werkzeuge zwei verschiedene Aufgaben:

1. „Ist die Website erreichbar?“ – ein Uptime-Monitor (zum Beispiel UptimeRobot). Er prüft das Produkt alle paar Minuten und sendet eine Warnung, wenn es ausfällt. Es gibt einen kostenlosen Tarif.
2. „Was genau ist kaputt?“ – ein Fehler-Tracker (zum Beispiel Sentry). Er sammelt Fehler innerhalb der App und zeigt, wo und warum etwas fehlgeschlagen ist.

Das erste Werkzeug erkennt, dass das Produkt ausgefallen ist. Das zweite zeigt, welche Funktion warum ausgefallen ist. Zusammen beantworten sie die Frage: „Erfahre ich von einem Ausfall, bevor ein Kunde den Support anschreibt?“

Die zweite Automatisierungsstufe ist ein Kontroll-Agent. Stell dir eine Immobilienagentur vor: Um sieben Uhr morgens liest ein KI-Agent die Anfragen auf der Website, erkennt, dass das Buchungsformular kaputt ist, findet die Ursache im Code und bringt dir eine fertige Lösung samt Erklärung. Du prüfst sie und sagst „Ja“ – dann wird sie bereitgestellt. Die Reihenfolge ist wichtig: Löse zuerst das Problem des Nutzers (Zugang gewähren, dich entschuldigen), dann untersuche die Ursache und die Finanzen.

Noch eine Regel für den Zugriff der KI auf die Produktionsdatenbank: Gib ihr einen schreibgeschützten Nutzer und verberge personenbezogene Daten hinter einer Zwischenschicht, sodass der Agent „Name“ statt des echten Namens einer Person sieht. Dann kann er selbst im Fehlerfall Produktionsdaten physisch weder löschen noch beschädigen. Bei dem Vorfall aus der Tabelle oben, bei dem ein Agent die Produktionsdatenbank löschte, fehlte genau diese Einschränkung. Der Leitfaden Was tun, wenn KI deine Datenbank gelöscht hat erklärt, was zu tun ist, wenn die Katastrophe bereits eingetreten ist.

Wann ist es Zeit, ein Produkt einzustellen?#

Der am meisten unterschätzte Teil der Wartung ist zu wissen, wann man damit aufhören sollte. Jeder, der viel entwickelt, hat einen Friedhof von Projekten: eins gebaut, daran herumgebastelt und dann aufgegeben. Das ist normal und kein Scheitern. Scheitern bedeutet, etwas monatelang aus Reue über die investierte Zeit mitzuschleppen, obwohl es niemand nutzt.

An diesen Schwellenwerten kannst du dich bei der Entscheidung orientieren:

1. Zwei Wochen – genug Zeit, um zu sehen, ob eine Idee funktioniert. Wenn die ersten echten Nutzer wiederkommen, mach weiter. Schweigen ist eine Antwort.
2. Drei Monate – die harte Grenze. Wenn das Produkt in drei Monaten nicht durchgestartet ist, stelle es ein. Beim Tempo von Vibe Coding ist es zu lang, sechs Monate mit dem Testen einer Idee zu verbringen.

Ein Projekt zu schließen ist psychologisch schwer. Betrachte es deshalb als Entscheidung, nicht als Gefühl. Ein Projekt loszulassen, in das du investiert hast, ist wie einen Mitarbeiter zu entlassen, der die Arbeit nicht schafft: unangenehm, aber ihn zu behalten kostet mehr, als ihn gehen zu lassen.

Wartung ist die Arbeit, die ein Produkt am Leben und für Menschen nützlich hält. Alles andere – Git, Backups, Monitoring – ist nur ein Werkzeug, das dir dabei hilft, den Punkt zu erreichen, an dem das Produkt jeden Tag für dich arbeitet.

Ein Produkt an einem Abend mit KI zu entwickeln, ist die halbe Arbeit. Es am Leben und sicher zu halten, während es wächst – das bedeutet Vibe Coding für Erwachsene.

Für deinen nächsten Schritt – Ailoot.