Häufige Probleme beim Bauen mit KI:10 Lösungen
Häufige Probleme beim Bauen mit KI, entschlüsselt: was du siehst, was darunter wirklich passiert, die genaue Lösung – und der Prompt zum Weitermachen.
Häufige Probleme beim Bauen mit KI sind fast nie neu: Wenn du beim Bauen mit KI feststeckst, ist es mit hoher Wahrscheinlichkeit eines der bekannten. Dieselben zehn Szenarien machen fast jeden „Ich habe keine Ahnung, was ich als Nächstes tun soll"-Moment aus, den ein nicht-technischer Gründer erlebt – und jedes hat eine bekannte Ursache und eine bekannte Lösung. Wieder in Fahrt zu kommen ist keine Heldentat. Es ist Mustererkennung.
Das ist die kuratierte Top Ten aus einer Liste von zwanzig Szenarien, in denen man stecken bleibt, die ich für die Teilnehmer des Kurses AI Product Builder führe – die, die immer wieder auftauchen. Finde dein Symptom in der Tabelle, verstehe, was wirklich passiert, wende die Lösung an. Wenn du noch nicht gelernt hast, Fehlermeldungen in der Browser-Konsole zu lesen, tu das zuerst – es verwandelt jedes Szenario unten von einem Rätsel in eine Diagnose.
Warum du feststeckst (und warum es nie zufällig ist)
Jedes Szenario hat eine von drei Wurzeln. Entweder deine Umgebung ist auseinandergedriftet (die Datenbank ist nicht mit dem Code synchron, eine Einstellung fehlt, ein Cache ist veraltet), dein Code hat einen konkreten Defekt (ein Tippfehler, eine fehlende Prüfung, ein falscher Import), oder deine Daten sind nicht so, wie du denkst (herausgefiltert, im falschen Konto, als inaktiv markiert). KI-generierter Code bringt eine Wendung mit: Der Code funktioniert oft – es sind die Annahmen drumherum, die brechen.
Deshalb funktioniert „versuch es nochmal" selten, und systematisch schlägt hektisch. Symptom zuordnen, Wurzel prüfen, Lösung anwenden.
Häufige Probleme beim Bauen mit KI: die 10 größten, entschlüsselt
| Was du siehst | Was tatsächlich passiert | Die Lösung |
|---|---|---|
| 400 Bad Request, „column does not exist" | Der Code erwartet eine Datenbankspalte, die nie angelegt wurde – Code und Datenbank sind nicht synchron | Wende deine ausstehenden Datenbankmigrationen an, dann prüfe die Tabelle in deinem Supabase-Dashboard, ob die Spalte existiert |
| Daten existieren, werden aber nicht angezeigt | Die Daten werden herausgefiltert: Inaktiv-Flag, Entwurfsstatus oder sie gehören zu einem anderen Konto | Prüfe die Zeile in deinem Datenbank-Dashboard – schau auf Flags wie is_active und das Konto, zu dem sie gehört |
| 401 Unauthorized | Deine Sitzung ist abgelaufen oder du wurdest abgemeldet | Abmelden, wieder anmelden; falls es bleibt, lösche die Websitedaten in deinem Browser und melde dich neu an |
| 403 Forbidden oder 406 Not Acceptable | Du bist angemeldet, aber die Sicherheitsregeln der Datenbank (RLS) blockieren die Operation | Prüfe deine Benutzerrolle und die Sicherheitsrichtlinien dieser Tabelle im Supabase-Dashboard |
| Duplicate key violation | Du legst etwas mit einem Namen oder einer Adresse an, die schon existiert – diese müssen eindeutig sein | Nutze einen anderen Wert oder aktualisiere den bestehenden Datensatz, statt einen neuen anzulegen |
| Cannot read property of undefined | Der Code läuft, bevor die Daten aus der Datenbank eintreffen | Bitte die KI, vor der Nutzung der Daten eine Ladeprüfung einzubauen |
| Module not found | Ein Tippfehler im Importpfad, eine Datei, die nicht existiert, oder ein Paket, das nie installiert wurde | Prüfe Schreibweise und Groß-/Kleinschreibung des Pfads exakt; führe den Installationsbefehl aus; starte den Dev-Server neu |
| Build failed beim Deploy | Lokal ignorierte Typfehler oder fehlende Einstellungen (Umgebungsvariablen) auf der Hosting-Plattform | Führe den Build zuerst auf deinem Rechner aus, um den echten Fehler zu sehen; kopiere jede Umgebungsvariable ins Hosting-Dashboard |
| Deployt, aber die Seite zeigt die alte Version | Dein Browser oder das CDN liefert eine zwischengespeicherte Kopie der alten Seite aus | Hartes Neuladen (Cmd + Shift + R); in einem privaten Fenster testen; mit geleertem Cache neu deployen |
| Code geändert, nichts passiert | Der Dev-Server läuft nicht, die Datei wurde nicht gespeichert oder du hast die falsche Datei bearbeitet | Prüfe, ob das Terminal den Server ausführt, speichere die Datei, lade hart neu – dann vergewissere dich, dass du die Datei bearbeitet hast, auf die der Fehler tatsächlich zeigt |
Drei Probleme, die in Wahrheit ein Problem sind
Schau dir die Zeilen zwei, drei und vier noch einmal an. „Daten werden nicht angezeigt", „401" und „403" fühlen sich wie drei verschiedene Katastrophen an, gehören aber zu einer Familie: Identität und Berechtigungen. Die Datenbank stellt immer dieselben drei Fragen – wer bist du, zu welchem Konto gehörst du, und darfst du das tun? Ist eine Antwort falsch, bekommst du eines dieser drei Symptome.
Debugge sie also in dieser Reihenfolge. Erstens: Bin ich überhaupt angemeldet? Zweitens: Liegen diese Daten in meinem Konto, oder habe ich sie unter einer anderen E-Mail-Adresse angelegt? Drittens: Erlaubt die Sicherheitsrichtlinie dieser Tabelle meiner Rolle, das zu tun? In neun von zehn Fällen kommst du nie zur dritten Frage.
Funktioniert auf deinem Rechner, bricht in Produktion
Das demoralisierendste Szenario verdient einen eigenen Abschnitt: Lokal läuft alles, du deployst, und die Live-Seite ist kaputt. Nichts ist „schiefgegangen" – lokal und Produktion sind einfach verschiedene Umgebungen. Andere Einstellungen, andere Datenbank, anderer Build-Modus. Die Checkliste:
- Zuerst die Umgebungsvariablen. Jede Einstellung, die dein Code liest, muss im Dashboard der Hosting-Plattform existieren, nicht nur auf deinem Rechner. Das ist öfter die Ursache als alles andere zusammen.
- Prüfe, auf welche Datenbank du zeigst. Deine Live-App muss die Adresse deiner Produktionsdatenbank nutzen, nicht die einer Entwicklungsdatenbank.
- Lies die Deployment-Logs. Deine Hosting-Plattform protokolliert Fehler, die auf deinem Rechner nie auftauchen.
- Baue lokal wie in Produktion. Führe den Produktions-Build-Befehl auf deinem Rechner aus – scheitert er dort, hast du deinen Bug gefunden, ohne einen weiteren Deploy-Zyklus.
Der Prompt, der dich wieder in Gang bringt
Wenn die Tabelle es nicht klärt, übergib das Problem richtig an die KI. Vage Bitten erzeugen vage Vermutungen – und eine ratende KI kann es schlimmer machen, wie ich in wie KI deine Codebasis sabotiert gezeigt habe. Der Prompt, der dich wieder in Gang bringt, hat vier Teile:
Ich stecke fest bei [was du versucht hast]. Was ich erwartet habe: [erwartetes Ergebnis]. Was tatsächlich passiert: [genaues Symptom]. Vollständige Fehlermeldung: [einfügen, mit Datei und Zeile]. Was ich schon versucht habe: [deine Liste]. Diagnostiziere die wahrscheinlichste Ursache, bevor du eine Lösung vorschlägst.
Dieser letzte Satz ist wichtig. Die Diagnose zuerst zu erzwingen hindert die KI daran, zufällige Korrekturen auf deine Codebasis abzufeuern – das Debugging-Äquivalent eines Arztes, der verschreibt, bevor er untersucht. Und eine Gewohnheit verhindert, dass dir die Hälfte dieses Artikels je passiert: Committe funktionierenden Code vor jedem Experiment, damit „es lief alles, und jetzt ist es kaputt" immer einen Ausweg mit einem einzigen Befehl hat.
Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →Häufig gestellte Fragen
Was sollte ich zuerst tun, wenn ich feststecke?
Öffne die Browser-Konsole und lies den tatsächlichen Fehler – so liest du jeden Fehler in 30 Sekunden. Dann sieh im Terminal nach, in dem dein Dev-Server läuft. Zwischen diesen beiden Orten steht die wahre Ursache fast immer schon für dich da; die Fähigkeit besteht darin, hinzusehen, bevor man rät.
Gestern lief alles und ich habe nichts geändert. Was ist passiert?
Etwas hat sich geändert – du hast es nur nicht bemerkt. Die üblichen Verdächtigen: Du hast neuen Code gezogen, ohne Abhängigkeiten oder Datenbank zu aktualisieren, ein Merge ist schiefgegangen oder eine Datei wurde versehentlich zurückgesetzt. Frag deine Versionsverwaltung, was sich seit dem letzten funktionierenden Zustand geändert hat, und stelle von dort wieder her. Deshalb ist häufiges Committen von funktionierendem Code die billigste Versicherung in der Softwareentwicklung.
Wann sollte ich aufhören zu debuggen und die KI um Hilfe bitten?
Nach einem systematischen Durchgang: Konsole gelesen, Symptom mit den häufigen Szenarien abgeglichen, eine Lösung versucht. Löst das das Problem nicht, füge den vollständigen Kontext ein – Fehler, Erwartung, was du versucht hast – mit dem Prompt oben. Zwanzig Minuten sturen Alleinratens sind weniger wert als zwei Minuten gut vorbereiteten Fragens.
Sind diese Probleme ein Zeichen, dass ich nicht ohne Entwickler bauen sollte?
Nein – jeder Entwickler der Welt erlebt genau diese Szenarien; sie haben sie nur oft genug gesehen, um die Muster zu erkennen. Dieses Erkennen ist in Wochen lernbar, nicht in Jahren. Die zehn Zeilen oben sind der Großteil dessen, was „jahrelange Erfahrung" beim täglichen Debugging bedeutet.
Wie gefangen bist du wirklich?
Mach den Corporate Suffocation Index – die kostenlose Einschätzung, ob du bereit bist, Solopreneur zu werden.