Was tatsächlich in einer mit KI gebauten App steckt: eine Tour für Nicht-Entwickler:innen
Wenn du etwas mit einem KI-App-Builder ausgeliefert hast und verstehen willst, was du da vor dir siehst, hier ist eine freundliche geführte Tour durch die Teile — ohne Fachjargon.
Du hast eine Beschreibung getippt, auf Los geklickt, und zwanzig Minuten später hattest du eine funktionierende App. Großartig. Aber jetzt hast du auf “Dateien anzeigen” geklickt und starrst auf einen Ordnerbaum, der aussieht, als wäre er in einer anderen Sprache geschrieben. Was ist package.json? Warum sind da vierzig Dinge in node_modules? Was heißt “Schema”, und warum hast du eins?
Dieser Beitrag ist eine geführte Tour. Kein Tutorial — eine Tour. Nach dem Lesen wirst du nicht wissen, wie man eine dieser Dateien selbst schreibt, aber das nächste Mal, wenn etwas seltsam aussieht, wirst du wissen, auf welche Ecke der App du zeigen musst.
Ich werde durchgehend drei laufende Beispiele verwenden, damit die abstrakten Teile etwas Konkretes haben, an dem sie sich festmachen:
- Maya, eine Marketing-Leiterin, die ein Empfehlungs-Leaderboard für ihr Team gebaut hat.
- Jordan, ein Yogalehrer, der eine Kursbuchungs-Seite gebaut hat.
- Sam, der eine Bäckerei betreibt und eine “Bestell die Croissants von morgen vor”-Seite gebaut hat.
Alle drei haben einen KI-App-Builder genutzt. Alle drei Apps sehen für eine:n Kund:in völlig unterschiedlich aus. Unter der Haube sind sie erstaunlich ähnlich geformt.
Das Frontend: was deine Kund:innen tatsächlich sehen
Das Frontend ist alles, was im Browser von jemandem lädt. Buttons, Layouts, Schriften, Animationen, die Art, wie sich ein Formular nach dem Absenden selbst leert. Wenn du es sehen kannst, ist es Frontend.
Bei Maya ist das Frontend ein Leaderboard mit Rang, Name und Anzahl der Empfehlungen. Bei Jordan ist es ein Kalender mit Kursen und einem “Buchen”-Button. Bei Sam ist es eine Liste von Backwaren mit kleinen Plus-und-Minus-Buttons neben jeder.
Innerhalb des Projekts lebt das Frontend meist in einem Ordner, der ungefähr app/, pages/ oder src/ heißt. Du wirst Dateien sehen, die auf .tsx oder .jsx enden. Jede ist grob “ein Screen” oder “ein Teil eines Screens”. Die Leaderboard-Zeile ist eine Datei. Der Header ist eine andere Datei. Die Seite, die alles zusammenbindet, ist eine dritte.
Wenn du den KI-Builder bittest, “die Buttons runder zu machen” oder “das Leaderboard nach rechts zu verschieben”, ist das der Teil, der sich ändert.
Das Backend: der Teil, der denkt
Das Backend ist der Teil, den niemand sieht, aber von dem alle abhängen. Es ist der Code, der woanders läuft — auf einem Server, nicht im Browser der Kund:innen —, wenn etwas passieren muss, dem man nicht zutrauen sollte, dass der Browser der Kund:innen es allein erledigt.
Warum kann der Browser nicht alles machen? Weil der Browser die Maschine der Kund:innen ist, und ihr kannst du nicht trauen. Wenn Mayas Leaderboard die Empfehlungszahlen rein im Browser aktualisieren würde, könnte jede:r rechtsklicken und sich 9.000 Empfehlungen hinzufügen. Also ist das Backend da, wo die Regeln leben: “diese Person darf das, aber nicht jenes”, “speichere das tatsächlich in der Datenbank”, “verschick diese E-Mail”.
Das Backend lebt meist in einem Ordner, der api/, server/ oder app/api/ heißt. Die Dateien dort sind meist kurz. Jede behandelt eine bestimmte Anfrage: “erstelle eine Buchung”, “liste die Croissants von heute auf”, “füge eine Empfehlung hinzu”.
Wenn etwas in deiner App funktioniert, aber das Ergebnis nicht hält — du klickst Absenden, siehst eine Bestätigung, aber morgen sind die Daten weg —, ist das Backend fast immer da, wo der Bug ist.
Die Datenbank: das Gedächtnis deiner App
Stell dir das Gedächtnis deiner App als eine Reihe Aktenschränke vor. Jeder Schrank hat ein Etikett vorn. Einer sagt “users”. Einer sagt “bookings”. Einer sagt “croissant_orders”. In jedem Schrank ist jede Schublade eine Zeile. Jede Schublade hat denselben Satz Fächer: einen Namen, eine E-Mail, ein created_at, einen Status.
Diese Struktur — “welche Schränke existieren, welche Fächer jede Zeile hat” — heißt Schema. Es ist die wichtigste Datei im Projekt, auch wenn es wahrscheinlich auch die langweiligst aussehende ist. Find eine Datei namens schema.ts, schema.prisma oder etwas in einem Ordner namens db/ oder migrations/. Öffne sie. Du wirst eine Liste sehen, die widerspiegelt, was deine App tatsächlich über die Welt behält.
Jordans Schema hat eine classes-Tabelle, eine bookings-Tabelle und eine users-Tabelle. Sams hat products, orders und order_items. Mayas hat members und referrals. Die Form des Schemas ist die Form des Produkts, weshalb es später schwerer zu ändern ist als das Aussehen der Buttons.
Ein nützlicher Trick: Wenn du in einfachen Worten beschreiben kannst, was deine App behält, kannst du meist das Schema beschreiben. “Ich behalte den Namen und die E-Mail jeder Kundin. Für jede Kundin behalte ich die Bestellungen, die sie aufgegeben hat. Für jede Bestellung behalte ich, welche Backwaren und wie viele von jeder.” Dieser Satz ist, fast Wort für Wort, das Schema.
Auth: der Türsteher am Eingang
“Auth” sind zwei zusammengequetschte Wörter: Authentifizierung (wer bist du?) und Autorisierung (was darfst du tun?). Beide werden meist von einem kleinen Satz Dateien in einem Ordner namens auth/ gehandhabt oder von einem Dienst, dessen Name dir vielleicht bekannt vorkommt: Clerk, Auth0, Supabase Auth, NextAuth.
Die zwei Fragen sind verschieden. Authentifizierung beantwortet: “ist das wirklich Maya?” — meist mit einem Passwort, einem Google-Login oder einem Magic Link, der ihr per E-Mail geschickt wird. Autorisierung beantwortet: “darf Maya die Empfehlungen anderer Leute löschen?” — und die ehrliche Antwort für die meisten mit KI gebauten Apps in ihrer ersten Woche ist “wir haben vergessen, das zu prüfen”.
Das ist der Teil, der am häufigsten still kaputt ist. Der Login-Screen funktioniert, also fühlt es sich sicher an. Aber das Backend prüft nicht immer, ob die eingeloggte Person dieselbe Person ist, deren Daten sie zu lesen versucht. Wenn deine App irgendein Konzept von “meine Daten vs. deine Daten” hat, frag den KI-Builder ausdrücklich: “Stell sicher, dass Nutzer:innen nur ihre eigenen Daten sehen und bearbeiten können.” Du wirst überrascht sein, wie oft dieser eine Satz eine fehlende Prüfung aufdeckt.
Integrationen: die Dinge, die du nicht gebaut hast, aber trotzdem nutzt
Hier unterschätzen die meisten Nicht-Entwickler:innen, was tatsächlich passiert. Das Ding, das Sams “deine Croissants sind fertig”-E-Mail verschickt, ist kein Code — es ist ein Konto bei SendGrid oder Resend. Das Ding, das Jordans Kurszahlung verarbeitet, ist kein Code — es ist Stripe. Das Ding, das die Fotos auf Mayas Leaderboard hostet, ist kein Code — es ist ein Speicherdienst wie S3 oder Cloudinary.
Jede Integration taucht an zwei Stellen auf. Da ist ein kleines Stück Code im Backend, das sagt “hey, Stripe, belaste diese Karte”. Und da ist ein Schlüssel — eine lange geheime Zeichenkette —, irgendwo sicher gespeichert (meist eine Datei namens .env, die niemand jemals committen sollte), der Stripe beweist, dass die Anfrage von Sams Bäckerei kam und nicht von einer fremden Person.
Wenn du dich je fragst, warum deine App plötzlich aufhört, E-Mails zu verschicken, oder aufhört, Zahlungen anzunehmen, ist die Ursache fast immer eine von: ein abgelaufener Schlüssel, ein erreichtes Nutzungslimit oder eine Änderung der Richtlinien der Integration. Der Code ist nicht kaputtgegangen. Der Handschlag ist es.
Das Deploy: wie es ins Internet kommt
Das letzte Teil ist der Teil, der den Ordner auf deiner Festplatte in ein Ding verwandelt, das deine Kund:innen unter einer URL besuchen können. Das bedeutet meist drei kleine Dinge, die zusammenarbeiten:
- Der Host: ein Dienst wie Vercel, Netlify, Fly oder Render, der dein Backend laufen lässt und dein Frontend ausliefert.
- Die Domain: ein Name wie
mayas-leaderboard.com, der auf deinen Host zeigt. - Der Build: das Rezept, das deine chaotischen Quelldateien nimmt und in die schlankere, schnellere Version verwandelt, die tatsächlich läuft.
Wenn etwas lokal funktioniert, aber in der Produktion kaputtgeht, liegt das Problem meist hier. Ein Schlüssel, der auf deinem Laptop gesetzt ist, aber nicht auf dem Host. Eine Bibliothek, die in der Entwicklung installiert ist, aber nicht in der Produktion. Eine Datenbank, die in deinem Browser existiert, aber nicht auf der Live-Seite.
Die Fünf-Minuten-Gewohnheit, die sich selbst bezahlt
Du musst nicht jede Datei in deinem Projekt lesen. Du musst nicht wissen, was die meisten von ihnen tun. Aber du solltest einmal pro Woche einen Fünf-Minuten-Rundgang machen, bei dem du jeden der obigen Ordner öffnest und den KI-Builder in einfachen Worten fragst, was sich geändert hat.
Maya macht das jeden Freitagnachmittag. Sie tippt: “Was hat sich diese Woche im Schema geändert, und warum?” Und: “Gibt es neue Integrationen in dieser App, um die ich nicht gebeten habe?” Die Antworten sind fast immer beruhigend. Die wenigen Male, in denen sie es nicht sind, fängt sie Probleme ab, solange sie noch klein sind.
Das ist der ganze Sinn, die Teile zu verstehen. Nicht, um Entwicklerin zu werden. Nur, um bessere Fragen stellen zu können.
Wo es als Nächstes weitergeht
Wenn diese Tour geholfen hat, sind zwei Anschlussbeiträge deine Zeit wert. Der “sieht in Ordnung aus”-Bug behandelt, was zu tun ist, wenn eines dieser Teile still kaputt ist, und demo-bereit vs. produktionsbereit behandelt, wie du erkennst, wann deine App von der ersten Stufe zur zweiten gewechselt ist. Dieselbe Karte, unterschiedliche Verwendungen dafür.