Vibe Coding bedeutet nicht Wartung im Autopilot

TL;DR: Vibe Coding hat die Build-Phase um das 10- bis 20-Fache komprimiert. Die Wartung wurde nicht proportional schneller. AI-gebaute Apps brauchen weiterhin Dependency-Updates, Sicherheitspatches, Refactoring, Observability, Incident Response und Kostenmonitoring. Manche Wartungsarbeit hat sich komprimiert (KI hilft bei Refactoring, Dependency-Updates); andere nicht (Architekturentscheidungen, Sicherheitsaudits, operative Disziplin). Gründer, die AI-gebaute Apps als "einmal bauen, dann vergessen" behandeln, häufen schnell technische Schulden an. Die Wartungsdisziplin, die reife Engineering-Teams über Jahrzehnte entwickelt haben, gilt weiterhin. Dieser Guide beschreibt, welche Wartungsarbeit weiterhin nötig ist, wobei KI hilft, wobei nicht, und die realistische laufende Disziplin für AI-gebautes SaaS.

Einleitung

Vibe Coding hat die Build-Phase drastisch komprimiert. Eine SaaS-Anwendung, die 2020 3–6 Monate brauchte, wird 2026 in 1–2 Wochen ausgeliefert. Die Build-Ökonomie hat sich zugunsten kleiner Betreiber gedreht, auf eine Weise, die Indie-SaaS wirklich verändert hat. Aber die Wartungsökonomie hat sich nicht proportional komprimiert. AI-gebaute Apps sammeln weiterhin Dependency-Updates, Sicherheitspatches, Refactoring-Bedarf, Lücken in der Observability, Incident-Response-Arbeit und Verantwortung fürs Kostenmonitoring an.

Ein wachsendes Muster 2026: Gründer shippen AI-gebaute Apps in Tagen, behandeln sie als "einmal bauen, dann vergessen" und stellen 6–12 Monate später fest, dass sich in der Codebasis erhebliche technische Schulden angesammelt haben. Veraltete Dependencies mit bekannten CVEs. Drift zwischen Datenbankschema und Code-Erwartungen. KI-Rechnungen, die durch unbeobachtete Nutzungsmuster in die Höhe schießen. Keine Observability für Produktionsprobleme. Sicherheitslücken, die sich über die Zeit summiert haben.

Das ist nicht die Schuld der KI. Die Wartungsdisziplin, die reife Engineering-Teams über Jahrzehnte entwickelt haben — Dependency-Hygiene, Security-Review, Refactoring-Rhythmus, Investition in Observability, Incident Response, Kostenmonitoring — gilt weiterhin für AI-gebaute Apps. Bei einem Teil dieser Arbeit hilft KI wirklich; bei einem Teil nicht. Dieser Guide beschreibt die realistische Wartungsdisziplin für AI-gebautes SaaS.

Was "Wartung" tatsächlich bedeutet

Wartung ist alles, was mit einer Codebasis nach dem ersten Shipping passiert. Sie ist nicht glamourös; sie ist nicht das, worauf Gründer typischerweise planen. Aber sie ist der Unterschied zwischen einem Produkt, das jahrelang zuverlässig läuft, und einem, das zu einem Sicherheitsvorfall oder Performance-Desaster verkommt.

Kategorien von Wartungsarbeit

• Dependency-Updates — Packages bekommen Sicherheitspatches, Bugfixes, Breaking Changes
• Sicherheitsaudits — Schwachstellen finden und beheben, bevor sie ausgenutzt werden
• Refactoring — Code aufräumen, der über viele Feature-Ergänzungen hinweg unordentlich geworden ist
• Observability — Produktionsverhalten überwachen; verstehen, was gerade passiert
• Incident Response — Produktionsprobleme behandeln, wenn sie auftreten
• Kostenmonitoring — besonders KI-API-Kosten, die unerwartet skalieren können
• Datenbankwartung — Index-Optimierung, Query-Performance, Schema-Migrationen
• Performance-Optimierung — Verlangsamungen begegnen, wenn die Nutzung skaliert
• Compliance-Updates — sich an veränderte regulatorische Anforderungen anpassen
• Browser-/Runtime-Kompatibilität — aktualisieren, während sich Plattformen weiterentwickeln

Wobei KI bei der Wartung wirklich hilft

Dependency-Updates

• AI-IDEs (Cursor, Windsurf) können Breaking Changes in Dependency-Updates prüfen
• Automatische PR-Erstellung für routinemäßige Versionssprünge (Renovate, Dependabot)
• KI kann Fixes vorschlagen, wenn Dependency-Updates Code brechen
• Reduziert die manuelle Review-Zeit bei Routine-Updates deutlich

Refactoring

• AI-IDEs übernehmen große Refactorings (Komponenten extrahieren, Muster umbenennen)
• Dateiübergreifendes Refactoring deutlich schneller als manuell
• Reduziert Duplizierung und räumt Muster auf
• Modernisiert veraltete Muster auf aktuelle Best Practices

Code-Review und Audit

• KI erkennt gängige Sicherheitsmuster (SQL-Injection, XSS, hartcodierte Secrets)
• Findet Performance-Probleme und Anti-Patterns
• Identifiziert Bereiche, in denen Tests fehlen

Dokumentationsgenerierung

• Automatisch generierte Docs aus dem Code
• API-Dokumentation aus OpenAPI-Spezifikationen
• README-Updates aus Code-Änderungen

Test-Schreiben

• KI generiert Testfälle für bestehenden Code
• Von KI generierte Tests brauchen ein Review zur Qualitätssicherung
• Reduziert die Zeit fürs Test-Schreiben deutlich

Wobei KI nicht hilft (oder weniger)

Architekturentscheidungen

• Ob ein neuer Service hinzukommt, das Datenmodell sich ändert, Technologien gewechselt werden
• Trade-off-Analyse zwischen Ansätzen
• Langfristige Auswirkungen struktureller Änderungen
• KI generiert innerhalb der Architektur; Menschen entscheiden über die Architektur

Sicherheitsaudits

• KI erkennt offensichtliche Muster; übersieht subtile Probleme
• Authentifizierungs- und Autorisierungslogik braucht menschliches Review
• Compliance-Anforderungen (HIPAA, SOC 2, GDPR) brauchen menschliches Urteilsvermögen
• Threat Modeling erfordert menschliches Verständnis der Angriffsfläche

Performance-Debugging

• Produktions-Performance-Probleme haben oft unerwartete Ursachen
• KI hilft bei Hypothesen; die Ursachenforschung ist Menschensache
• Query-Optimierung bei der Datenbank erfordert Verständnis der Nutzungsmuster
• Kapazitätsplanung braucht menschliches Urteilsvermögen

Incident Response

• Produktionsprobleme erfordern schnelles menschliches Urteilsvermögen
• KI hilft bei Hypothesen, kann aber den Incident nicht leiten
• Kundenkommunikation während Vorfällen ist Menschenarbeit
• Post-Mortems erfordern menschliche Analyse

Strategische technische Entscheidungen

• Wann Plattformen migriert werden
• Wann neue Technologien eingeführt werden
• Wann refactored statt neu geschrieben wird
• Build-vs.-Buy-Entscheidungen

Der realistische laufende Wartungsplan

Wöchentlich

• Produktions-Fehlerrate prüfen (Sentry oder Äquivalent)
• KI-API-Kostentrend prüfen
• Produktionsvorfälle der vergangenen Woche triagieren
• Ausstehende Dependency-Update-PRs prüfen
• Support-Tickets auf Produktprobleme prüfen

Monatlich

• Dependency-Updates anwenden (mindestens Sicherheitspatches)
• Datenbank-Performance prüfen (langsame Queries)
• Observability-Lücken aus Vorfällen dieses Monats prüfen
• Schwachstellen aus der Entwicklung prüfen und refactoren
• Wissensdatenbank/Dokumentation mit Erkenntnissen aktualisieren

Quartalsweise

• Sicherheitsaudit (Dependencies, Auth-Flows, Umgang mit sensiblen Daten)
• Performance-Review (Latenztrends, Kapazitätsplanung)
• Kosten-Review (Hosting, KI-APIs, Drittanbieterdienste)
• Angehäufte technische Schulden refactoren
• Architektur gegen aktuelle Produktanforderungen prüfen

Jährlich

• Große Versions-Upgrades (Node.js, Next.js usw.)
• Compliance-Review (GDPR, CCPA, branchenspezifisch)
• Größeres Refactoring nach Bedarf
• Tech-Stack gegen Alternativen neu bewerten

Dependency-Hygiene

• Renovate oder Dependabot einrichten, um PRs für Dependency-Updates zu erstellen
• Sicherheitspatches sofort reviewen und mergen (oft automatisiert)
• Minor-Versionen wöchentlich oder zweiwöchentlich reviewen und mergen
• Major-Versionen monatlich reviewen (oft mit Breaking Changes)
• Dependencies nicht mehr als 1 Major-Version zurückfallen lassen
• Lock-Files im Repo committen (package-lock.json oder yarn.lock)
• Vor dem Mergen von Dependency-Updates in CI testen

Sicherheitswartung

• Security-Advisories für deinen Stack abonnieren (Next.js, Supabase usw.)
• Sicherheitspatches umgehend anwenden, wenn sie angekündigt werden
• Vierteljährliches Review von Auth-Flows und RLS-Policies
• Jährliches Sicherheitsaudit (selbst durchgeführt oder extern, je nach Größe)
• Auf CVEs in Dependencies achten (npm audit, GitHub-Sicherheitswarnungen)
• API-Keys und Secrets regelmäßig rotieren
• Nutzerberechtigungen und Admin-Zugriff vierteljährlich prüfen
• Jährliche Penetrationstests, wenn sensible Daten verarbeitet werden

Investition in Observability

• Fehler-Monitoring (Sentry, Bugsnag oder Äquivalent) — von Tag eins an nicht optional
• Application-Monitoring (Vercel Analytics, Datadog oder Ähnliches)
• Datenbank-Monitoring (Supabase-Dashboards, eigene Queries)
• Log-Aggregation (Logtail, Datadog oder einfaches Logging nach Supabase)
• Alerting auf Kennzahlen (Anstieg der Fehlerrate, Latenzanstieg, Kostenanstieg)
• Dashboards für tägliche Check-ins

KI-Kostenmonitoring (spezifisch für AI-gebaute Apps)

• KI-API-Kosten können mit Nutzungsmustern unerwartet skalieren
• Kosten pro aktivem Nutzer als primäre Kennzahl tracken
• Bei täglichen Kosten über einem Schwellenwert alarmieren
• KI-Antworten wo sinnvoll cachen (semantisches Caching)
• Für einfachere Aufgaben kleinere Modelle nutzen (Model-Routing)
• Prüfen, welche Features die meisten KI-Kosten verursachen; die teuersten Features optimieren
• Feste Limits/Circuit-Breaker einrichten, um ausufernde Kosten zu verhindern

Grundlagen der Incident Response

• Festlegen, was als Vorfall zählt (Schweregrade)
• Eskalationspfad dokumentieren (Gründer, On-Call-Rotation im Team)
• Ein Runbook für gängige Probleme haben (Datenbank down, API-Limit erreicht usw.)
• Status-Seite oder Kundenkommunikations-Vorlage bereithalten
• Post-Mortem-Vorlage für jeden bedeutenden Vorfall
• Vorfallhäufigkeit und Time-to-Resolution als laufende Kennzahl tracken
• Nach einem Vorfall: systemische Ursachen identifizieren und beheben

Refactoring-Disziplin

Wenn AI-gebauter Code technische Schulden ansammelt

• Mehrere Prompt-Iterationen erzeugen inkonsistente Muster
• Generierter Code kann Logik an mehreren Stellen duplizieren
• Namenskonventionen können über Dateien hinweg driften
• Komponentengrenzen müssen möglicherweise angepasst werden, während sich das Produkt weiterentwickelt

Refactoring-Rhythmus

• Monatlich: kleines Refactoring während der Feature-Arbeit
• Vierteljährlich: dedizierter Refactoring-Sprint (1–2 Tage)
• Jährlich: umfangreicheres Refactoring, während das Produkt reift
• AI-IDEs für große Refactorings nutzen
• Refactoring-Schulden nicht über 3 Monate hinaus anhäufen lassen

Datenbankwartung

• Log für langsame Queries überwachen
• Indizes hinzufügen, wo Queries zu viele Zeilen scannen
• Regelmäßig vacuumen und analysieren (die meisten Managed-Postgres-Dienste übernehmen das)
• Alte Daten regelmäßig archivieren (Audit-Logs, alte Events)
• Migrationen planen, die Tabellen nicht blockieren (Online-Migrationen)
• Backup-Verifizierung — den Restore-Prozess vierteljährlich testen
• Erschöpfung des Connection-Pools überwachen

Häufige Fehler bei der Wartung von AI-gebauten Apps

• AI-gebaute Apps als "einmal bauen, dann vergessen" behandeln — Wartungsdisziplin gilt unabhängig davon, wie der Code generiert wurde.
• Dependency-Updates überspringen — Schwachstellen sammeln sich an. Richte von Tag eins an automatisierte PRs ein.
• Keine Observability — Ohne Monitoring weißt du nicht, was in Produktion passiert. Sentry mindestens von Tag eins an.
• KI-Kostenwachstum ignorieren — Kosten können unerwartet skalieren. Von Tag eins an tracken.
• Sicherheitsaudits überspringen — KI generiert plausibel wirkenden Code, der subtile Sicherheitsprobleme haben kann. Vierteljährlich auditieren.
• Kein Incident-Runbook — Wenn etwas kaputtgeht, willst du nicht bei null anfangen zu denken. Häufige Szenarien dokumentieren.
• Anhäufung von Refactoring-Schulden — Iterative KI-Generierung erzeugt Inkonsistenzen. Vierteljährlich refactoren.
• Keine Backup-Verifizierung — Ungetestete Backups sind nicht verlässlich. Restore vierteljährlich testen.
• Post-Mortems überspringen — Vorfälle, die nicht analysiert werden, wiederholen sich. Jeden bedeutenden dokumentieren.
• Datenbankwartung unterschätzen — Schemata driften; Queries werden langsam; Indizes hinken hinterher. Monatlich prüfen.

Häufig gestellte Fragen

F1: Wie viel Zeit pro Woche kostet Wartung wirklich? Indie-SaaS bei 0–10.000 $ MRR: 2–4 Stunden/Woche. 10.000–100.000 $ MRR: 4–10 Stunden/Woche. 100.000 $+ MRR: 10+ Stunden/Woche oder eine dedizierte Person. Die Disziplin zählt mehr als die investierte Zeit.

F2: Sollte ich einen Engineer für die Wartung einstellen? Kommt auf deinen Hintergrund an. Nicht-technische Gründer sollten mindestens für Sicherheitsaudits und Incident Response Engineering-Hilfe holen. Technische Gründer können die Wartung länger selbst übernehmen.

F3: Was ist die größte Wartungsfalle bei AI-gebauten Apps? Kostenwachstum durch KI-APIs. Apps mit KI-Features können überraschend variable Kosten haben, abhängig von Nutzungsmustern. Von Tag eins an überwachen; Alerts einrichten; wo sinnvoll aggressiv cachen.

F4: Woran erkenne ich, dass Refactoring nötig ist? Anzeichen: Änderungen fühlen sich langsam an; Bugs häufen sich in bestimmten Bereichen; duplizierte Logik taucht auf; Tests laufen durch, aber du vertraust dem Code nicht. Wenn du diese Anzeichen bemerkst, ist Refactoring überfällig.

F5: Sollte ich für die Wartung denselben AI-App-Builder nutzen? Anfangs ja; langfristig wechseln die meisten Teams für laufende Wartungsarbeit zu AI-IDEs (Cursor). AI-App-Builder glänzen bei der Generierung; AI-IDEs glänzen bei der Modifikation bestehenden Codes.

F6: Was ist mit technischen Schulden, die sich bei handgeschriebenem Code sowieso ansammeln würden? Ja — jeder Code sammelt Schulden an. KI-generierter Code sammelt Schulden mit etwas anderen Mustern an (inkonsistente Abstraktionen, duplizierte Logik über Iterationen hinweg), aber ähnlicher Größenordnung. Wartungsdisziplin gilt für alle Codebasen.

F7: Wann sollte ich größere Refactorings oder Neuschreibungen einplanen? In den ersten 2 Jahren selten nötig, wenn die Wartungsdisziplin gut ist. Inkrementelles Refactoring schlägt in den meisten Fällen periodische Neuschreibungen.

Fazit

• Vibe Coding hat die Build-Phase um das 10- bis 20-Fache komprimiert. Die Wartung wurde nicht proportional schneller. AI-gebaute Apps brauchen weiterhin Dependency-Updates, Sicherheitspatches, Refactoring, Observability, Incident Response, Kostenmonitoring.
• KI hilft bei einem Teil der Wartung (Refactoring, Dependency-Review, Test-Generierung, Dokumentation). Bei Architekturentscheidungen, Sicherheitsaudits, Performance-Debugging und Incident Response hilft KI weniger.
• Realistischer Plan: wöchentliche Checks (Fehler, Kosten, Vorfälle), monatlich (Dependency-Updates, Performance), vierteljährlich (Sicherheitsaudit, Refactoring), jährlich (große Upgrades, Compliance-Review). 2–10 Stunden/Woche, je nach Größe.
• Die Wartungsdisziplin, die reife Engineering-Teams über Jahrzehnte entwickelt haben, gilt weiterhin. Gründer, die AI-gebaute Apps als "einmal bauen, dann vergessen" behandeln, häufen schnell technische Schulden an.

Wenn du ein AI-gebautes SaaS betreibst und dein Wartungsplan "immer dann, wenn etwas kaputtgeht" lautet, häufst du Schulden an. Richte diese Woche Sentry ein. Konfiguriere Renovate für Dependency-Updates. Plane monatliche Zeit für Security-Review und Refactoring ein. Verfolge KI-Kosten wöchentlich. Vibe Coding ist die Build-Phase; die Wartungsdisziplin entscheidet, ob dein SaaS zuverlässig weiterläuft oder mit der Zeit verfällt. Nimm es ernst. Baue die Gewohnheiten auf. Die Vibe-Coding-Gründer, die langfristig erfolgreich sind, behandeln Wartung als operative Kerndisziplin, nicht als Nachgedanken.