Reparieren, refaktorieren oder neu bauen?

Ein funktionierender Prototyp kann unübersichtlichen Code enthalten und trotzdem wertvolle Entscheidungen abbilden. Vielleicht macht er einen Arbeitsablauf erstmals greifbar, der sich vorher kaum erklären ließ. Umgekehrt kann hinter einer überzeugenden Oberfläche eine Struktur stecken, die notwendige Zugriffsregeln nicht durchsetzt. Weder das Aussehen noch der Einsatz von KI entscheidet darüber, ob Reparatur, Refactoring oder Neubau sinnvoll ist.

Trenne zuerst das fachliche Verhalten, das erhalten bleiben soll, von der technischen Umsetzung, die verändert werden darf. Die Frage ist nicht, ob ein Entwickler den Code anders geschrieben hätte. Entscheidend ist, ob die bestehende Anwendung deine Anforderungen mit vertretbarem Aufwand und Risiko erfüllen kann.

Erst das Problem benennen

„Vibe Code aufräumen“ ist keine ausreichend konkrete Aufgabe. Formuliere beobachtbare Probleme: Nutzer sehen fremde Datensätze; die Bereitstellung benötigt manuelle Änderungen; ein kleiner Eingriff beschädigt mehrere Oberflächen; ein Bericht läuft in einen Timeout; niemand kann die Datenbank wiederherstellen; oder das Tool funktioniert nur im persönlichen Konto seines Erstellers.

Halte für jedes Problem den betroffenen Ablauf, die fachliche Folge, die Häufigkeit und den Nachweis fest. Eine reproduzierbare Umgehung von Berechtigungen ist etwas anderes als eine ungewohnte Ordnerstruktur. Ein langsamer Bericht unterscheidet sich von fehlerhaften Auftragsdaten. Diese Trennung verhindert, dass Stilfragen wichtigere Probleme verdrängen.

Dokumentiere auch das Funktionierende: typische Eingaben und erwartete Ergebnisse, wichtige Bildschirmzustände, Berechnungsbeispiele und Regeln hinter Freigaben. Daraus entsteht eine Grundlage für spätere Vergleiche. Ohne sie kann ein Neubau genau das Verhalten verlieren, das den Prototyp nützlich gemacht hat.

Reparieren, wenn der Fehler eingegrenzt ist

Eine Reparatur verändert ein konkretes Verhalten mit begrenzten Auswirkungen auf die Umgebung. Beispiele sind eine fehlende serverseitige Berechtigungsprüfung, eine falsche Berechnung, unvollständige Eingabeprüfung oder die Absicherung einer externen Aktion gegen doppelte Ausführung.

Das ist sinnvoll, wenn die Ursache verstanden wird und die bestehende Struktur eine belastbare Korrektur erlaubt. Auch eine kleine Reparatur braucht eine Prüfung. Eine geschützte Oberfläche hilft wenig, wenn der Export-Endpunkt weiterhin offen ist. Eine Wiederholung nach einem Timeout darf nicht versehentlich denselben Geschäftsvorgang zweimal auslösen.

Lege vorher ein Abnahmebeispiel fest: Der Eigentümer darf einen privaten Datensatz lesen, ein berechtigter Kollege ebenfalls, ein unbeteiligter Nutzer dagegen auch über einen direkten API-Aufruf nicht. Entscheidend ist nachgewiesenes Verhalten, nicht das bloße Vorhandensein einer beruhigend benannten Funktion.

Refaktorieren, wenn Änderungen selbst riskant werden

Refactoring verändert die innere Struktur und soll dabei das beobachtbare Verhalten erhalten. Es kann Geschäftsregeln von Darstellung trennen, wiederholte Zugriffslogik zusammenführen, Konfiguration explizit machen oder die Abhängigkeit von einer bestimmten Bereitstellungsumgebung reduzieren.

Verbinde die Arbeit mit einem konkreten Bedarf. Wenn drei Kopien einer Berechnung auseinanderlaufen, kann eine gemeinsame Umsetzung Fehler vermeiden. Wenn ein zweiter Arbeitsbereich hinzukommt, müssen Datenabgrenzungen möglicherweise zuerst deutlicher werden. „Schönerer Code“ allein liefert keinen sinnvollen Endpunkt.

Arbeite schrittweise: einen wichtigen Ablauf gezielt absichern, eine Verantwortung verschieben, Ergebnisse vergleichen und eine rücknehmbare Änderung bereitstellen. Viele unabhängige Verbesserungen auf einmal erschweren die Fehlersuche. Kleine, überprüfte Schritte lassen sich fachlich besser bewerten und bei Bedarf unterbrechen.

Neu bauen, wenn die Grundlage notwendige Anforderungen verhindert

Ein Neubau kann gerechtfertigt sein, wenn erforderliche Datengrenzen nicht zuverlässig durchsetzbar sind, die Laufzeitumgebung nicht mehr unterstützt wird, kein wiederherstellbarer Quellstand existiert oder bestehende Einschränkungen eine Anpassung teurer machen als den Ersatz eines klar abgegrenzten Teils.

Dabei entstehen Migrationskosten. Vorhandene Datensätze brauchen ein Ziel, Kennungen können in anderen Systemen verwendet werden, Nutzer benötigen einen Übergang und Integrationen dürfen nicht doppelt laufen. Häufig müssen altes und neues System zeitweise parallel betreut werden. Eine frische Codebasis beseitigt diese Aufgaben nicht.

Prüfe einen Teilersatz, bevor alles ersetzt wird. Ein instabiler Berichtsprozess lässt sich vielleicht aus einer ansonsten brauchbaren Anwendung herauslösen. Ein unterstützter Identitätsdienst kann unter Umständen die Anmeldung übernehmen, ohne den fachlichen Ablauf neu zu bauen. Die passende Grenze ergibt sich aus Code und Daten.

Nachweise statt KI-Etiketten verwenden

Forschung liefert keine allgemeine Produktivitätsgarantie für jedes Werkzeug, jede Aufgabe und jeden Entwickler. METRs Aktualisierung zur Messung KI-gestützter Entwicklung beschreibt unter anderem Auswahlverzerrungen und andere Messprobleme. Solche Ergebnisse sind keine Vorhersage für Geschwindigkeit oder Qualität deines Projekts.

Auch eine einzelne Studie zu einem Assistenten kann deine Anwendung nicht freigeben. Wir beurteilen beobachtbare Eigenschaften: reproduzierbare Builds, Zugriffskontrolle, Datenverarbeitung, Fehlerverhalten, Prüfungen wichtiger Regeln und Wiederherstellbarkeit. Diese Kriterien gelten unabhängig davon, ob Code manuell, mit einem Modell oder aus mehreren Quellen entstanden ist.

Der OWASP Application Security Verification Standard bietet eine strukturierte Referenz für Sicherheitsanforderungen. Ein begrenzter Review kann passende Anforderungen heranziehen. Das ist keine vollständige Verifikation des Standards und keine Zertifizierung.

Optionen in einer kurzen Entscheidungsvorlage vergleichen

Notiere für jede Option, was geändert und was erhalten wird, bekannte Risiken, offene Fragen, erwarteten Aufwand und Abnahmekriterien. Unterscheide eine Schätzung auf Basis geprüften Codes von einer groben Annahme. Benenne Vorarbeiten, die für eine belastbare Kalkulation erforderlich sind.

Betrachte auch die Folgen, einige Wochen nichts zu ändern. Eine vorübergehend kleine, vertrauenswürdige Nutzergruppe kann Zeit schaffen, eine schwierige Abgrenzung sauber umzusetzen. Bei einer bereits nachgewiesenen erheblichen Datenexposition kann weitere Nutzung dagegen ungeeignet sein. Die Entscheidung folgt dem konkreten Befund.

Es gibt mehr Möglichkeiten als „sofort veröffentlichen“ oder „alles neu bauen“. Eine sinnvolle Reihenfolge kann sein: einen blockierenden Fehler reparieren, Wiederherstellung sicherstellen, den nächsten Änderungsschritt durch Refactoring erleichtern und harmlose Unvollkommenheiten zunächst akzeptieren.

Einen Endpunkt vereinbaren

Eine Reparatur endet, wenn der definierte Fehler behoben und wichtige angrenzende Wege geprüft sind. Ein Refactoring endet, wenn die gewünschte Verantwortlichkeit klarer ist und das Verhalten überprüft erhalten bleibt. Ein Neubau benötigt Kriterien für Migration, Umstellung, Rückkehr zum alten Stand und dessen spätere Stilllegung.

Eine hilfreiche Empfehlung unterscheidet Blocker von Verbesserungen und benennt nicht untersuchte Bereiche. So wird die nächste Investition nachvollziehbar. Der technische Rat sollte erklären, warum etwas jetzt wichtig ist und etwas anderes warten kann.

Unser Starter Review liefert eine solche begrenzte Einschätzung für den nächsten Schritt. Der Zeitrahmen von insgesamt bis zu vier technischen Arbeitsstunden umfasst Sichtung, Bericht und Besprechung. Reparaturen, vertiefte Untersuchungen und Umsetzung werden separat vereinbart. Der Review verspricht nicht, eine ganze Anwendung innerhalb dieses Zeitrahmens produktionsreif zu machen.