Wie funktioniert Prompt-to-App? Eine verständliche Erklärung

Letzten Monat beschrieb eine Marketing-Managerin in einem 200-Personen-Unternehmen ein Urlaubsverwaltungssystem, das sie brauchte. Drei Stunden später nutzte ihr Team es bereits. Keine Entwickler. Keine IT-Tickets. Nur ein Gespräch mit einer KI -- und am Ende eine funktionierende Anwendung.

Das passiert inzwischen täglich tausendfach. Menschen, die noch nie programmiert haben, erstellen echte Software, indem sie beschreiben, was sie wollen. Trotzdem haben die meisten -- selbst regelmäßige Nutzer -- keine Ahnung, was tatsächlich zwischen dem Klick auf "Erstellen" und dem Erscheinen ihrer App passiert. Es fühlt sich weniger wie Magie an und mehr wie eine Black Box, von der man hofft, dass sie das Richtige tut.

Zu wissen, was unter der Haube passiert -- auch nur ungefähr -- ist nützlicher, als du vielleicht denkst. Du schreibst bessere Prompts, findest Fehler schneller und kannst unterscheiden, welche Plattformen tatsächlich funktionierende Software generieren und welche nur hübsche Mockups ausspucken, die beim ersten Nutzungsversuch auseinanderfallen.

Der 3-Schritte-Prozess: Beschreiben, Generieren, Bereitstellen

Der Workflow hat drei Schritte. Das ist kein Marketing-Slogan; es sind wirklich nur drei.

Schritt 1: Beschreib, was du willst

Sag der KI in normaler Sprache, was du bauen möchtest. Kein Pseudocode, keine technischen Spezifikationen -- einfach so, wie du es einem Kollegen beim Kaffee erklären würdest.

Zum Beispiel:

"Ich brauche ein System, in dem Mitarbeiter Urlaubsanträge einreichen können. Der Vorgesetzte soll den Antrag genehmigen oder ablehnen können. Die Personalabteilung braucht ein Dashboard mit allen Anträgen im gesamten Unternehmen."

Das ist ein vollständiger Prompt. Du hast Benutzerrollen (Mitarbeiter, Vorgesetzte, Personalabteilung), Aktionen (einreichen, genehmigen, ablehnen) und Ansichten (Dashboard) beschrieben -- alles, was die KI braucht, um loszulegen.

Mehr Detail führt oft zu besseren Ergebnissen, aber du musst nicht wissen, wie Datenbanken funktionieren oder was eine REST API ist. Du musst nur wissen, was die Anwendung tun soll.

Schritt 2: Die Anwendung generieren

Sobald du auf "Erstellen" klickst, legt die KI los -- und sie tut deutlich mehr, als man vermuten würde.

Innerhalb von Sekunden bis Minuten, je nach Komplexität:

Erstellt sie die Datenbankstruktur zur Speicherung deiner Daten
Baut die Benutzeroberfläche -- die Screens, die Menschen sehen und mit denen sie interagieren
Schreibt die Geschäftslogik -- die Regeln, die das Verhalten der App bestimmen
Richtet die Benutzerauthentifizierung ein -- Login, Rollen, Berechtigungen
Konfiguriert alles, damit es als vollständiges System zusammenarbeitet

Das Ergebnis ist kein Mockup und kein Prototyp, der gut aussieht, aber nicht funktioniert. Es ist eine echte, funktionierende Webanwendung mit tatsächlichem Code dahinter.

Schritt 3: Bereitstellen und nutzen

Sobald die KI deine Anwendung generiert hat, ist sie in der Regel sofort einsatzbereit. Kein Server-Setup. Keine Deployment-Pipelines. Kein Warten auf die IT.

Viele Plattformen (einschließlich Chattee) übernehmen das Hosting automatisch. Du bekommst eine URL, teilst sie mit deinem Team, und die Leute können sofort loslegen. Einige Plattformen erlauben sogar die Einrichtung eigener Domains, damit die App aussieht, als gehöre sie zu deinem Unternehmen.

Vom Eintippen einer Beschreibung bis zur fertigen App kann es buchstäblich Minuten dauern.

Was hinter den Kulissen passiert

In den wenigen Sekunden zwischen dem Klick auf "Erstellen" und dem Erscheinen deiner Anwendung passiert eine Menge. Hier ist der grobe Ablauf.

Deine Anforderungen interpretieren

Deine Beschreibung wird auf Struktur analysiert. Die KI liest deinen Prompt im Grunde so, wie es ein erfahrener Entwickler tun würde -- und pickt die wichtigen Teile heraus:

Substantive werden typischerweise zu Datenobjekten. "Mitarbeiter", "Anträge", "Vorgesetzte" -- daraus werden Dinge, die das System speichern und verfolgen muss. Verben werden zu Aktionen: einreichen, genehmigen, ablehnen. Wenn du erwähnst, dass "Mitarbeiter Vorgesetzte haben" oder "Anträge zu Mitarbeitern gehören", werden daraus Beziehungen in der Datenbank.

Das geht über einfachen Keyword-Abgleich hinaus. Wenn du schreibst "Vorgesetzte sollen Anträge ihres Teams genehmigen", erkennt das System eine Hierarchie: "ihres Teams" bedeutet Mitarbeiter, die diesem bestimmten Vorgesetzten unterstellt sind, und Genehmigungsberechtigungen folgen dieser Kette. Du hast nichts davon explizit formuliert -- das System hat es aus dem Kontext erschlossen.

Die Datenbank aufbauen

Jede App, die sich Dinge merken soll, braucht eine Datenbank -- stell dir ein strukturiertes Ablagesystem vor, oder eine Tabellenkalkulation mit Regeln darüber, wie verschiedene Blätter miteinander verbunden sind.

Wenn du "Urlaubsanträge" erwähnst, erstellt das System einen Speicherort dafür und arbeitet heraus, was jeder Antrag enthalten muss: den Mitarbeiter, der ihn eingereicht hat, die gewünschten freien Tage, einen Grund, den aktuellen Status (ausstehend? genehmigt? abgelehnt?), welcher Vorgesetzte die Entscheidung getroffen hat und wann.

Das Interessante ist, wie diese Teile zusammenhängen. Keine dieser Daten steht isoliert. Ein Antrag wird mit dem Mitarbeiter verknüpft, der ihn eingereicht hat. Dieser Mitarbeiter wird mit seinem Vorgesetzten verknüpft. Der Vorgesetzte ist ebenfalls ein Mitarbeiter. All diese Verbindungen werden automatisch verdrahtet, sodass die App später Fragen beantworten kann wie "Zeig mir alle offenen Anträge von Personen in Sarahs Team."

Die Oberfläche erstellen

Dann gibt es alles, was die Leute tatsächlich sehen und womit sie interagieren.

Für Mitarbeiter, die Anträge einreichen, generiert das System ein Formular mit Datumsauswahl, einem Textfeld für den Grund und einem Absenden-Button. Für Vorgesetzte, die Anträge prüfen, wird eine Liste oder Tabelle erstellt, die jeden Antrag mit den relevanten Details und Genehmigen/Ablehnen-Buttons zeigt. Die Personalabteilung bekommt ein Dashboard -- Diagramme zum Antragsvolumen im Zeitverlauf, Filter nach Abteilung, Statusaufschlüsselungen.

Jeder Benutzertyp bekommt eine Navigation, die für seine Rolle Sinn ergibt. Ein Mitarbeiter sieht das HR-Analyse-Panel nicht (und braucht es auch nicht). Ein Vorgesetzter sieht nicht die Teams anderer Vorgesetzter.

Das System kümmert sich auch um die visuellen Details, für die man sonst Stunden aufwenden würde: einheitliche Abstände, gut lesbare Typografie, ein stimmiges Farbschema. Ästhetisch nichts Bahnbrechendes, aber es sieht aus wie Software von Profis -- nicht wie etwas, das übers Wochenende zusammengebastelt wurde.

Geschäftslogik

Hier leben die eigentlichen Regeln. Wenn ein Mitarbeiter einen Antrag einreicht, wird er als "ausstehend" gespeichert und der richtige Vorgesetzte wird benachrichtigt. Vorgesetzte sehen nur Anträge ihrer eigenen Mitarbeiter, nicht aller im Unternehmen. Ein Klick auf "Genehmigen" aktualisiert den Status, zieht vom Urlaubsguthaben ab und löst eine Benachrichtigung aus. Das System lässt nicht zu, dass jemand Urlaub für bereits gebuchte Tage beantragt, und führt eine laufende Bilanz der verbleibenden Tage.

All das wird zu echtem Code, der ausgeführt wird, wenn Menschen mit der App interagieren. Die KI weiß nicht nur, was passieren soll -- sie findet heraus, wann Dinge passieren sollen und was zuerst validiert werden muss.

Wer darf was

Die meisten Geschäftsanwendungen müssen wissen, wer eingeloggt ist. Das System kümmert sich auch darum: Login-Screens (meist E-Mail und Passwort, manchmal Google-Anmeldung), verschiedene Benutzerrollen mit unterschiedlichen Berechtigungen und Zugriffskontrollen, die sicherstellen, dass jeder nur sieht, was er sehen soll.

Ein normaler Mitarbeiter loggt sich ein und sieht seine eigenen Anträge. Ein Vorgesetzter sieht sein Team. Die Personalabteilung sieht das ganze Unternehmen. Dieselbe Anwendung, drei verschiedene Erfahrungen -- je nachdem, wer fragt.

All das -- Datenstruktur, Oberfläche, Logik und Zugriffskontrolle -- wird gleichzeitig erarbeitet. Die KI arbeitet keine Checkliste Schritt für Schritt ab, sondern löst das gesamte Problem ganzheitlich. So wird etwas, wofür ein Entwicklerteam Wochen bräuchte, in Minuten erledigt.

Nur UI vs. Full-Stack: Ein entscheidender Unterschied

Etwas, das viele überrascht: Nicht alle KI-Builder erstellen dasselbe. Manche produzieren wunderschöne Oberflächen ohne irgendetwas dahinter. Andere bauen vollständige, funktionierende Systeme. Dieser Unterschied ist wichtiger, als die meisten realisieren -- bis sie schlechte Erfahrungen gemacht haben.

Das Mockup-Problem

Bestimmte Tools sind hervorragend darin, Benutzeroberflächen zu generieren -- die visuelle Ebene. Wunderschöne Formulare, saubere Dashboards, professionelle Typografie. Aber klick auf den "Absenden"-Button und nichts passiert. Füll ein Formular aus und die Daten verschwinden. Es ist eine Filmkulisse: beeindruckend von vorne, Gerüst und Sperrholz von hinten.

Diese Tools haben ihren Platz. Du musst Stakeholdern zeigen, wie etwas aussehen könnte? Perfekt. Du willst ein Design-Konzept validieren, bevor du in die Entwicklung investierst? Dafür hervorragend geeignet. Aber wenn du Software brauchst, die Menschen tatsächlich nutzen können -- die Daten speichert, Regeln durchsetzt und nicht alles vergisst, wenn du den Browser schließt -- brauchst du das echte Ding.

Was Full-Stack wirklich bedeutet

Full-Stack heißt, dass alles gebaut wird: die Screens (Frontend), die Logik, die Daten verarbeitet und Regeln durchsetzt (Backend), die Datenbank, die alles speichert, das Authentifizierungssystem, die API, die alle Teile verbindet, und das Hosting, damit Menschen darauf zugreifen können.

Hier die Aufschlüsselung:

Frontend: was Benutzer sehen und anklicken
Backend: die Logik, die Dinge tatsächlich zum Laufen bringt -- Daten validiert, Geschäftsregeln durchsetzt, mit der Datenbank kommuniziert
Datenbank: wo alles gespeichert wird, damit Daten zwischen Sitzungen erhalten bleiben und später abgefragt werden können
Authentifizierung: Login, Benutzerrollen, Sicherstellung, dass jeder nur auf das zugreifen kann, was er soll
API: die Kommunikationsschicht zwischen Frontend und Backend (für Benutzer unsichtbar, aber kritisch)
Hosting: Server, die deine App betreiben und sie über eine URL zugänglich machen

Wenn irgendetwas davon fehlt, hast du keine Anwendung. Du hast eine Demo.

Warum Chattee auf Full-Stack setzt

Chattee baut vollständige Anwendungen, weil das echte Probleme löst. Ein Urlaubsverwaltungssystem ist nutzlos, wenn es sich nicht merken kann, wer was eingereicht hat. Ein Kundenportal scheitert, wenn Kunden keine Dateien hochladen können, die dauerhaft gespeichert werden.

Beschreib etwas bei Chattee und du bekommst funktionierende Software -- kein Mockup, das du später neu bauen musst.

Iteration: Beim ersten Mal trifft es niemand perfekt

Rechne mit Verfeinerungen. Die erste Version -- ob KI-generiert oder nicht -- ist selten die endgültige.

Warum der erste Entwurf nicht perfekt ist

Wenn du beschreibst, was du willst, übersetzt du etwas aus deinem Kopf in Worte. Dabei geht immer etwas verloren. Du vergisst Dinge zu erwähnen, die dir offensichtlich erscheinen, oder verwendest einen Begriff, der für die KI etwas leicht anderes bedeutet.

Die erste Version wird also nah dran sein, aber nicht ganz. Die Genehmigungsbuttons sind vielleicht zu klein, du hast ein Feld vergessen, oder das Dashboard organisiert Daten auf eine Weise, die für die KI Sinn ergab, aber nicht für dich. Nichts davon sind Fehler. Die KI kann deine Gedanken nicht lesen (noch nicht jedenfalls), also ist etwas Hin und Her normal.

Die Gesprächsschleife

Wenn etwas nicht stimmt, reichst du keinen Fehlerbericht ein und wartest, bis ein Entwickler sich darum kümmert. Du beschreibst einfach das Problem:

"Die Genehmigungsbuttons sind auf dem Handy zu klein. Mach sie größer und setz sie an den unteren Rand der Karte."

Oder:

"Ich hab vergessen zu erwähnen -- Mitarbeiter sollten bei Krankmeldungen ein ärztliches Attest hochladen können. Füg ein Dateiupload-Feld hinzu, das nur bei Anträgen für Krankheitsurlaub angezeigt wird."

Oder:

"Das Dashboard ist zu überladen. Können wir es vereinfachen und nur drei Kennzahlen anzeigen: ausstehende Anträge, diesen Monat genehmigte und durchschnittliche Antwortzeit?"

Die KI nimmt die Änderungen vor. Du prüfst. Du verfeinerst bei Bedarf weiter. Jede Iteration dauert Minuten, nicht Tage.

Realistische Erwartungen setzen

Plane mindestens 2-3 Verfeinerungsrunden ein. Nicht weil die KI schlecht arbeitet, sondern weil:

Du Dinge bemerken wirst, die du ändern möchtest, sobald du sie siehst
Du feststellen wirst, dass du Anforderungen vergessen hast
Deine Stakeholder Feedback haben werden
Die reale Nutzung Randfälle aufdeckt

Die Gesamtzeit für diese Iterationen? Immer noch wahrscheinlich weniger als ein einzelnes Meeting in der traditionellen Entwicklung gedauert hätte.

Iteration effektiv gestalten

Der Schlüssel ist Spezifität. "Das Formular fühlt sich falsch an" gibt der KI nicht viel. "Mach den Absenden-Button grün statt blau und setz die Datumsfelder nebeneinander statt übereinander" -- das ist umsetzbar.

Bezieh dich auf Dinge, die bereits existieren. "Füg auf dem Manager-Dashboard eine Spalte für die Abteilung hinzu" ist besser als "füge irgendwo Abteilungsinformationen hinzu."

Wenn du mehrere Änderungen hast, geh sie am besten einzeln an. So lässt sich jede Korrektur leichter überprüfen. Und wenn etwas fehlerhaft aussieht, beschreib, was du siehst: "Wenn ich auf Genehmigen klicke, bekomme ich für eine Sekunde einen weißen Bildschirm, bevor die Liste aktualisiert wird" -- das gibt der KI etwas zum Untersuchen.

Häufige Missverständnisse

Einige hartnäckige Überzeugungen, die es wert sind, angesprochen zu werden.

"Das muss Magie sein -- oder Betrug." Weder noch. Die KI wurde mit Millionen von Beispielen echter Software trainiert: Oberflächen, Datenbankschemata, Geschäftslogik, Authentifizierungsmuster. Wenn du beschreibst, was du willst, synthetisiert sie etwas Passendes aus diesen Mustern. Standard-Geschäftstools passen zu Vorlagen, die die KI gut kennt. Ungewöhnliche, beispiellose Anwendungen brauchen möglicherweise mehr Iteration -- aber die meiste Geschäftssoftware ist nicht so ungewöhnlich.

Wie sehr zählt dein Prompt eigentlich? Mehr als du denkst. Vergleich "bau mir etwas für Urlaubsverfolgung" mit "bau ein Urlaubsantragssystem für eine 50-Personen-Marketingagentur, in dem Mitarbeiter Anträge mit Daten und Gründen einreichen, Vorgesetzte genehmigen oder ablehnen, und die Personalabteilung alle Anträge plus verbleibende Guthaben sieht -- gestalte es wie Notion."

Die zweite Version gibt der KI echte Einschränkungen. Unternehmensgröße beeinflusst die Berechtigungsstruktur. Die Erwähnung von Notion prägt Typografie und Abstände. Detail garantiert keine Perfektion, verbessert aber deinen Ausgangspunkt dramatisch.

Beim ersten Prompt trifft es niemand perfekt. Das ist wahrscheinlich die größte Frustrationsquelle für neue Nutzer. Komplexe Software entsteht nicht vollständig beim ersten Versuch -- egal ob Menschen oder KI sie bauen. Wer Erfolg hat, behandelt das als Gespräch: bauen, auf das Gesehene reagieren, verfeinern, wiederholen.

Zur Codequalität. Entwickler nehmen gern an, KI-generierter Code sei ein Chaos. Die Realität ist differenzierter: Er folgt Standardkonventionen, verwendet sinnvolle Muster, behandelt gängige Randfälle. Nicht wie ein Senior-Entwickler es schreiben würde, aber sauber genug, dass mehrere Chattee-Nutzer exportierten Code ihren Entwicklerteams gezeigt haben und bessere Reaktionen bekamen als erwartet.

Vielleicht erinnerst du dich, als KI-Tools nur einfache Formulare und Listen erstellen konnten. Dieser Eindruck blieb hängen, aber die Obergrenze hat sich erheblich verschoben. Aktuelle Plattformen bewältigen Multi-Rollen-Berechtigungen, komplexe Genehmigungsketten, bedingte Logik, berechnete Felder, API-Integrationen, Dateihandling und Benachrichtigungen. Heute liegt die Einschränkung meist darin, wie gut du beschreiben kannst, was du brauchst -- nicht darin, was die KI bauen kann.

Was ist mit Vendor Lock-in? Berechtigte Sorge. Bei Chattee kannst du den vollständigen Quellcode jederzeit exportieren -- Frontend, Backend, Datenbankschemata, alles. Standardtechnologien, keine proprietären Abhängigkeiten. Wenn du irgendwann auf deine eigene Infrastruktur umziehen willst, gehört der Code dir.

Ein reales Beispiel: Ein Urlaubsantragssystem bauen

Theorie ist schön und gut, aber lass uns einen tatsächlichen Build durchgehen -- ein Urlaubsantragssystem, vom ersten Prompt durch mehrere Verfeinerungsrunden.

Der Ausgangs-Prompt

"Baue ein Mitarbeiter-Urlaubsantragssystem für ein Unternehmen mit etwa 100 Personen. Es gibt drei Benutzertypen: normale Mitarbeiter, Vorgesetzte und Personaladministratoren.

Mitarbeiter können Urlaubsanträge mit Startdatum, Enddatum, Art (Urlaub, Krankheit, persönlicher Tag) und einer optionalen Notiz einreichen. Sie können alle ihre vergangenen Anträge und ihr aktuelles Urlaubsguthaben einsehen.

Vorgesetzte sehen Anträge von Mitarbeitern, die ihnen unterstellt sind. Sie können jeden Antrag mit einem optionalen Kommentar genehmigen oder ablehnen. Außerdem sollen sie eine Kalenderansicht sehen, die zeigt, wer in ihrem Team an welchem Tag abwesend ist.

Personaladministratoren sehen alles: alle Anträge im gesamten Unternehmen, ein Dashboard mit Kennzahlen (gesamte beantragte Tage in diesem Quartal, Genehmigungsraten usw.) und die Möglichkeit, das Urlaubsguthaben jedes Mitarbeiters anzupassen.

Das Design soll sauber und professionell sein -- denk an ein modernes SaaS-Tool. Blaues Farbschema. Mobilfreundlich, da die Leute das auf ihren Handys prüfen werden."

Was zurückkommt

Einige Minuten später gibt es eine funktionierende Anwendung. Die Datenbank hat Tabellen für Benutzer (mit Rollen), Urlaubsanträge (mit Status, Daten, Art, Notizen), die Unterstellungsverhältnisse zwischen Mitarbeitern und Vorgesetzten sowie Urlaubsguthaben.

Die Oberfläche umfasst eine Login-Seite, ein Mitarbeiter-Dashboard zum Einreichen von Anträgen und Einsehen der Historie, eine Vorgesetzten-Ansicht mit Warteschlange ausstehender Anträge und Team-Kalender sowie ein Personaladmin-Panel mit unternehmensweiten Kennzahlen. Es gibt auch eine Profileinstellungsseite.

Die Geschäftslogik ist verdrahtet: Anträge werden validiert (Enddatum muss nach Startdatum liegen, darf das Guthaben nicht überschreiten), der Genehmigungsworkflow aktualisiert Status korrekt, Genehmigungen ziehen automatisch vom Guthaben ab, und Benachrichtigungs-Hooks sind eingerichtet (wobei wir in einem späteren Schritt konfigurieren, wohin diese tatsächlich gehen).

Authentifizierung funktioniert ebenfalls -- sicherer Login, rollenbasierter Zugriff, damit Mitarbeiter nicht versehentlich in Vorgesetzten-Ansichten landen, Sitzungsverwaltung, damit Benutzer eingeloggt bleiben.

Der Kalender-Blindspot

Beim Testen zeigt sich ein Problem: Der Team-Kalender zeigt nur genehmigten Urlaub an -- keine ausstehenden Anträge. Aber Vorgesetzte müssen ausstehende Anträge sehen, wenn sie über Genehmigungen entscheiden. Sonst genehmigt man drei Personen für dieselbe Woche.

"Zeig im Team-Kalender des Vorgesetzten auch ausstehende Anträge neben den genehmigten an. Verwende eine andere Farbe -- Gelb für ausstehend, Grün für genehmigt."

Zwei Minuten später können Vorgesetzte das vollständige Bild sehen, bevor sie entscheiden.

Benachrichtigungen hinzufügen

Das System funktioniert, aber niemand will den ganzen Tag die App aktualisieren und sich fragen, ob der Urlaub genehmigt wurde.

"Füge E-Mail-Benachrichtigungen hinzu: Wenn ein Mitarbeiter einen Antrag einreicht, sende eine E-Mail an den Vorgesetzten. Wenn ein Vorgesetzter genehmigt oder ablehnt, sende eine E-Mail an den Mitarbeiter. Wöchentliche Zusammenfassung an die Personalabteilung. Halte die E-Mails einfach und professionell."

Das System erstellt einen E-Mail-Dienst, gestaltet Vorlagen und verdrahtet alles mit den richtigen Auslösern.

Feinschliff nach Feedback

Sobald einige Leute das System nutzen, fallen Kleinigkeiten auf:

"Der Absenden-Button soll 'Antrag einreichen' heißen, nicht nur 'Absenden'. Füg ein Bestätigungsfenster vor dem Ablehnen hinzu -- wir wollen keine versehentlichen Ablehnungen. Auf dem Handy soll das Antragsformular einspaltig sein. Zeig das verbleibende Guthaben prominent oben auf dem Mitarbeiter-Dashboard an."

Jede dieser Änderungen dauert Sekunden.

Das Ergebnis

Das fertige System bewältigt den vollständigen Workflow von Antrag bis Genehmigung, zeigt jeder Benutzerrolle die richtige Ansicht, sendet E-Mail-Benachrichtigungen, sieht professionell auf Desktop und Handy aus und funktioniert tatsächlich -- Daten bleiben erhalten, Regeln werden durchgesetzt, nichts bricht ab, wenn man die Seite aktualisiert.

Gesamtzeit inklusive aller Iterationen: wahrscheinlich unter zwei Stunden. Dasselbe System hätte auf traditionellem Weg Wochen gedauert und Tausende von Euro gekostet.

Was tatsächlich funktioniert

Nach Tausenden von Builds zeigen sich Muster, die konstant zu besseren Ergebnissen führen.

Sei spezifisch darüber, wer es nutzt. Sag nicht einfach "Benutzer". Führe die verschiedenen Rollen auf und was jede braucht: "Mitarbeiter können ihre eigenen Anträge einsehen und neue einreichen. Vorgesetzte können alles, was Mitarbeiter können, plus Anträge ihrer direkten Mitarbeiter genehmigen. Die Personalabteilung sieht alles und kann das Guthaben jedes Mitarbeiters anpassen."

Beschreib Workflows, nicht nur Features. "Genehmigungsfunktion hinzufügen" ist vage. Besser: "Wenn ein Mitarbeiter einen Antrag einreicht, geht er als ausstehend in die Warteschlange des Vorgesetzten. Der Vorgesetzte genehmigt oder lehnt ab. Genehmigung zieht automatisch vom Guthaben ab. Ablehnung erfordert eine Begründung. In beiden Fällen wird der Mitarbeiter benachrichtigt."

Gib Designrichtung vor. Die KI kann verschiedene Ästhetiken umsetzen, aber du musst ihr eine Richtung geben. "Sauber und minimalistisch" produziert etwas anderes als "professionell und corporate wie Microsoft 365" oder "modern und freundlich wie Notion." Wenn es eine App gibt, deren Aussehen dir gefällt, nenn sie beim Namen.

Sag, was du nicht willst. Manchmal ist das genauso wichtig wie das, was du willst. "Füge keine Features hinzu, die ich nicht erwähnt habe." "Keine öffentlichen Seiten -- alles erfordert Login." "Keine Integrationen fürs Erste." Das hindert die KI daran, hilfsbereit Komplexität hinzuzufügen, die du später wieder entfernen musst.

Aufbauen statt abspecken. Starte mit der Kernfunktionalität und bau darauf auf. Erster Prompt: Grundstruktur und Haupt-Workflow. Zweiter: Verfeinern basierend auf dem, was du siehst. Dritter: Sekundäre Features. Vierter: Feinschliff und Randfälle. So fängst du Probleme früh, bevor sie sich aufschaukeln.

Probier es aus

Darüber zu lesen bringt dich nur bedingt weiter. Der Prozess ergibt mehr Sinn, wenn du beobachtet hast, wie eine Anwendung aus deiner eigenen Beschreibung entsteht.

Denk an etwas, das du schon länger brauchst. Der interne Workflow, der immer noch in Tabellen feststeckt. Das Kundenportal, das ständig in der Prioritätenliste nach unten rutscht. Das Tracking-System, das dein Team ein Dutzend Mal erwähnt hat, aber niemand Zeit hatte zu bauen.

Chattee ist kostenlos zum Starten -- keine Kreditkarte, keine Verpflichtung. Beschreib, was du willst, und schau, was passiert. Die erste Version wird nicht perfekt sein (ist sie nie), aber du hast eine funktionierende Anwendung, die du von dort aus verfeinern kannst.

Neugierig auf den breiteren Wandel in der Softwareentwicklung? Unser Leitfaden Was ist Vibe Coding? behandelt die Bewegung, die KI-gestützte Entwicklung zum Mainstream macht.