Warum dein KI-App-Builder dir zuerst falsche Daten zeigt (und warum das richtig ist)
Wenn dein KI-App-Builder deine Screens mit erfundenen Nutzer:innen und Beispielbestellungen füllt, bevor er die Datenbank überhaupt anfasst, ist das keine Abkürzung — es ist die richtige Art zu bauen. Hier erfährst du, warum.
Du beschreibst deinem KI-App-Builder eine App. Eine Minute später blickst du auf eine funktionierende Oberfläche — Seiten, Buttons, eine Tabelle mit Nutzer:innen, die “Alex Rivera” und “Priya Shah” heißen, Preise, die keinen Sinn ergeben, einen “Pro-Tarif”, nach dem du nicht gefragt hast. Nichts ist gespeichert. Wenn du aktualisierst, sind die Daten immer noch da. Wenn du eine:n neue:n Nutzer:in hinzufügst, verschwindet sie wieder.
Es sieht aus wie ein Zaubertrick, der gleich auseinanderfällt. Ist er nicht. Das ist der gute Teil des Builds. Die Mock-Daten auf deinem Bildschirm sind ein bewusster erster Schritt, und sie sind der Grund, warum die Datenbank, die als Nächstes kommt, tatsächlich zu der App passt, die du wolltest.
Was “falsche Daten zuerst” wirklich bedeutet
Wenn ein KI-App-Builder dein Briefing entgegennimmt, geht er nicht direkt zur Datenbank. Ein guter schreibt zuerst die Screens, füllt sie mit plausiblen Platzhalterdaten und entwirft dann — und erst dann — die Datenbank passend dazu.
Die Platzhalterdaten sind keine Dekoration. Sie sind ein Vertrag. Sobald deine App sagt “jede Bestellung hat einen Kundennamen, drei Posten, eine Summe und einen Status”, muss die Datenbank, die als Nächstes gebaut wird, genau diese Dinge haben, in genau diesen Formen. Die Screens entscheiden, wie die Daten aussehen, nicht umgekehrt.
Das ist verkehrt herum im Vergleich dazu, wie ein:e menschliche:r Entwickler:in normalerweise anfangen würde. Ein:e traditionelle:r Entwickler:in entwirft zuerst die Datenbank und baut dann die Screens dagegen. KI-Builder haben das umgedreht, und die meisten Menschen merken es nicht — sie sehen nur die falschen Nutzer:innen und nehmen an, der Builder mogelt.
Warum diese Reihenfolge mit KI besser funktioniert
Wir haben versucht, die Datenbank und die Screens gleichzeitig zu bauen. Es hat nicht funktioniert. Hier ist die Kurzfassung, warum.
Wenn zwei KI-Agenten an verschiedenen Teilen einer App arbeiten, ohne die Ergebnisse des jeweils anderen zu sehen, treffen sie unvereinbare Annahmen. Der Interface-Agent entscheidet, dass Nutzer:innen ein Feld “name” haben. Der Datenbank-Agent entscheidet, dass Nutzer:innen ein Feld “fullName” haben. Beide sehen korrekt aus. Zusammen funktioniert nichts. Ein dritter Agent wird hinzugezogen, um die Diskrepanz zu flicken. Auch er rät. Jetzt sind drei Annahmen unterwegs, und die App, die du in der Vorschau siehst, ist irgendein Frankenstein aus allen dreien.
Die Lösung ist fast peinlich: Mach erst das eine, dann das andere. Das Interface wird gebaut. Es schreibt auf, welche Daten es braucht, als eine einzige Datei mit falschen Nutzer:innen, falschen Bestellungen, falschem Was-auch-immer-deine-App-betrifft. Der Datenbank-Agent liest diese Datei und passt sie Feld für Feld an. Keine Annahmen. Keine Verhandlung. Keine Diskrepanz.
Deshalb kann dir dein KI-App-Builder in einer Minute eine fertig aussehende App zeigen. Er hat den Build nicht vorgetäuscht. Er hat ein Viertel des Builds erledigt — den Teil, der alles andere entscheidet — und die Datenbank sind die nächsten zehn Sekunden Arbeit, nicht die nächsten zehn Stunden.
Worauf du achten solltest, wenn die falschen Daten auf dem Bildschirm sind
Das ist der Moment, den die meisten Menschen überspringen. Sie sehen die Platzhalterdaten und fangen an, nach Farbänderungen zu fragen. Aber die Platzhalterdaten sind eine Frage, die dir gestellt wird. Lies sie.
Ein paar Beispiele, worauf du achten solltest:
- Falsches Vokabular. Die App, die du wolltest, verfolgt “Sendungen”. Die Platzhalterdaten nennen sie “Bestellungen”. Sag es dem Builder. Wenn du es jetzt durchgehen lässt, wird jeder Screen, jedes Datenbankfeld, jeder Report das falsche Wort verwenden — und später umzubenennen ist in keinem Tool eine Ein-Klick-Operation, egal was das Marketing behauptet.
- Fehlende Felder. Die falsche Rechnung hat eine Summe und ein Datum. Du brauchst außerdem eine Bestellnummer. Besser jetzt hinzufügen, wenn fünf Mock-Rechnungen auf einem Screen sind, als nachdem die Datenbank gebaut und mit echten Kundendaten befüllt ist.
- Falsche Formen. Die Mock-Daten zeigen “1 Kunde, 1 Adresse”. Deine tatsächlichen Kund:innen haben mehrere Adressen. Der Builder kann das nicht aus deinem Briefing ableiten. Sag es ihm jetzt, solange das Ändern der Form nichts kostet.
- Überraschende Entitäten. Der Builder hat ein “Team”-Konzept erfunden, nach dem du nicht gefragt hast, weil er von einer Multi-User-App ausging. Vielleicht wolltest du das. Vielleicht nicht. So oder so: Entscheide, bevor die Datenbank darum herum gebaut wird.
Eine nützliche Regel: Wenn deine App ein Substantiv enthält, das nicht in den Platzhalterdaten auf dem Bildschirm vertreten ist, weiß der Builder noch nichts davon. Erwähne es, bevor du in der ersten Vorschau auf “speichern” klickst.
Warum die Reihenfolge für das zählt, was als Nächstes kommt
Sobald die Platzhalterdaten stimmen, ist der Datenbank-Build mechanisch. Der Builder liest deine falschen Daten, generiert ein Schema, das dazu passt, schreibt die Abfragen, die die Screens ohnehin schon aufrufen wollen, und tauscht schließlich die Platzhalter-Importe gegen echte aus. Dieselben Screens, die falsche Nutzer:innen zeigten, zeigen nun das, was du tatsächlich eingibst.
Du kannst den Tausch meist in Echtzeit beobachten. Eine Seite, die sofort lud, weil sie eine lokale Datei las, hat jetzt einen halbsekündigen Ladezustand — das ist der Screen, der zum ersten Mal mit einer echten Datenbank spricht. Die meisten Menschen verpassen das und merken nicht, dass die App gerade die Grenze von “Demo” zu “Ding, das echte Daten speichern kann” überschritten hat.
Der Grund, warum das überhaupt funktioniert, ist, dass alles Nachgelagerte — das Datenbankdesign, die Abfragen, die Ladezustände, die Leerzustände — von dem entschieden wurde, was du während der Platzhalter-Phase auf dem Bildschirm gesehen hast. Wenn du drei Spalten abgesegnet hast, bekommst du drei Spalten. Wenn du ein “Status”-Feld mit den Werten “Entwurf” und “gesendet” abgesegnet hast, ist das genau das, was die Datenbank akzeptiert. Es gibt keinen zweiten Übersetzungsschritt, bei dem eine Designer-Entwickler-Übergabe die Dinge verstümmelt.
Ein kleiner Test, den du machen kannst
Wenn du das nächste Mal etwas baust, probier das: Wenn die Platzhalterdaten auftauchen, ändere eine Sache daran, bevor du nach irgendetwas anderem fragst. Benenne ein Feld um. Füge eine Spalte hinzu. Ersetze “users” durch “members”. Dann beobachte, was passiert, wenn die Datenbank gebaut wird.
Du wirst die Änderung überall auftauchen sehen — im Datenbankdesign, in den Abfragen, in den Seed-Daten, die der Builder einsetzt, wenn die App fertig ist. Ein Wort in der Platzhalter-Phase hat sich durch die ganze App fortgepflanzt. Das ist der Hebel, den du in dieser Phase hast, und es ist der Grund, warum “falsche Daten zuerst” kein Abkürzungstrick ist. Es ist der Moment, in dem die App wirklich entschieden wird.
Wenn du tiefer eintauchen willst: Unser letzter Beitrag darüber, was tatsächlich in einer KI-gebauten App steckt, führt durch die anderen beweglichen Teile, die du auf den ersten Blick nicht siehst. Das Muster ist dasselbe: Der meiste Hebel steckt in den Teilen, die so aussehen, als spielten sie keine Rolle.