So veränderst du eine KI-gebaute App, ohne sie kaputtzumachen

Um eine KI-gebaute App zu verändern, ohne sie kaputtzumachen, ändere pro Prompt nur eine Sache, prüf sie in der Vorschau und speichere einen Checkpoint, bevor du weitergehst. Beschreib, was du siehst, statt was du im Code vermutest. Plane große Änderungen, bevor du sie baust. Und wenn eine Änderung schiefgeht, geh zur letzten funktionierenden Version zurück, statt die KI ihren eigenen Fix reparieren zu lassen.

Die erste Version einer App steht oft in Minuten. Schwierig wird die fünfzigste Änderung, wenn jeder neue Prompt etwas gefährdet, das schon funktioniert hat. Dieser Leitfaden beschreibt die Schleife, die das verhindert.

Die Iterationsschleife

1. Wähle eine Änderung. Eine Funktion, ein Fehler, eine Seite.
2. Beschreib sie so, wie der Nutzer es sieht und tut.
3. Plane große Änderungen zuerst. Lass dir einen Plan geben, lies ihn, dann bauen.
4. Prüf das Ergebnis in der Vorschau: die Änderung und die Abläufe in ihrer Nähe.
5. Speichere einen Checkpoint oder Commit.
6. Wiederhole.

Jeder Schritt dient dazu, Änderungen klein und rückgängig machbar zu halten.

Schritt 1: Führ eine kurze Liste

Schreib vor dem Prompt auf, was du ändern willst, nach Wichtigkeit sortiert. So schickst du keinen Absatz mit zehn Wünschen auf einmal, und du kannst Ideen, die dir mittendrin kommen, auf später verschieben.

Ist eine Änderung groß, zerleg sie. „Teamkonten hinzufügen“ wird zu: Teams anlegen, ein Mitglied einladen, zwischen Teams wechseln, Daten auf das aktuelle Team beschränken. Jeder Punkt ist ein eigener Prompt. User Stories schreiben hilft dabei.

Schritt 2: Beschreib, was du siehst

Die KI kann deinen Bildschirm nicht sehen, außer du sagst es ihr. Zeig auf konkrete Dinge und sag, was passieren soll:

Auf der Preisseite am Handy ist der Button der Pro-Karte am rechten Rand abgeschnitten. Lass das Desktop-Layout gleich; unter 640 px sollen die Karten untereinander stehen und die Buttons die volle Breite haben.

Vergleich das mit „Die Preisseite sieht auf dem Handy schlecht aus“. Die erste Beschreibung lässt sich in einem Durchgang umsetzen und prüfen. Die zweite lädt zu einem Redesign ein, das du nicht wolltest.

Screenshots helfen. Wenn dein Baukasten Bilder annimmt, hänge eines an und markiere das Problem.

Schritt 3: Plane vor großen Änderungen

Alles, was mehrere Teile der App betrifft – ein neues Datenmodell, Zahlungen, Nutzerrollen –, bekommt zuerst einen Plan, bevor sich Code ändert:

Ändere noch keinen Code. Ich möchte, dass Nutzer zu Teams gehören und nur die Projekte ihres Teams sehen. Plane die Änderung: Welche Tabellen, Seiten und API-Routen ändern sich, was passiert mit den Daten bestehender Nutzer, und in welcher Reihenfolge würdest du sie bauen?

Lies den Plan. Wenn er falsch ist, ist ein korrigierter Plan viel günstiger als das Rückgängigmachen eines Builds.

Schritt 4: Sag, was sich nicht ändern darf

KI-Werkzeuge „räumen“ manchmal Dinge auf, nach denen du nicht gefragt hast. Schütze, was funktioniert:

Füge der Bestellungstabelle einen Datumsfilter hinzu. Ändere nicht die Spalten der Tabelle, das Styling oder den Export-Button.

Für Regeln, die überall gelten – Markenfarben, Tonalität, „Daten nie ohne Bestätigung löschen“ –, leg sie in einer Projektnotiz oder einer Wissensdatei ab, die die KI bei jeder Nachricht liest. Wiederhol sie nicht ständig.

Schritt 5: Prüf mehr als nur die Änderung

Teste nach jedem Prompt:

• Die Änderung selbst. Tut sie, was du verlangt hast, am Desktop und am Handy?
• Die Nachbarn. Dinge auf derselben Seite und Abläufe, die dieselben Daten nutzen.
• Den kritischen Pfad. Anmelden, abmelden, die Hauptaktion, Zahlung. Ein halbminütiger Durchgang nach jeder großen Änderung fängt die meisten Schäden früh ab.

Wenn etwas nicht stimmt, beschreib es genau. Siehe So schreibst du einen guten Fehlerbericht.

Schritt 6: Zurückgehen, statt zu stapeln

Wenn eine Änderung etwas kaputt macht und der erste Fix nicht hilft, halt an. Jede weitere „Korrektur“ baut auf einem kaputten Zustand auf, und die Probleme verstärken sich.

Stattdessen:

1. Geh zur letzten funktionierenden Version zurück (einem Checkpoint oder Git-Commit).
2. Finde heraus, was am Prompt unklar war.
3. Versuch es noch einmal mit einer kleineren oder klareren Anfrage.

Die Änderung hat das Speichern von Entwürfen kaputtgemacht. Ich habe zurückgesetzt. Diesmal nur: Füge den Autosave-Hinweis als Text in der Kopfzeile hinzu. Ändere nicht, wie Entwürfe gespeichert werden.

Schritt 7: Wisse, wann ein Neubau richtig ist

Ein Neubau von Grund auf wirft viele funktionierende Details weg. Er lohnt sich nur, wenn:

• sich die Produktidee komplett geändert hat;
• die Grundstruktur das Nötige nicht tragen kann – zum Beispiel wurde sie als statische Seite gebaut und braucht jetzt Konten und eine Datenbank;
• das Projekt noch fast leer ist.

Wenn du neu baust, schreib auf, was du behalten willst: Name, Farben, Texte, die Teile, die Nutzern gefallen haben.

Beispiel-Prompts

Bevor wir weitermachen: Fass zusammen, wie die App aktuell funktioniert: Seiten, gespeicherte Daten und alles, was dir zerbrechlich vorkommt.

Ich möchte wiederkehrende Buchungen hinzufügen. Was ist die kleinste Version, die schon nützlich wäre? Schlag sie als drei getrennte Änderungen vor, die wir nacheinander umsetzen können.

Prüf die letzten drei Änderungen, ob eine davon den Bezahlvorgang beschädigt haben könnte. Noch nicht bearbeiten.

Häufige Fehler

• Zehn Anfragen in einem Prompt. Manches wird erledigt, manches halb, und du kannst nicht sagen, was.
• Vage Rückmeldungen. „Es ist kaputt“ oder „mach es besser“ führt zu Vermutungen.
• Nie die Nachbarn prüfen. Eine Änderung an einer gemeinsamen Komponente bricht drei andere Seiten.
• Fixes auf Fixes. Vier Prompts tief in einem Fehler: zurückgehen.
• Den Kontext immer wieder wiederholen, statt dauerhafte Regeln in Projektnotizen abzulegen.
• Neu bauen, wenn man festhängt. Die meisten „Neustart“-Momente sind eigentlich „zwei Schritte zurück“.

Checkliste

• Ein Ziel pro Prompt.
• Ich beschreibe, was ich sehe und was passieren soll.
• Große Änderungen bekommen einen Plan, bevor es Code gibt.
• Ich sage, was sich nicht ändern darf.
• Nach jeder Änderung teste ich sie, ihre Nachbarn und den kritischen Pfad.
• Ich speichere einen Checkpoint oder Commit nach jeder funktionierenden Änderung.
• Schlägt ein Fix fehl, gehe ich zurück, statt Fixes zu stapeln.
• Dauerhafte Regeln stehen in Projektnotizen, die die KI jedes Mal liest.

Mit Mythex iterieren

Mythex baut auf dieser Schleife auf:

• Modi Plan, Build und Ask. Plan bespricht den Ansatz, bevor etwas bearbeitet wird; Ask beantwortet Fragen, ohne Code zu ändern; Build setzt die Änderung um. Siehe Chat.
• Checkpoints. Nach jeder erfolgreichen Runde speichert Mythex einen Git-Checkpoint; Zu diesem Punkt zurückkehren macht die Änderungen rückgängig. Du kannst auch eine frühere Nachricht bearbeiten und mit Verwerfen und erneut senden einen anderen Prompt von dort aus versuchen. Siehe Ohne Neubau iterieren.
• Wissen. Unter Projekteinstellungen → Wissen stehen dauerhafte Notizen, denen der Agent bei jeder Nachricht folgt.
• /test lässt den Agenten nach einer großen Änderung die Vorschau wie ein Nutzer durchklicken.

Kürzere Anfragen kosten außerdem weniger Credits. Wie du die Prompts selbst schreibst, steht in So schreibst du Prompts für KI-App-Baukästen; wenn etwas kaputtgeht, hilft So debuggst du eine KI-gebaute App.

Fragen