Löschen statt migrieren: Die Refactoring-Strategie für vibe-codierte React-Native-Apps

Der Eidechsenschwanz

In der Biologie bezeichnet Autotomie den Vorgang, bei dem ein Tier einen Körperteil abwirft, der nicht länger nützlich ist. Eine Eidechse verliert ihren Schwanz, um einem Raubtier zu entkommen. Der Schwanz war einmal nützlich, aber Überleben erfordert, ihn loszulassen. Ein neuer wächst nach.

So solltest du über das Refactoring einer vibe-codierten React-Native-App denken.

In frühen KI-codierten MVPs wird der erste Auth-Flow meist schneller live gebracht, als irgendjemand erwartet. Die Probleme beginnen ein paar Wochen später, wenn sich das Produkt ändert und das Team versucht, Code vorsichtig zu refaktorieren, den es nie wirklich entworfen hat. Dann zerbricht Login, User State driftet auseinander und die Zahl der Bugs steigt. Sie versuchen, Code zu bewahren, der hätte ersetzt werden sollen.

KI-generierten Code zu refaktorieren ist teuer, weil du dafür eine Absicht verstehen musst, die du nie hattest. Claude Code hat Abstraktionen erzeugt, die du nicht entworfen hast. Es hat Coupling-Entscheidungen getroffen, denen du nie zugestimmt hast. Diesen Code zu refaktorieren bedeutet, architektonische Entscheidungen rückzuentwickeln, die probabilistisch statt absichtlich getroffen wurden.

Ersetzen, nicht refaktorieren

Die Alternative: Wenn ein Modul dasselbe Interface erfüllt und dieselben Tests besteht, kannst du es austauschen, ohne die alte Implementierung zu verstehen. Das alte Modul wird gelöscht. Das neue nimmt seinen Platz ein. Der Composition Root ist die einzige Datei, die davon weiß.

// Module A (Auth v1) -> Interface Contract -> Module A' (Auth v2)

// The old auth module. You don't need to understand it.
// Claude Code generated it. It worked. Now it's done.
class SupabaseAuthService implements AuthService {
  // ... implementation you inherited ...
}

// The new auth module. You designed it. Claude Code helps write it.
class CustomAuthService implements AuthService {
  // ... your clean implementation ...
}

// The composition root is the ONLY place that changes:
const auth: AuthService = useSupabase
  ? new SupabaseAuthService()
  : new CustomAuthService()

Der Login-Screen ändert sich nicht. Die Route Guards ändern sich nicht. Die Hooks ändern sich nicht. Nur der Composition Root weiß, dass ein Austausch stattgefunden hat. Das ist die Stärke einer interface-getriebenen Architektur, wenn du mit KI-generiertem Code arbeitest. Interfaces sind deine Versicherung gegen technische Schulden.

Vier Voraussetzungen für sicheres Löschen

Das funktioniert nur, wenn vier Dinge vorhanden sind. Ohne sie löschst du bloß Code und hoffst. Mit ihnen führst du eine Operation durch:

• Definierte Interfaces - Jedes Modul exponiert einen Contract. TypeScript-Types, API-Schemas, klare Boundaries. Cursor generiert dagegen. Claude Code liest sie. Du besitzt sie.
• Boundary Enforcement - Module dürfen nicht in die Interna anderer Module greifen. dependency-cruiser, ESLint oder Konventionen verhindern das.
• Contract Tests - Tests verifizieren das Interface, nicht die Implementierung. Wenn das neue Modul dieselben Tests besteht, ist es im Verhalten äquivalent.
• Saubere Dependency-Graphen - Keine zirkulären Dependencies. Kein implizites Coupling über Globals. Der Import-Graph ist ein DAG, kein Spinnennetz.

Analytics austauschen, ohne einen Screen anzufassen

Du bist mit Segment gestartet, weil Claude Code es vorgeschlagen hat. Jetzt brauchst du PostHog. Das alte Modul wird gelöscht. Das neue implementiert dasselbe Interface. Jede Call Site bleibt identisch:

// Before
const analytics = new SegmentAnalytics(writeKey)

// After — same interface, different implementation
const analytics = new PostHogAnalytics(apiKey)

// Every call site stays the same.
// Cursor-generated screens don't change.
analytics.track('purchase_completed', { productId: '123' })
analytics.identify(userId, { plan: 'premium' })

Der Impuls, Dinge zu bewahren, ist stark. Wir möchten unseren Code vorsichtig weitertragen und jedes Verhalten erhalten. Aber wenn du mit KI-generiertem Code arbeitest, ist der sicherste Weg oft, loszulassen. Schreibe gute Interfaces. Erzwinge Boundaries. Und dann sei bereit, zu löschen.

Das Autotomy Expo Starter Pack ist um genau diese Philosophie herum gebaut - jedes Modul ist auf Austausch, nicht auf Bewahrung ausgelegt. Wenn deine vibe-codierte App an die Skalierungswand stößt, entwirrst du nicht Claude Codes Architekturentscheidungen. Du ersetzt sie.