Ich baue seit über einem Jahr täglich mit KI-Coding-Tools. Claude Code, Cursor, Lovable — je nach Aufgabe. Und es gibt ein Muster, das ich in jedem einzelnen Projekt sehe, bei jeder neuen Datenbankverbindung.

Die KI schreibt Code, der funktioniert. Der Test ist grün. Das Interface sieht genau so aus, wie man es beschrieben hat. Aber wenn man sich anschaut, was die App im Hintergrund tatsächlich tut — was sie an Daten lädt, welche Anfragen sie an die Datenbank schickt, welche Informationen im Browser ankommen — dann sieht das Bild anders aus.

Irgendwann wollte ich wissen, ob das wirklich jedes Mal passiert. Oder ob ich einfach Pech habe.

Also habe ich zehn KI-Tools denselben Auftrag gegeben: Bau mir ein Projektmanagement-Tool. Teams, Aufgaben, Workspaces. Jeder Nutzer sieht nur die Aufgaben seines Teams.

Jede App sah gut aus. Jede hat funktioniert.

Bei 9 von 10 hat die App alle Daten aller Teams geladen. Das Interface zeigt nur deine — aber im Hintergrund ist alles da. Jeder mit ein bisschen technischem Wissen kann es auslesen.

Stellen wir uns vor, ein Team baut mit KI-Tools ein internes Projektmanagement-Tool. Drei Abteilungen nutzen es, jede mit eigenen Projekten, eigenen Aufgaben, teilweise sensiblen Daten — Budgets, Kundennamen, strategische Initiativen.

Das Tool funktioniert. Jede Abteilung sieht ihre Aufgaben. Alles scheint in Ordnung.

Aber im Hintergrund passiert etwas anderes: Wenn Abteilung A ihr Dashboard öffnet, lädt die App nicht nur die 12 Aufgaben von Abteilung A. Sie lädt alle Aufgaben. Von allen Abteilungen. 4.000 Datensätze. Das Frontend filtert danach — zeigt nur die relevanten. Aber die Daten der anderen Abteilungen waren da. Im Netzwerk, im Speicher, im Browser.

Das hat zwei Konsequenzen:

Es ist ein Sicherheitsproblem. Daten von Abteilung B landen auf dem Gerät von Nutzer A. Kein sichtbarer Fehler, keine Fehlermeldung. Einfach Daten, die nie hätten ankommen dürfen. In einem Multi-Tenant-System — also überall wo es Workspaces, Teams oder Nutzerbereiche gibt — ist das ein Datenleck. Nicht theoretisch, sondern real.

Es ist ein Performance-Problem. Bei 50 Testnutzern fällt das nicht auf. Bei 500 wird die App langsamer. Bei 5.000 geht sie in die Knie. Der Gründer sucht den Fehler im Hosting, im Frontend, im Design. Nutzer beschweren sich, springen ab. Aber der Fehler sitzt nicht dort — er sitzt ganz am Anfang, in der Art wie die App Daten aus der Datenbank holt.

Die KI macht keinen Fehler. Sie folgt ihrer Logik.

Wenn du einer KI sagst „Bau mir ein Dashboard mit den Aufgaben meines Teams", dann baut sie ein Dashboard, das Aufgaben zeigt. Fertig. Sieht gut aus. Test bestanden.

Was die KI dabei nicht tut: Sie fragt nicht „Welcher Nutzer ist gerade eingeloggt? Zu welchem Team gehört er? Was darf er sehen?" Sie holt, was da ist, und filtert danach.

Das ist kein Versagen — es ist der kürzeste Weg zur funktionierenden Lösung. Und „kürzester Weg" ist genau das, worauf Sprachmodelle optimiert sind. „Alles laden" funktioniert immer. „Nur das Richtige laden" erfordert Kontext über das Projekt, über Berechtigungen, über die Datenbankstruktur — Kontext, den die KI schlicht nicht hat.

In der Datenbanksprache heißt dieses Muster SELECT * FROM — gib mir alles aus dieser Tabelle. Es ist das Erste, was man in jedem Datenbank-Kurs lernt. Und das Erste, was man in der Praxis durch gezielte Abfragen ersetzt. KI-Tools machen diesen zweiten Schritt nicht.

Eine Studie über ein Hotel macht den Mechanismus anschaulich: Du bekommst den Schlüssel für Zimmer 302. Aber an der Rezeption lagen kurz alle Schlüssel offen auf dem Tisch. Du hast nur deinen genommen — aber die anderen lagen da. Das ist kein eingebrochenes Schloss. Es ist ein Prozess, der die Filterung am falschen Ort macht.

Seit April 2026 gibt es Claude Design. In einer Stunde vom UI-Entwurf zur fertigen App. Mockup beschreiben, von Claude in ein interaktives Prototype verwandeln lassen, direkt an Claude Code zur Implementierung übergeben.

Was dabei verloren geht: Niemand fragt, welche Daten jede einzelne Ansicht tatsächlich braucht. Das Design zeigt „Meine Projekte" — und die KI baut genau das. Visuell korrekt. Funktional unvollständig. Die Geschwindigkeit, mit der heute aus einer Idee eine funktionierende App wird, überspringt genau den Schritt, der über Datensicherheit und Skalierbarkeit entscheidet.

Das betrifft nicht nur Hobby-Projekte. Jeder Workspace, jedes Dashboard, jedes Tool mit Nutzerbereichen hat dieses Problem — wenn niemand explizit prüft, was im Hintergrund geladen wird.

Meine Beobachtung aus der täglichen Arbeit deckt sich mit der Forschung:

Eine Studie von CodeRabbit über 470 reale Pull Requests (Dezember 2025) hat gemessen: Performance-Ineffizienzen — also genau das Muster, das ich beschreibe — treten in KI-generiertem Code achtmal häufiger auf als in menschlich geschriebenem Code. Nicht doppelt so oft. Achtmal.

Eine akademische Studie über 304.000 KI-generierte Code-Commits (Liu et al., „Debt Behind the AI Boom", März 2026) zeigt: Fast jedes vierte Problem, das KI in den Code einführt, existiert Monate später noch. Niemand hat es bemerkt, niemand hat es behoben. Die Studie dokumentiert über 110.000 ungelöste Issues, die sich von Anfang 2025 bis Anfang 2026 angesammelt haben.

Und eine Untersuchung von kluster.ai zu Cursors Auto-Modus (November 2025) fand: 48 Prozent des generierten Codes enthielt Probleme, die eine Korrektur erforderten — darunter Fälle, in denen das Modell Methoden entfernt hat, aber vergessen hat, den Code zu aktualisieren, der diese Methoden aufruft. Feldnamen und Funktionen, die im Code stehen aber im echten System nicht existieren. Silent Fails — keine Fehlermeldung, einfach falsche oder leere Daten.

Ich habe kein Patentrezept. Aber ich habe drei Fragen, die ich heute in jeder KI-Session stelle, bevor ich einen Push akzeptiere:

Lädt die App nur die Daten, die der Nutzer sehen darf? Nicht: Zeigt sie nur die richtigen Daten? Sondern: Kommen überhaupt nur die richtigen an? Der Unterschied ist entscheidend — das eine ist ein UI-Filter, das andere ist Datensicherheit.

Passiert die Filterung in der Datenbank — oder erst danach? Wenn die App erst alle Daten holt und dann aussortiert, ist das kein Feature, das man optimiert. Das ist ein Architektur-Fehler, der mit jedem Nutzer teurer wird.

Teste ich gegen echte Daten — oder gegen Testdaten, die genauso erfunden sind wie der Code? KI generiert nicht nur Code. Sie generiert auch Testdaten, Mock-Datenbanken, simulierte API-Antworten. Wenn die Testdaten die gleichen Lücken haben wie der Code — und das haben sie fast immer — dann testet man das Problem mit dem Problem.

Die KI macht keinen Fehler. Sie folgt ihrer Logik: Der kürzeste Weg zur funktionierenden Lösung gewinnt. „Alles laden" funktioniert immer. „Nur das Richtige laden" erfordert Kontext, den die KI nicht hat.

Diesen Kontext müssen wir liefern. Nicht weil die Technologie schlecht ist — sondern weil sie gut genug ist, um uns zu überzeugen, dass alles in Ordnung ist. Das Interface sieht richtig aus. Die Tests sind grün. Der Deploy ist erfolgreich.

Ob die App tatsächlich nur zeigt, was sie zeigen darf — das prüft niemand automatisch. Das müssen wir tun. Jedes Projekt. Jedes Mal.