Codex ist genial im Design. Hier ist der Workflow, der wirklich funktioniert.

Codex + ein geheimes Tool ist der Design-Workflow, den wir in unserer Agentur nutzen … und die Ergebnisse sind wirklich auf einem ganz anderen Niveau.

Ich sage das seit Monaten. Wenn deine App wie KI-Schrott aussieht, ist das kein Codex-Problem. Das ist ein Workflow-Problem.

Die meisten Entwickler stecken in derselben Schleife. Sie liefern Features mit KI aus. Das Backend funktioniert. Die Logik ist solide. Aber das Interface sieht aus wie jede andere Vibe-coded-App. Innerhalb von zwei Sekunden entscheiden Nutzer, ob es sich echt anfühlt.

Die alte Lösung war, einen Designer einzustellen. Wochen auf Figma-Dateien warten. Dann zusehen, wie dein Entwickler diese Designs interpretiert und im Code neu aufbaut. Bis das Design live war, hattest du den Schwung verloren und Geld verbrannt, das du nicht hättest verbrennen müssen.

Dieser gesamte Prozess ist jetzt optional.

Für diese Anleitung habe ich Haven gebaut, ein Konzept für eine Immobilien-Mobile-App. Vollständiges Designsystem in 20 Minuten. Jeder Screen in unter einer Stunde designed. Produktionscode über Codex ausgeliefert, ohne eine einzige CSS-Zeile neu zu schreiben.

Das ist der Workflow, den ich jetzt verwende. Und jeder Entwickler, der mit KI ausliefert, muss verstehen, wie er funktioniert.

Was Moonchild wirklich ist

Das geheime Tool ist Moonchild.

Ich habe fast jedes KI-Design-Tool getestet, das im letzten Jahr auf den Markt gekommen ist. Die meisten sehen auf dem ersten Screen ganz gut aus, zerfallen aber, sobald du eine zweite Seite baust. Beständigkeit ist das Problem. Moonchild löst es auf eine Weise, die keinem anderen gelingt.

Es ist eine chatgesteuerte Design-Leinwand, die von deinem Designsystem ausgeht. Nicht von einem leeren Prompt. Nicht von einem Screenshot. Von deinem tatsächlichen System. Du bringst dein System auf drei Arten ein:

→ Importiere aus Figma, GitHub oder einer Live-URL

→ Beschreibe deine Marke gegenüber dem Agentic Design System Builder

→ Füge Design-Inspiration von Dribbble oder anderswo ein

Sobald das System drin ist, promptest du nicht mehr auf die alte Weise. Du fügst ein PRD ein. Es generiert vollständige Screens gegen dein System. Von dort aus führst du die künstlerische Regie.

Und der Exportpfad schließt den Kreislauf. Moonchild liefert einen MCP-Connector mit, der deine Designs direkt als strukturierte Ausgabe an Codex übergibt. Kein Screenshot, den Codex interpretieren muss. Die tatsächlichen Design-Daten. Komponenten, Tokens, Layout, alles.

Das ist der Workflow. Und jetzt kommt, wie du ihn tatsächlich nutzt.

Das Problem, wie die meisten Entwickler KI für Design nutzen

So gehen die meisten Entwickler vor.

Sie prompten Codex, um eine neue Funktion zu bauen. Sie wird ausgeliefert. Sieht okay aus. Dann prompten sie die nächste Funktion. Sieht etwas anders aus. Bei der fünften Funktion sieht die App aus wie fünf verschiedene Produkte, die zusammengenäht wurden.

Das ist es, was die Leute meinen, wenn sie sagen, KI-Design sei schlecht.

Das Modell ist nicht schlecht. Der Workflow ist es.

Codex hat keine Ahnung, was deine Designsprache ist. Jeder Prompt ist ein frischer Kontext. Jeder Screen ist eine Vermutung. Jede Komponente driftet von der vorherigen ab. Die Farben verschieben sich. Die Typografie verschiebt sich. Alles potenziert sich.

Die Lösung ist einfach. Gib Codex ein System zum Befolgen. Dann gib ihm das tatsächliche Design, das er bauen soll.

Die meisten Workflows geben ihm nur das eine oder das andere. Moonchild plus die MCP-Verbindung gibt ihm beides gleichzeitig.

Schritt 1: Baue zuerst dein Designsystem. Immer.

Das ist der Schritt, den alle überspringen. Er ist auch der wichtigste.

Bei @ignytlabs bauen wir für jeden einzelnen Kunden ein Designsystem, bevor wir einen Screen anfassen. Früher hat das einen Designer zwei Tage gekostet. Moonchild erledigt es in etwa 20 Minuten.

Für diese Anleitung habe ich Haven gebaut, ein Konzept für eine Immobilien-Mobile-App. Es gibt mehrere Möglichkeiten, ein Designsystem in Moonchild zu bekommen. Du kannst aus Figma, GitHub oder einer Live-URL importieren. Du kannst deine Marke gegenüber dem Agentic Design System Builder beschreiben. Für Haven habe ich das gemacht, was ich normalerweise tue, wenn ich von einem Vibe ausgehe. Design-Inspiration von Dribbble. Ich habe drei Screenshots von mobilen Immobilien-Apps eingefügt, die das Gefühl, das ich suchte, perfekt getroffen haben, plus eine kurze Beschreibung, was Haven ist und für wen es gedacht ist. Das Tool hat die Designsprache extrahiert und das System von Grund auf neu aufgebaut.

Was mich überrascht hat, ist, wie vorschaubar alles ist. Die meisten KI-Tools, einschließlich des Google-Stitch-Workflows, über den ich in meinem letzten Artikel geschrieben habe, geben dir eine flache Token-Datei. Farben. Schriften. Vielleicht Abstände. Dieses Tool macht etwas anderes. Es baut eine vollständige Komponentenbibliothek und eine Galerie. Jedes Badge, jeder Button, jede Karte und jeder Chip so gerendert, wie sie in deiner App tatsächlich aussehen werden. Klicke auf eine Komponente und du siehst sie live, mit Steuerungselementen zum Testen von Varianten und Größen. Direkt unter der Vorschau erhältst du das tatsächliche JavaScript, CSS, Beispiele und Abhängigkeiten für diese Komponente. Bereit, in die Codebasis übernommen zu werden.

Die Galerie ist der Teil, der wirklich verändert, wie du designst. Anstatt zu raten, wie ein „Marken-Badge“ oder „Bewertungs-Badge“ im Kontext aussehen sollte, siehst du sie alle nebeneinander. Zum Verkauf. Zur Miete. Hervorgehoben. Die ganze Familie auf einmal. Du triffst fundierte Designentscheidungen, bevor ein einziger Screen generiert wird.

Es ist der Unterschied zwischen einem Stylesheet und einem echten System.

Schritt 2: Vom PRD zur UI

Sobald dein Designsystem drin ist, promptest du nicht mehr auf die alte Weise.

Du fügst ein PRD ein.

Ein einseitiges Feature-Briefing. Eine Produktspezifikation. Eine Zielsetzung. Was auch immer du hast.

Für Haven habe ich ein strukturiertes PRD eingefügt, das die Produkteinführung, die Ziele, die Zielnutzer und Rollen, die wichtigsten Funktionen und den MVP-Umfang, die vollständigen User Journeys, den technischen Stack und die Designrichtung abdeckt. Ungefähr eine Seite. Spezifisch genug, um dem Tool echten Kontext zu geben. Strukturiert genug, dass es die richtigen Details in die richtigen Screens zieht.

Dann habe ich etwas getan, was die meisten überspringen.

Ich habe damit gebrainstormt, bevor ich einen einzigen Screen generiert habe.

Das ist der entscheidende Vorteil, den die meisten Entwickler verpassen. Der Chat-Modus hält den gesamten PRD-Kontext. Anstatt das PRD einfach hineinzuwerfen und auf Generieren zu drücken, besprichst du zuerst das Produkt. Bestätige die Liste der Screens. Lege das Navigationsmuster fest. Definiere die Hierarchie der wichtigsten Screens im Voraus, bevor irgendwelche Pixel existieren.

Für Haven habe ich gefragt:

→ „Basierend auf diesem PRD, welche Screens empfiehlst du, als erstes zu bauen? Fehlt mir etwas für eine Immobilien-App?“

→ „Soll die primäre Navigation ein unterer Tab mit Home, Suche, Favoriten, Profil sein? Oder etwas anderes?“

→ „Bevor du generierst, geh bitte die Prioritätsreihenfolge für den Property-Detail-Screen durch. Fotos zuerst, dann Name und Preis, dann Spezifikationen, dann Annehmlichkeiten, dann Makler. Bestätige oder verbessere.“

→ „Ok, jetzt fahre bitte fort und generiere diese Screens sowohl im hellen als auch im dunklen Modus, unter Einhaltung des Designsystems, das ich derzeit angehängt habe. Stelle sicher, dass du die gesamte User Journey abschließt und alle Screens erstellst.“

Als ich auf Generieren drückte, kannte das Tool das Produkt bereits besser, als die meisten Designer nach ihrem ersten Kundentermin.

Jetzt eine kurze Anmerkung zu Varianten. Lies das genau.

Eine coole Funktion: Du kannst verschiedene Varianten deiner Screens erstellen. Du musst es Moonchild nur explizit sagen, und es kümmert sich darum. Für Haven wollte ich drei verschiedene ästhetische Richtungen für die gesamte App, bevor ich mich für eine entschied. Hier ist der genaue Prompt, den ich verwendet habe:

„Ich möchte, dass du 3 vollständige mobile UI-Designkonzepte für Haven generierst:

Konzept 1 – Warm Editorial: Cremefarbene Hintergründe, großzügige Abstände, Serifen-Überschriften für Objektnamen, weiche Schatten, bildmagazinartige Bildbehandlung.

Konzept 2 – Bold Modern: Dark Mode, hoher Kontrast, durchgehend serifenlos, scharfe Ecken, fotogeführt mit randlosen Bildern.

Konzept 3 – Premium Minimal: Neutrale Palette (Off-White, Anthrazit, einzelne Akzentfarbe), raffinierte Typografie, viel Luft, subtile Mikrointeraktionen.

Verwende das angeschlossene Designsystem als Grundlage, aber lass jedes Konzept das System in eine andere ästhetische Richtung ziehen. Generiere vollständige Screens, nicht nur Abschnitte. Was wirst du tun?“

Beachte das „Was wirst du tun?“ am Ende. Das ist das kleine Detail, das das Ganze zum Laufen bringt. Anstatt einfach blind alles zu generieren, kam das Tool mit einem Plan zurück.

Es sagte, es würde zunächst 5 repräsentative Screens pro Konzept bauen. Ich würde die drei Richtungen nebeneinander prüfen. Sobald ich die gewünschte ausgewählt hätte, würde es die gesamte App in dieser Richtung designen.

Das verändert die Kostenrechnung völlig. Du zahlst nicht für drei vollständige Builds. Du zahlst für drei schnelle Muster, dann einen einzigen vollständigen Build in der Richtung, die du tatsächlich wählst.

Ich habe das warme editoriale ausgewählt. Der vollständige Satz von Screens kam als Nächstes.

Jetzt der Teil, der mich wirklich überrascht hat.

Jeder Screen, den Moonchild generiert, ist im Vorschaumodus interaktiv. Kein statischer Mockup. Tatsächlich interaktiv.

Du kannst in Eingabefelder klicken. Auf Buttons tippen. Dich zwischen Screens bewegen wie ein echter Nutzer, der den Prototypen testet, bevor irgendein Code geschrieben wird. Bei Haven habe ich in der Vorschau zwei Flow-Probleme entdeckt, die sonst an Codex ausgeliefert worden wären. Der Property-Detail-Screen hatte keinen offensichtlichen Weg zurück zum Durchsuchen. Der Contact-Agent-CTA war zu weit unter dem Falz. Beide wären ausgeliefert worden, wenn ich das Design ohne vorheriges Durchklicken an Codex übergeben hätte.

Das ist der entscheidende Vorteil. Du testest das Produkt, bevor Code geschrieben wird.

Der Verfeinerungszyklus ist das letzte Stück.

Wenn ein Screen bearbeitet werden muss, promptest du nicht von Grund auf neu. Du wählst den Screen aus, sagst dem Tool, was geändert werden soll, und es generiert eine v2 an Ort und Stelle. Möchtest du einen cineastischeren Hero? v2. Möchtest du ein Kartenlayout gegen eine Listenansicht austauschen? v3. Die Varianten stapeln sich, sodass du vergleichen und die stärkste auswählen kannst.

Für Havens Property-Detail-Screen bin ich drei Iterationen durchgegangen. v1 hatte den Maklerblock zu weit oben. v2 korrigierte die Hierarchie, aber die Fotogalerie wirkte klein. v3 hat beides perfekt hinbekommen. Etwa 8 Minuten hin und her.

Du kuratierst nicht von einer leeren Leinwand. Du verfeinerst eine echte Richtung. Das ist der Teil, der sich am nächsten an der Zusammenarbeit mit einem Senior Designer anfühlt.

Schritt 3: Moonchild mit Codex via MCP verbinden

Hier wird der Workflow richtig KRANK.

Das Designsystem gibt Codex die Regeln. Die MCP-Verbindung gibt Codex etwas Mächtigeres: direkten Zugriff auf die tatsächlichen Design-Outputs. Keine Screenshots. Keine Textbeschreibungen des Designs. Strukturierte Design-Daten, die Codex lesen und neu aufbauen kann.

So richtest du es ein:

→ Gehe zu Moonchild-Einstellungen, dann MCP

→ Kopiere den Installationsbefehl für dein Setup

→ Öffne Codex CLI

→ Füge den Installationsbefehl ein

→ Authentifiziere dich mit deinem Moonchild-Konto

→ Fertig

Sobald verbunden, sieht Codex sowohl dein Designsystem als auch die spezifischen Haven-Screens, die du designed hast.

Schritt 4: Codex liefert den Code aus

Jetzt promptest du Codex so:

Hole das Haven Real Estate Mobile App-Projekt mit dem Moonchild MCP und lass mich wissen, welche Screens wir darin haben.

Dieser erste Prompt übernimmt zwei Aufgaben: Er bestätigt, dass das MCP korrekt verbunden ist, und gibt Codex volle Sicht auf jeden Screen, den du designed hast.

Ein kurzer Tipp, bevor du Codex etwas Schwereres machen lässt. Bleib im Plan-Modus. Codex zeigt an, was es vor der Ausführung tun wird. Lies den Plan jedes Mal durch. Stelle sicher, dass es versteht, welche Screens du willst, in welcher Reihenfolge und mit welcher Detailtreue. Das ist der Unterschied zwischen Codex, der das codiert, was du tatsächlich brauchst, und Codex, der das codiert, was es denkt, dass du brauchst.

Sobald du den Plan überprüft und auf den gewünschten Screen verwiesen hast, zieht Codex die Design-Daten direkt von Moonchild, greift auf dein Designsystem zu und schreibt den Code. Es fügt sogar Hover-Zustände, Übergänge und die Behandlung von Randfällen hinzu, weil es mit echten Design-Daten arbeitet, anstatt aus einem Prompt zu raten.

Das Ergebnis: Produktionsreife UI in deiner tatsächlichen Codebasis, die exakt dem Design entspricht, in Minuten.

Bei @ignytlabs haben wir früher zwei Wochen für das Design jedes Kunden-MVP eingeplant. Ein Designer baute die Figma-Datei. Ein Entwickler interpretierte sie. Die Interpretation driftete ab. Wir korrigierten. Zyklus. Mit diesem Workflow bricht der gesamte Kreislauf auf einen einzigen Nachmittag Arbeit zusammen. Gleiche Qualität. Höhere Marge. Viel weniger Kontextwechsel.

Wann du diesen Workflow einsetzen solltest

Dies ist nicht der richtige Workflow für jedes Team. Sei ehrlich, wann er passt.

Nutze ihn, wenn:

→ Du als Solo-Entwickler oder kleines Team MVPs auslieferst

→ Die Designkonsistenz über Screens hinweg immer wieder bricht

→ Du keine separate Figma-zu-Designer-zu-Entwickler-Pipeline unterhalten willst

→ Du bereits ein Designsystem hast und es überall durchgesetzt haben möchtest

Überspringe ihn, wenn:

→ Du im großen Stil mit einem vollständigen internen Designteam und einer ausgereiften Figma-Bibliothek arbeitest

→ Du eine pixelgenaue Übergabe für eine Marketing-Website oder Markenarbeit brauchst, bei der jeder Schatten zählt

→ Deine Codebasis hochgradig maßgeschneiderte UI-Muster hat, die eine individuelle Designarbeit erfordern

Für 80 % der Entwickler, die MVPs und SaaS-Produkte ausliefern, deckt dieser Workflow alles ab, was du brauchst.

Worauf du achten solltest

Ein paar ehrliche Hinweise, bevor du loslegst.

Die Qualität deines Designsystems bestimmt die Qualität der Ergebnisse. Müll rein, Müll raus. Eine halbfertige Figma-Datei mit drei Farb-Tokens wird mittelmäßige Screens hervorbringen. Investiere Zeit in das System von Anfang an. Es zahlt sich bei jedem Screen zurück.

Die PRD-Qualität ist wichtig. Ein vages Briefing bringt dir generische Screens. Ein spezifisches PRD mit User Flows, Randfällen und klarer Hierarchie bringt dir nützliche Designs. Das ist keine Einschränkung des Tools. Es ist eine Einschränkung des Denkens.

Du brauchst trotzdem Geschmack. Das Tool produziert. Du lenkst. Die richtige Variante auszuwählen und zu verfeinern, ist der Ort, an dem dein Urteilsvermögen liegt. Wenn du den Kurationsschritt überspringst, bist du wieder beim Vibe-Designen.

Manche Komponenten brauchen manuelle Anpassungen. Komplexe animierte Zustände, benutzerdefinierte Interaktionsmuster – alles außerhalb des Designsystems braucht einen manuellen Durchlauf in Codex. Das MCP bringt dich zu 90 % dorthin. Die letzten 10 % sind dein Geschmack.

Was das tatsächlich bedeutet

Hier meine ehrliche Einschätzung.

Der Engpass beim Ausliefern KI-gebauter Produkte war nie der Code. KI kann den Code schreiben. Der Engpass war schon immer die Designebene. Die Konsistenz, der Geschmack, das System, das alles zusammenhält.

Dieser Engpass ist gerade zusammengebrochen.

Bei unserer Agentur haben wir früher zwei Wochen für das Design jedes Kunden-MVP eingeplant. Einen Designer einstellen. Auf Figma-Dateien warten. Zusehen, wie der Entwickler es interpretiert. Zyklus. Was früher zwei Wochen dauerte, dauert jetzt zwei Tage. Gleiche Qualität. Schnellere Auslieferung. Höhere Marge.

Das ist der Workflow, den finanzierte Teams bereits mit ihren Figma-plus-Designer-plus-Entwickler-Pipelines haben. Der Unterschied ist, dass jetzt Solo-Entwickler, Indie-Agenturen und kleine Studios den gleichen Hebel ohne Personal bekommen.

2026 wird UNFAIR für Agenturen und Entwickler sein, die das zuerst verstehen.

TLDR

→ Hör auf, Codex die Schuld für schlechte UI zu geben. Codex ist nicht das Problem. Dein Workflow ist es.

→ Schritt 1: Baue dein Designsystem in Moonchild. Importiere aus Figma, GitHub oder einer Live-URL. Oder beschreibe deine Marke. Oder füge Dribbble-Inspiration ein, wie ich es für Haven getan habe.

→ Schritt 2: Füge dein PRD ein. Brainstorme im Chat-Modus, bevor du generierst. Lege zuerst die Screen-Liste und das Navigationsmuster fest.

→ Standardmäßig wird eine Variante generiert. Frage explizit nach mehreren Varianten auf Hero-Screens mit unterschiedlichen angegebenen Vibes.

→ Nutze die interaktive Vorschau, um den Flow zu testen, bevor Code geschrieben wird. Verfeinere Screens mit v2-, v3-Iterationen vor Ort.

→ Schritt 3: Verbinde Moonchild mit Codex via MCP. Das gibt Codex echte Design-Daten, keine Screenshots.

→ Schritt 4: Prompt Codex, jeden Screen mit dem MCP zu bauen. Produktionsreife UI wird in Minuten ausgeliefert.

→ Die Qualität deines Designsystems bestimmt die Qualität der Ergebnisse. Investiere dort.

→ Der Figma-zu-Übergabe-zu-Entwickler-Zyklus ist tot. Ein Workflow betreibt jetzt Design und Code gemeinsam.

AUF GEHT'S.