So debuggst du eine mit KI gebaute App: eine praktische Methode

Um eine mit KI gebaute App zu debuggen, bringst du den Fehler zuerst absichtlich wieder zum Vorschein. Dann sammelst du Belege: die genauen Schritte, die Fehlermeldung und was die Browser-Konsole und der Netzwerk-Tab zeigen. Das gibst du der KI als „Ich habe X gemacht, erwartet habe ich Y, bekommen habe ich Z“. Wenn eine Korrektur die Lage verschlimmert, rollst du auf die letzte funktionierende Version zurück, statt weitere Korrekturen obendrauf zu stapeln. Du musst den Code dafür nicht lesen.

Dieser Leitfaden beschreibt die ganze Schleife, einschließlich eines kurzen Überblicks über die Browser-Entwicklertools für Nicht-Entwickler.

Die Debugging-Schleife

Jede Fehlerbehebung folgt derselben Schleife, egal ob eine Person oder eine KI sie macht:

1. Reproduzieren: Den Fehler verlässlich auslösen.
2. Beobachten: Die Fehlermeldung und das festhalten, was die App gerade tat.
3. Beschreiben: Der KI präzise Schritte, erwartetes und tatsächliches Ergebnis geben.
4. Beheben: Die KI eine Sache ändern lassen.
5. Prüfen: Die exakten Schritte wiederholen und bestätigen, dass der Fehler behoben ist und nichts daneben kaputtgegangen ist.
6. Zurückrollen, falls nötig: Wenn es schlimmer wurde, rückgängig machen und mit besseren Informationen erneut versuchen.

Die meiste Zeit geht bei KI-gebauten Apps verloren, wenn die Schritte 1, 2 und 5 übersprungen werden: „Es ist kaputt“ sagen, eine Änderung ungetestet übernehmen und dann noch eine Korrektur auf eine kaputte Version verlangen.

Schritt 1: Den Fehler reproduzieren

Ein Fehler, den du auf Abruf auslösen kannst, ist zur Hälfte behoben. Versuche, die kürzeste Abfolge von Schritten zu finden, die ihn auslöst.

Frag dich:

• Passiert es jedes Mal? Wenn nur manchmal, was ist anders, wenn es passiert: ein bestimmter Datensatz, eine langsame Verbindung, eine abgemeldete Sitzung?
• Passiert es bei jedem Nutzer? Melde dich mit einem anderen Konto an. Viele Fehler treten nur bei neuen Nutzern ohne Daten auf oder bei einem Nutzer mit anderer Rolle.
• Passiert es auf jedem Gerät? Probiere eine Bildschirmbreite wie beim Handy und einen anderen Browser.
• Hat es nach einer bestimmten Änderung angefangen? Wenn es gestern noch funktionierte, sind die letzten Änderungen die wahrscheinlichsten Verdächtigen.

Schreib die Schritte als kurze nummerierte Liste auf. Du fügst sie später in den Prompt ein.

Schritt 2: Die Fehlermeldung lesen

Fehlermeldungen wirken einschüchternd, doch du brauchst nur ein paar Teile davon.

Du musst sie nicht verstehen, du musst sie genau kopieren. „Cannot read properties of undefined (reading 'name')“ sagt der KI, dass der Code Daten erwartet hat (wahrscheinlich eine Buchung oder einen Nutzer), die nicht da waren. Eine Umschreibung wie „irgendein undefined-Fehler“ verliert genau diese Information.

Ein paar häufige Fälle, grob übersetzt:

• undefined- / null-Fehler: Der Code erwartete Daten, die nicht ankamen. Oft ein Ladezustand oder eine leere Liste, die der Code nicht behandelt.
• 404 Not Found: Die Seite oder API-Adresse existiert nicht. Oft ein Tippfehler in einer Route oder ein Link zu einer umbenannten Seite.
• 401 Unauthorized / 403 Forbidden: Die Anfrage war nicht angemeldet, oder der Nutzer darf das nicht.
• 500 Internal Server Error: Der serverseitige Code ist abgestürzt. Der eigentliche Grund steht in den Server-Logs, nicht im Browser.
• CORS-Fehler: Der Browser hat eine Anfrage an eine andere Domain blockiert. Meist ein Konfigurationsproblem auf der Serverseite.

Schritt 3: Die Browser-Entwicklertools nutzen

Jeder Desktop-Browser hat eingebaute Entwicklertools („DevTools“). Sie zeigen, was die Seite im Hintergrund tut. In Chrome, Edge und Firefox klickst du irgendwo auf der Seite mit der rechten Maustaste und wählst Untersuchen, oder drückst F12 (auf dem Mac Cmd+Option+I). In Safari aktivierst du zuerst das Menü Entwickler in den Safari-Einstellungen.

Du brauchst nur drei Tabs.

Konsole

Der Tab Konsole listet Fehler und Meldungen aus dem Code der Seite auf. Fehler stehen in Rot. Wenn ein Button beim Klicken nichts tut, zeigt die Konsole sehr oft genau im Moment des Klicks einen roten Fehler. Kopiere den vollständigen Text des Fehlers (in den meisten Browsern gibt es per Rechtsklick eine Kopieren-Option).

Netzwerk

Der Tab Netzwerk listet jede Anfrage auf, die die Seite stellt: Daten laden, ein Formular speichern, sich anmelden. Öffne ihn und wiederhole die Schritte, die den Fehler auslösen.

• Achte auf Zeilen in Rot oder mit dem Status 400 oder höher.
• Klicke eine fehlgeschlagene Zeile an, um deren Antwort zu sehen. Ein Serverfehler enthält dort oft eine Meldung, die hilfreicher ist als alles, was auf dem Bildschirm steht.
• Notiere die URL und den Statuscode der Anfrage. „Das POST an /api/bookings hat 500 zurückgegeben“ ist ein sehr nützlicher Satz für die KI.

Aktiviere Protokoll erhalten, wenn der Fehler mit einem Neuladen oder einer Weiterleitung zusammenhängt, damit die Anfragen nicht verschwinden.

Elemente

Der Tab Elemente (oder Inspektor) zeigt die Struktur und die Stile der Seite. Er ist vor allem bei Layoutfehlern nützlich: Wenn du mit der Maus über ein Element fährst, werden Größe und Abstände hervorgehoben. Du musst hier nichts bearbeiten. Es reicht zu sagen: „Der Footer ist auf dem Handy 2.000 Pixel breit und schiebt die Seite zur Seite“.

Schritt 4: Die Server-Logs prüfen

Manche Fehler passieren auf dem Server, den der Browser nicht sehen kann. Ein 500-Fehler im Netzwerk-Tab ist das klassische Zeichen. Server-Logs, also die Textausgabe deines Backends während es läuft, enthalten meist den eigentlichen Fehler mit einem Stack-Trace (eine Liste der Funktionen, die liefen, als es abstürzte).

Wo du sie findest, hängt von deinem Werkzeug ab. In den meisten KI-App-Buildern kannst du ein Terminal oder eine Log-Ansicht für das Projekt öffnen oder die KI einfach fragen: „Prüfe die Server-Logs auf Fehler der letzten Anfrage und sag mir, was fehlgeschlagen ist.“

Schritt 5: Den Fehler der KI beschreiben

Bring das Gesammelte in diese Form:

Auf der Seite Buchungen, angemeldet als Mitglied: Ich habe auf Stornieren bei dem Kurs morgen um 9:00 geklickt. Erwartet: Die Buchung verschwindet und der Kurs hat einen freien Platz mehr. Tatsächlich: Auf dem Bildschirm ändert sich nichts. Die Konsole zeigt TypeError: Cannot read properties of undefined (reading 'id') bei BookingCard.tsx:31, und der Netzwerk-Tab zeigt, dass DELETE /api/bookings/123 500 zurückgegeben hat. Finde die Ursache, behebe sie und prüfe, dass Stornieren funktioniert, für ein Mitglied mit einer Buchung und für eines mit mehreren.

Warum jeder Teil wichtig ist:

• Wo und als wer grenzt auf einen Bildschirm und eine Rolle ein.
• Die genauen Schritte lassen die KI den Fehler reproduzieren.
• Erwartet vs. tatsächlich legt fest, was „behoben“ bedeutet.
• Der Fehlertext und die fehlgeschlagene Anfrage zeigen direkt auf die Ursache.
• „Prüfe, dass …“ bittet die KI zu verifizieren, nicht nur zu ändern.

Hat die KI zweimal versucht zu beheben und ist gescheitert, bitte sie zu erklären, bevor sie etwas ändert:

Ändere noch keinen Code. Was glaubst du, verursacht das, und welche Belege stützen das?

Eine falsche Theorie fällt beim Ausschreiben leicht auf und ist viel günstiger zu korrigieren als eine falsche Korrektur.

Schritt 6: Prüfen, dann die Umgebung checken

Wenn die KI sagt, es sei behoben, wiederhole die exakten Schritte aus Schritt 1. Prüfe dann die Dinge drumherum:

• Dieselbe Aktion für eine andere Nutzerrolle
• Dieselbe Aktion ohne Daten und mit vielen Daten
• Seiten, die Komponenten mit der Seite teilen, die du behoben hast
• Eine Bildschirmbreite wie beim Handy, falls die Korrektur das Layout berührt hat

KI-Änderungen beheben manchmal einen Pfad und brechen stillschweigend einen anderen. Zwei Minuten Prüfung jetzt sparen eine verwirrte Stunde später.

Schritt 7: Zurückrollen statt aufstapeln

Wenn eine Korrektur die Lage verschlimmert hat oder du drei Runden ohne Fortschritt hinter dir hast, geh zurück. Auf die letzte funktionierende Version zurückzurollen und mit besseren Belegen neu zu formulieren, schlägt fast immer eine vierte Korrektur auf drei falsche. Jeder gescheiterte Versuch hinterlässt Code, und dieser Code verwirrt den nächsten Versuch.

Gute Gewohnheiten, die das Zurückrollen einfach machen:

• Nach jeder Änderung testen, damit du weißt, welche Änderung etwas kaputt gemacht hat.
• Änderungen klein halten: eine Funktion oder Korrektur pro Nachricht.
• Die letzte gute Version notieren, bevor du etwas Riskantes anfängst.
• Liegt der Code in Git, committe funktionierende Versionen, damit du dorthin zurückkehren kannst.

Typische Fehlermuster bei KI-gebauten Apps

Wenn das Problem kein Fehler ist

Manche „Fehler“ sind die KI, die genau das baut, was ihr gesagt wurde, und die Beschreibung war mehrdeutig. Wenn die gewünschte Korrektur eigentlich eine Verhaltensänderung ist, sag es klar: „Ändere es so, dass …“. Wenn du unsicher bist, wie das richtige Verhalten überhaupt aussieht, entscheide das zuerst. Unser Leitfaden zu Prompts für KI-App-Builder zeigt, wie du Regeln klar festlegst. Und wenn du eine App für echte Nutzer vorbereitest, behandelt wie du einen KI-Prototyp in die Produktion bringst die Prüfungen, die sich vor dem Start lohnen.

Debuggen in Mythex

Mythex hat Werkzeuge für jeden Schritt der Schleife:

• Vorschau, um den Fehler zu reproduzieren, auch in einem Rahmen in Handybreite.
• /test: Der Agent klickt sich durch deine Live-Vorschau wie ein Nutzer und meldet kaputte Abläufe.
• /fix richtet den Agenten gezielt auf Defekte.
• Der Modus Plan lässt den Agenten untersuchen und erklären, bevor er etwas bearbeitet.
• Code → Terminal zeigt die Server-Logs deiner App.
• Zu diesem Punkt zurücksetzen auf jeder Antwort setzt das Projekt auf diesen Checkpoint zurück.

Wenn eine Veröffentlichung fehlschlägt, bietet der Veröffentlichungsdialog meist Mit KI beheben an, das die Build-Ausgabe oder die Logs der App liest. Siehe Deine App debuggen und Fehlerbehebung bei Veröffentlichungen in der Dokumentation.

Fragen