03. Mai 2025·8 Min
Von Intent zur App: Wenn KI UI, Zustand und APIs erzeugt
Die Geschichte einer mobilen App‑Idee, die zur funktionierenden App wird, indem KI UI erzeugt, Zustand verwaltet und Backend‑Services Ende‑zu‑Ende verbindet.
Die Geschichte einer mobilen App‑Idee, die zur funktionierenden App wird, indem KI UI erzeugt, Zustand verwaltet und Backend‑Services Ende‑zu‑Ende verbindet.
Eine Gründerin lehnt sich nach einem erneuten End‑of‑Quarter‑Sprint zurück und sagt: „Hilf den Außendienstmitarbeitern, Besuche schnell zu protokollieren und Folgeaktionen zu setzen, damit nichts verloren geht — ohne zusätzliche Verwaltungsarbeit.“
Dieser einzelne Satz fasst ein echtes Nutzerproblem: Notizen werden verspätet (oder gar nicht) erfasst, Folgeaktionen werden vergessen und Umsatz läuft stillschweigend davon.
Das ist das Versprechen einer KI‑unterstützten Umsetzung: Du startest mit einem Intent und kommst schneller zu einer funktionierenden mobilen App — ohne jedes einzelne Bildschirm-, Zustands‑ und API‑Detail von Hand zu verknüpfen. Kein „Zauber“, keine sofortige Perfektion, aber ein kürzerer Weg von der Idee zu etwas, das man tatsächlich auf einem Telefon starten und jemandem geben kann.
Dieser Abschnitt (und die folgende Geschichte) ist kein technisches Tutorial. Es ist eine Erzählung mit praktischen Erkenntnissen: was man sagt, welche Entscheidungen früh getroffen werden sollten und was man offenlässt, bis man den Flow mit echten Nutzern getestet hat.
Kurz gesagt: Intent ist das gewünschte Ergebnis, für eine konkrete Zielgruppe, unter klaren Randbedingungen.
Guter Intent ist keine Feature‑Liste. Er ist nicht „baue mir ein mobiles CRM“. Er ist der Satz, der allen — Menschen und KI — sagt, wie Erfolg aussieht.
Wenn der Intent klar ist, zielt man auf ein MVP, das mehr ist als klickbare Screens. Das Ziel ist eine versandfähige App mit echten Flows und echten Daten: Nutzer können sich anmelden, sehen die heutigen Accounts, protokollieren einen Besuch, fügen Notizen/Fotos an, legen einen nächsten Schritt fest und behandeln die üblichen Ausnahmefälle.
Alles, was danach kommt — Anforderungen, Informationsarchitektur, UI, Zustand, Backend‑Integration und Iteration — sollte diesem einen Satz dienen.
Maya ist die PM und zufällige Gründerin dieses Projekts. Sie will mobile Apps nicht neu erfinden — sie will eine ausliefern, bevor die Quartalsfrist die Chance zunichte macht.
Das „Team“ passt in einen Kalendertermin: Maya, eine Designerin mit wenigen Stunden pro Woche und eine einzelne Entwicklerin, die bereits zwei andere Apps betreut. Es bleibt keine Zeit für ein 40‑seitiges Spec, Framework‑Debatten oder monatelange Workshops. Trotzdem sind die Erwartungen real: Leadership will etwas Nutzbares, keinen Demo‑Hack.
Mayas Startartefakte sind bescheiden:
In ihren Notizen steht außerdem ein entscheidender Satz: „Wenn ein Nutzer die Hauptaufgabe nicht in unter zwei Minuten auf dem Telefon beenden kann, haben wir nicht das Richtige gebaut.“
Für dieses MVP ist „done“ eine einzelne Nutzerreise, die Ende‑zu‑Ende funktioniert:
Keine schicken Dashboards. Keine versteckten Menüs. Keine „wir polieren später“-Screens, die den Flow blockieren.
Die App muss an ein bestehendes Backend angeschlossen werden — APIs, die nicht für Mobile entworfen wurden und lückenhaft dokumentiert sind. Das Budget ist knapp, also muss jeder zusätzliche Screen sich rechtfertigen.
Einige Leitplanken sind nicht verhandelbar: Audit‑Logs, klare Einwilligungen wo nötig und keine sensiblen Daten, die ungeschützt auf dem Gerät liegen.
Und die Spannung: Maya hat zehn gute Ideen und vielleicht zehn Arbeitstage. Jede Stunde, die in Debatten fließt, ist eine Stunde, die nicht dem Kernflow zur Validierung dient.
Ziel ist nicht ein perfektes Spec. Es ist schnell zu testbarer Klarheit zu kommen — welches Problem wir lösen, für wen und woran wir erkennen, dass es funktioniert.
Du startest mit einem ungenauen Satz:
„Ich möchte eine App, die unseren Außendienstmitarbeitern hilft, Besuche zu protokollieren und Follow‑ups zu setzen.“
Dann bittest du die KI, das zu schärfen:
Prompt: „Formuliere das als Problemstatement und füge 3 Erfolgsmetriken hinzu. Kurz halten."
KI‑Ausgabe (bearbeitet):
Problemstellung: Außendienstmitarbeiter verlieren Follow‑ups, weil Besuchsnotizen und nächste Schritte verspätet (oder gar nicht) erfasst werden, was zu verpassten Umsatzchancen und inkonsistenter Kundenerfahrung führt.
Erfolgsmetriken:
Nun haben wir ein Ziel, auf das das Team zielen kann — nicht nur eine Feature‑Liste.
Wenn du einen Vibe‑Coding‑Workflow nutzt (zum Beispiel in Koder.ai, wo du das Produkt im Chat beschreibst und iterativ eine funktionsfähige App generierst), zahlt sich dieser Moment aus: ein präziser Intent + Metriken wird zur „Single Source of Truth“ für alles, was das System als Nächstes erzeugt.
Als Nächstes extrahiere Rollen und Aufgaben:
User‑Rollen:
Top‑Aufgaben:
Formuliere daraus ein paar User Stories mit Akzeptanzkriterien:
Um den ersten Release zu schützen:
Verankere jede Entscheidung an einem Flow:
App öffnen → „Besuch protokollieren“ → Kunde auswählen → Notiz/Foto hinzufügen → nächsten Schritt + Fälligkeitsdatum wählen → speichern → Follow‑ups erscheinen in „Heute“.
Wenn eine Anforderung diesen Flow nicht unterstützt, wartet sie auf die nächste Version.
Sobald der North‑Star‑Flow klar ist, kann die KI ihn in eine Informationsarchitektur (IA) übersetzen, die alle lesen können — ohne sofort in Wireframes oder komplexe Diagramme zu springen.
Für die meisten MVPs reicht eine kleine Anzahl von Bildschirmen, die den primären Job vollständig unterstützen. KI schlägt meist (mit Möglichkeit zur Anpassung) eine Liste wie diese vor:
Diese Liste bildet das Skelett. Alles, was darüber hinausgeht, ist später oder ein sekundärer Flow.
Statt abstrakt über Patterns zu debattieren, beschreibt die IA Navigation als Sätze, die man validieren kann:
Wenn es Onboarding gibt, definiert die IA, wo es startet und wo es endet („Onboarding endet bei Home").
Jeder Screen bekommt eine schlanke Gliederung:
Empty‑States sind oft die Stelle, an der Apps gebrochen wirken; formulier sie deshalb bewusst (z. B. „Heute noch keine Besuche protokolliert“ plus klarer nächster Schritt).
Die IA markiert bedingte Views früh: „Manager sehen einen zusätzlichen Tab“ oder „Nur Ops kann Account‑Details bearbeiten“. Das verhindert Überraschungen, wenn später Berechtigungen und Zustand umgesetzt werden.
Das Ergebnis ist typischerweise eine einseitige Flow‑Übersicht plus Bullet‑Punkte pro Screen — etwas, das ein nicht‑technischer Stakeholder schnell absegnen kann: welche Screens existieren, wie man zwischen ihnen navigiert und was passiert, wenn Daten fehlen.
Sobald der Flow abgestimmt ist, kann die KI erste Wireframes erzeugen, indem sie jeden Schritt als „Screen‑Contract“ behandelt: was der Nutzer sehen muss, was er als Nächstes tun kann und welche Informationen gesammelt oder angezeigt werden müssen.
Die Ausgabe ist meist grob — Graustufenblöcke mit Labels — aber bereits um Inhaltsbedürfnisse herum strukturiert. Braucht ein Schritt Vergleich, schlägt die KI ein Grid oder Kartenlayout vor. Geht es um Fortschritt, sieht man eine klare Primäraktion und eine kompakte Zusammenfassung.
Komponentenwahl ist nicht zufällig. Sie ist auf die Aufgabe ausgerichtet:
Die KI trifft diese Entscheidungen oft anhand der Verben im Intent: browse, choose, edit, confirm.
Schon in diesem Stadium sollten Generatoren Grundregeln anwenden, damit die Screens nicht „nach KI“ aussehen:
Copy‑Entwürfe erscheinen neben der UI. Statt „Submit“ heißt der Button „Besuch speichern“ oder „Follow‑up planen“, passend zur Aufgabe.
Hier greifen Produktverantwortliche, Designerinnen oder Marketerinnen ein — nicht um alles neu zu zeichnen, sondern um Ton und Klarheit anzupassen:
Du endest nicht nur mit Bildern. Die Übergabe ist meist ein klickbarer Prototyp (Tap‑through zur Feedback‑Sammlung) oder generierter Bildschirm‑Code, mit dem das Team im Build‑Test‑Loop weiterarbeitet.
Wenn du in Koder.ai baust, wird die UI oft direkt als Teil einer funktionierenden App erzeugt (Web in React, Backend in Go mit PostgreSQL, Mobile in Flutter) und du kannst die echten Screens an einem Ort prüfen und das Flow‑Dokument als Leitplanke behalten.
Nach der UI‑Skizze ist die nächste Frage simpel: Was muss sich die App merken und worauf muss sie reagieren? Dieses „Gedächtnis“ ist der Zustand. Er erklärt, warum ein Screen dich mit Namen begrüßt, einen Zähler behält, ein halb ausgefülltes Formular wiederherstellt oder Ergebnisse nach deinen Vorlieben sortiert.
Die KI definiert typischerweise eine kleine Menge von Zustandsobjekten, die durch die ganze App reisen:
Wichtig ist Konsistenz: Dieselben Objekte (und Namen) treiben alle Screens an, die sie nutzen, statt dass jeder Screen ein eigenes Mini‑Modell erfindet.
Formulare sind mehr als Inputs — sie sind sichtbare Regeln. Die KI kann Validierungsmuster erzeugen, die über Screens hinweg konsistent sind:
Für jede asynchrone Aktion (Anmeldung, Items laden, Besuch speichern) durchläuft die App vertraute Zustände:
Wenn diese Muster über Screens hinweg konsistent sind, wirkt die App vorhersehbar — und weniger fragil, wenn echte Nutzer unerwartet tippen.
Ein Flow ist nur real, wenn er echte Daten liest und schreibt. Sobald Screens und Zustandsregeln stehen, kann die KI übersetzen, was der Nutzer tut, in das, was das Backend unterstützen muss — und dann das Wiring generieren, sodass die App vom Prototyp zum Produkt wird.
Aus einer typischen Nutzerreise ergeben sich meist diese Buckets:
Die KI zieht diese Anforderungen direkt aus dem UI‑Intent. Ein „Speichern“‑Button impliziert eine Mutation. Ein Listen‑Screen impliziert einen paginierten Fetch. Ein Filter‑Chip impliziert Query‑Parameter.
Statt Endpoints isoliert zu bauen, leitet die Abbildung sich aus Screen‑Interaktionen ab:
POST /visitsGET /accounts?cursor=...PATCH /visits/:idPATCH /followups/:idWenn du bereits ein Backend hast, passt die KI sich daran an: REST‑Endpoints, GraphQL‑Operationen, Firebase/Firestore‑Sammlungen oder eine interne API. Wenn nicht, kann sie eine dünne Service‑Schicht generieren, die genau die UI‑Bedürfnisse abdeckt (und nichts Überflüssiges).
Die KI schlägt Modelle aus UI‑Copy und Zustand vor:
Visit { id, accountId, notes, nextStep, dueAt, createdAt }Ein Mensch bestätigt dann die Wahrheit: welche Felder erforderlich sind, was nullable ist, was indexiert werden muss und wie Berechtigungen funktionieren. Diese schnelle Überprüfung verhindert, dass „fast richtige“ Datenmodelle sich als Produkt verfestigen.
Integration ist ohne Failure‑Paths unvollständig:
Hier beschleunigt die KI die langweiligen Teile — konsistente Request‑Wrapper, typisierte Modelle und vorhersehbare Fehlerzustände — während das Team auf Korrektheit und Geschäftsregeln achtet.
Der erste „echte“ Test ist kein Simulator‑Screenshot — es ist ein Build auf einem echten Telefon, in einer Hand, mit imperfectem WLAN. Dort zeigen sich die ersten Risse.
Meistens nicht das große Feature, sondern die Nähte:
Diese Fehler sind nützlich. Sie zeigen, wovon deine App wirklich abhängt.
Bei Ausfällen ist die KI ein Schicht‑übergreifender Detektiv. Statt UI, Zustand und API getrennt zu jagen, lässt sich der Pfad Ende‑zu‑Ende untersuchen:
profile.photoUrl, Backend liefert avatar_url.Weil die KI Flow, Screen‑Map und Datenverträge im Kontext kennt, kann sie einen einzigen Fix vorschlagen, der alle betroffenen Stellen adressiert — Feld umbenennen, Fallback‑State hinzufügen und Endpoint‑Antwort anpassen.
Jeder Test‑Build sollte beantworten: „Kommen wir der Metrik näher?“ Füge eine kleine Menge Events hinzu, die zu deinen Erfolgszielen passen, z. B.:
signup_started → signup_completedfirst_action_completed (dein Aktivierungsereignis)error_shown mit Grundcode (timeout, validation, permission)Feedback wird so weniger zur Meinung und mehr zu einem messbaren Funnel.
Eine einfache Routine hält die Dinge stabil: täglicher Build + 20‑min Review. Jeder Zyklus nimmt ein oder zwei Fixes, und aktualisiert UI, Zustand und Endpoints zusammen. So vermeidest du halbgefertigte Features — der Bildschirm kann richtig aussehen, aber die App darf nicht daran scheitern, reale Timing‑ oder Berechtigungsprobleme zu behandeln.
Sobald der Happy Path läuft, muss die App das echte Leben überstehen: Tunnele, niedriger Batteriezustand, verweigerte Berechtigungen und unvorhersehbare Daten. Hier hilft die KI, indem sie „nicht kaputt gehen“ in überprüfbares Verhalten übersetzt.
Kennzeichne jede Aktion als offline‑sicher oder verbindungsabhängig. Beispiel: Browsen bereits geladener Accounts, Entwürfe bearbeiten und zwischengespeicherte Historie funktionieren offline. Volltextsuche, Syncs und personalisierte Empfehlungen brauchen meist Verbindung.
Guter Default: Aus Cache lesen, in Outbox schreiben. Die UI zeigt deutlich, ob eine Änderung „lokal gespeichert“ oder „gesynct“ ist, und bietet „Erneut versuchen“, wenn Verbindung wieder da ist.
Fordere Berechtigungen im Moment des Bedarfs an:
Wichtig sind sanfte Alternativen, keine Sackgassen.
Die KI kann Edge‑Cases schnell auflisten; das Team entscheidet die Produkthaltung:
Security‑Basics: Tokens im sicheren Speicher ablegen, least‑privilege‑Scopes nutzen und mit sicheren Defaults ausliefern (keine detaillierten Logs, kein „remember me“ ohne Verschlüsselung).
Accessibility‑Checks: Kontrast, Mindest‑Tap‑Flächen, dynamische Textunterstützung und sinnvolle Screen‑Reader‑Labels — besonders für icon‑only Buttons und Custom Components.
Beim Shipping entscheidet sich, ob ein vielversprechender Prototyp zum echten Produkt wird — oder stillsteht. Wenn die KI UI, Zustandsregeln und API‑Wiring erzeugt hat, ist das Ziel, den laufenden Build in etwas zu verwandeln, das Rezensenten (und Kunden) sicher installieren.
Behandle „Release“ als kleine Checkliste, nicht als Heldentat:
Auch ein simples MVP braucht passend gewählte Metadaten:
Plane den Launch wie ein Experiment.
Nutze Internal Testing zuerst, dann einen staged release (phasenweiser Rollout) zur Begrenzung der Blast‑Radius. Überwache Crash‑Rate, Onboarding‑Completion und Konversionen der Schlüsselaktion.
Definiere Rollback‑Trigger vorab — z. B. Abstürze steigen über Schwellenwert, Sign‑in‑Fehler schießen hoch oder Funnel‑Rate bricht ein.
Wenn dein Build‑System Snapshots und schnellen Rollback unterstützt (z. B. Koder.ai bietet Snapshots/Rollback neben Deployment/Hosting), wird „Undo“ zur normalen Release‑Option — kein Panik‑Move.
Wenn du Hilfe brauchst, deine MVP‑Checkliste in eine wiederholbare Release‑Pipeline zu verwandeln, siehe /pricing oder kontaktiere uns via /contact.
Wenn KI Screens, Zustand und API‑Integrationen entwirft, verschwindet Arbeit nicht — sie verschiebt sich. Teams verbringen weniger Zeit damit, Intent in Boilerplate zu übersetzen, und mehr Zeit damit zu entscheiden, was gebaut werden sollte, für wen und in welchem Qualitätsmaß.
KI erzeugt besonders gut zusammenhängende Ausgaben über mehrere Schichten, sobald der Flow klar ist:
KI schlägt vor; Menschen entscheiden:
Schnelligkeit hilft nur, wenn der Code verständlich bleibt:
Wenn die erste Version in einer Plattform wie Koder.ai generiert wurde, ist ein praktischer Hebel die Source‑Code‑Export‑Funktion: der Übergang von „schnell generiert“ zu „teamgepflegtem Codebase“ ohne komplettes Rewriting.
Nach dem MVP fokussieren sich Iterationen meist auf Performance (Startzeit, List‑Rendering), Personalisierung (gespeicherte Präferenzen, bessere Defaults) und tiefere Automatisierung (Test‑Generierung, Analytic‑Instrumentierung).
Für mehr Beispiele und weiterführende Artikel siehe /blog.
Intent ist ein einzelner Satz, der klärt:
Es ist keine Feature-Liste; es ist die Definition von Erfolg, die UI, Zustand und APIs auf ein Ziel ausrichtet.
Eine gute Intent-Formulierung ist konkret und messbar. Nutze diese Struktur:
Beispiel: “Hilf Leitern kleiner Kliniken, Termine automatisch zu bestätigen, damit Ausfälle sinken, ohne zusätzliche Verwaltungsarbeit.”
„Versandfähig“ bedeutet, dass die App eine Kernreise mit echten Daten abschließt:
Wenn Nutzer die Hauptaufgabe nicht schnell auf dem Telefon abschließen können, ist sie noch keine echte Release‑App.
Bitte die KI, deine Idee in folgende Form zu bringen:
Anschließend passe die Zahlen mit deiner Fachexpertise an—so misst du Wirkung statt Aktivität.
Konzentriere dich auf:
Halte Akzeptanzkriterien beobachtbar (z. B. “Zeitstempel gespeichert”, “Nächster Schritt erforderlich ODER Notiz erforderlich”), damit Engineering und QA schnell validieren können.
Schneide alles weg, was den North‑Star‑Flow nicht unterstützt. Typische MVP‑Ausschlüsse:
Halte eine explizite Liste „ausgeschlossen“, damit Stakeholder wissen, was bewusst verschoben wurde.
Beginne mit 3–7 Kernbildschirmen, die die Hauptaufgabe vollständig unterstützen:
Definiere Navigation in klaren Sätzen (Tabs vs. Stack) und beschreibe Empty‑States, damit die App bei fehlenden Daten nicht kaputt wirkt.
Zustand ist das, was sich die App merken und worauf sie reagieren muss. Übliche MVP‑Zustandsobjekte:
Arbeite von den Bildschirmen zurück:
GET /items (meist paginiert)POST oder PATCHDELETELass die KI Schemata vorschlagen, bestätige aber Felder, Berechtigungen und Namenskonventionen (z. B. vs. ), bevor sie im Produkt verfestigt werden.
Bewerte pro Aktion, ob sie offline‑sicher oder verbindungsabhängig ist. Praktischer Default:
Bei Berechtigungen frage im richtigen Moment (Kamera beim Foto‑Upload, Benachrichtigungen erst nach Opt‑in) und biete eine Fallback‑Option (manuelle Eingabe, In‑App‑Erinnerung), statt Dead‑Ends.
Standardisiere außerdem asynchrone Zustände: loading → success → failure, und bewahre Nutzereingaben bei Fehlern.
photoUrlavatar_url