Wie ich echte Produkte mit KI-gestütztem Produktdesign ausliefere

Figma → Figma Make → VS Code → Claude Code / GPT Codex → Figma MCP → Gerätetests

Vor ein paar Monaten habe ich ein FlutterFlow-Projekt in Claude Code exportiert. Seitdem habe ich FlutterFlow nicht mehr geöffnet.

Die Art meiner Arbeit hat sich grundlegend verändert. Das Nützliche ist nicht, dass KI Code generieren kann – sondern dass ich jetzt selbst von der Designabsicht zur funktionierenden Software gelangen, sie unter realen Bedingungen testen und iterieren kann, bevor die Idee veraltet.

Was ich veröffentlicht habe

Das Wichtigste für mich ist, dass es sich hierbei um echte Produkte handelt, nicht um Experimente.

Halo ist eine Live-App für Kinder-Gute-Nacht-Geschichten auf iOS und Android. Mit diesem Workflow habe ich innerhalb weniger Wochen den Kauf einzelner Geschichten, die Unterstützung für fünf Sprachen und ein vollständiges Performance-Refactoring für ältere Geräte implementiert. Das war der Moment, in dem ich aufhörte, KI-Codierungstools als interessant zu betrachten, und anfing, sie als Teil meiner täglichen Praxis zu behandeln.

Ein WordPress-Übersetzungs-Plugin hat mir die wichtigere Lektion erteilt. Die erste Version scheiterte. Ich habe ein LLM auf eine WordPress-Codebasis losgelassen, ohne genügend Struktur für Kontext, Fehlerbehandlung oder Kostenüberwachung. Es hat stillschweigend $250 an API-Kosten verbrannt, bevor ich bemerkte, was passierte. Ich habe es von Grund auf neu aufgebaut, auf der offiziellen Plugin-Dokumentation basiert, den Kontext gestrafft und ein Reporting hinzugefügt. Die zweite Version verarbeitet jetzt mehr als 5.000 Beiträge in zehn Sprachen, mit einem gesperrten Glossar für doktrinäre Begriffe. Es funktioniert, weil die Überwachung besser wurde, nicht weil das Modell intelligenter wurde.

Ein Raumvisualisierer für Immobilien lief viel reibungsloser. Die Aufgabe war klar: Käufern zeigen, wie ein leerer Raum möbliert aussehen könnte. Es war eine gute Erinnerung daran, dass diese Tools sehr schnell sein können, wenn das Problem konkret und die Einschränkungen sichtbar sind.

Ein Kommentar-Modul für einen gemeinsamen Arbeitsprototyp ist vielleicht das kleinste Beispiel, aber es verdeutlicht den Wandel. Ich brauchte Kommentare direkt auf dem Prototyp, also habe ich sie gebaut. Das ist jetzt ein normaler Satz in meinem Workflow. Beispiel unten:

Was Prototyping früher bedeutete

Während des größten Teils meiner Karriere fiel Prototyping in eine von zwei Kategorien.

Bei Unternehmen wie Meta und Careem bedeutete es normalerweise, in Figma zu designen, Übergabeprotokolle zu schreiben, Leute durch die Absicht zu führen und dann darauf zu warten, dass die Technik es baut. Manchmal war das Endergebnis nah am Design. Manchmal nicht. So oder so war die Schleife langsam. Jede Iterationsrunde kostete Zeit, Koordination und ein wenig Verhandlung.

Für meine eigenen Produkte habe ich FlutterFlow verwendet. Es war schneller, aber es kam immer noch mit dem bekannten Kompromiss von No-Code-Tools: frühe Geschwindigkeit, spätere Reibung. Je spezifischer Ihre Idee wurde, desto mehr kämpften Sie mit der Abstraktionsschicht, anstatt das Produktproblem zu lösen. Etwas, das im Code einfach hätte sein sollen, konnte im Builder umständlich und zeitaufwendig werden.

In beiden Fällen war der Engpass derselbe. Ich konnte das Produkt oft klar sehen, aber ich konnte nicht von der Absicht zur Umsetzung zu meinen eigenen Bedingungen gelangen. Es gab immer eine weitere Abhängigkeit in der Schleife: ein Team, ein Tool oder eine Schnittstelle, die mich nur ein Stück weit brachte.

Das ist der Teil, der sich am meisten verändert hat.

Der Workflow, den ich jetzt verwende

Der einfachste Weg, dies zu erklären, ist Schritt für Schritt, da jeder Teil des Workflows ein anderes Problem löst.

Schritt 0: Wissen, was man bauen will

Offensichtlich. Mit diesen neuen Tools wird deutlich, wer wirklich klar denken kann und wer einen Problembereich auf einer tiefen Ebene versteht.

Schritt 1: Ich fange immer noch in Figma an

Das ist das Erste, was ich lernen musste: KI kann Interface-Code generieren, aber sie kämpft immer noch mit visuellem Urteilsvermögen.

KI kann Layouts generieren, aber sie kämpft immer noch mit visuellem Urteilsvermögen. Die Hierarchie ist oft zu flach, der Abstand zu gleichmäßig, das Ergebnis zu generisch. Also benutze ich Figma für den Teil, der Geschmack erfordert: die wichtigsten Bildschirme, die visuelle Hierarchie, die Stellen, an denen Schliff das Produkt verändert.

Diese Unterscheidung ist wichtig. Figma ist der Ort, an dem ich entscheide, wie sich das Produkt anfühlen soll. Code ist der Ort, an dem ich unter Druck teste, ob es tatsächlich funktioniert.

Schritt 2: Ich benutze Figma Make, um schnell zu einem ersten Entwurf zu gelangen

Sobald ich diesen Ausgangspunkt habe, verwende ich Figma Make, um einen ersten Code-Prototyp zu generieren.

Hier will ich Geschwindigkeit, nicht Perfektion. Figma Make ist hervorragend darin, mich von einem statischen Design zu etwas zu bringen, durch das ich klicken kann. Es gibt mir Schwung. Es ist viel weniger gut darin, ein Produkt durch die unordentliche Mitte zu tragen. Styling driftet ab. Die Iteration verlangsamt sich. Große Änderungen werden umständlich. Das hat mir etwas Wichtiges gesagt. Figma Make ist ein starkes Tool für den ersten Entwurf. Es ist noch nicht der Ort, an dem ich ernsthafte Iterationen durchführen möchte.

Schritt 3: Echte Iteration findet in VS Code mit Claude Code oder GPT Codex statt

Hier beginnt sich der Workflow wirklich anders anzufühlen.

Ich exportiere den generierten Code in VS Code und mache dort mit KI-Codierungstools weiter. Das ist der Punkt, an dem der Prototyp aufhört, eine clevere Demo zu sein, und anfängt, ein Produkt zu werden, das ich formen kann.

Ich verwende hauptsächlich Claude Code und GPT Codex. Claude Code ist oft schneller und generativer. GPT Codex ist langsamer, aber in längeren Sitzungen beständiger. Ich wechsle zwischen ihnen, je nach Problem und, ehrlich gesagt, je nachdem, welches an diesem Tag klarer denkt.

Schritt 4: Ich verwende die Figma MCP-Schleife, um zu beheben, was die KI visuell falsch macht

Wenn der Code funktional richtig, aber visuell falsch ist, gehe ich in den Figma Dev Mode, wähle das falsche Element aus, kopiere den MCP-Prompt und füge ihn in VS Code ein. Das lässt das Modell von der Quelle der Wahrheit aus arbeiten, anstatt von meiner Beschreibung davon.

Es funktioniert nicht jedes Mal perfekt, aber oft genug, um wichtig zu sein. Und noch wichtiger: Es verändert die Art der Aufgabe. Anstatt UI-Details manuell Zeile für Zeile zu korrigieren, überwache ich eine engere Schleife zwischen Designabsicht und Umsetzung.

Schritt 5: Dann teste ich auf dem Gerät, notiere, was kaputt geht, und wiederhole

Von da an wird die Arbeit zu einem Rhythmus: auf dem Gerät testen, sehen, was sich falsch anfühlt, im Code beheben und wiederholen.

Dieser Teil ist wichtiger als jedes Modell. Echte Software sagt schnell die Wahrheit. Scroll-Verhalten, Performance, Ladezustände, umständliche Übergänge – all die Dinge, die ein Mockup verbergen kann, werden offensichtlich, sobald man das Produkt in der Hand hält. Die Schleife ist also einfach: bauen, testen, bemerken, was sich falsch anfühlt, beheben, wiederholen.

Wo das scheitert

Die Erfolgsgeschichten sind real, aber das sind die Fehlermodi auch.

Der erste ist Kontextdegradation. Lange Chats mit Codierungsmodellen können sich produktiv anfühlen, weil es eine sichtbare Arbeitsspur hinter einem gibt. Aber Länge und Kohärenz sind nicht dasselbe. Mit der Zeit verliert das Modell den Überblick darüber, was wichtig ist. Es vergisst Einschränkungen, lässt abgelehnte Ideen wieder auferstehen oder behandelt jede vergangene Anweisung als gleich wichtig. Ich habe gelernt, Threads öfter zurückzusetzen, als es sich intuitiv anfühlt, und die wichtigsten Einschränkungen jedes Mal neu zu formulieren.

Der zweite ist Design-System-Drift. Der Code, den diese Tools produzieren, kann wie die richtige Antwort aussehen, ohne sinnvoll mit dem richtigen System verbunden zu sein. Er ähnelt den Design-Tokens und Komponenten, ohne tatsächlich auf sie zu verweisen. Für die Arbeit allein ist das überschaubar. Für Teams wird es zu einem Übergabeproblem. Die Pipeline vom Design-System zur Umsetzung ist besser als früher, aber sie ist immer noch nicht wirklich geschlossen.

Der dritte ist kognitive Ermüdung. Dies ist vielleicht der am wenigsten diskutierte Teil des Workflows und einer der wichtigsten. KI-unterstütztes Programmieren ist nicht mühelos. Es verschiebt Ihre Rolle. Sie sind gleichzeitig Macher, Prüfer, Redakteur und Qualitätsfilter. Jeder Output durchläuft einen mentalen Checkpoint: Ist das richtig? Ist es vollständig? Ist es auf eine Weise subtil falsch, die mich später etwas kosten wird? Das wiederholt zu tun, ist auf eine sehr spezifische Weise ermüdend. Die Arbeit ist schneller, aber die Wachsamkeit ist real.

Der vierte ist, dass die Tool-Qualität inkonsistent ist. Ich hatte wiederholte Sitzungen, in denen Claude Code während der Spitzenzeiten spürbar an Qualität verlor. Die Outputs werden fauler. Das Denken wird flacher. Die Halluzinationen nehmen zu. Man lernt, das Muster zu erkennen und die Tools zu wechseln, wenn es passiert, aber es ist immer noch eine Einschränkung.

Keines dieser Probleme ist theoretisch. Sie alle treten im normalen Gebrauch auf.

Was das für mich zum Funktionieren gebracht hat

Nach ein paar Monaten, in denen ich auf diese Weise gebaut habe, bin ich bei einer Handvoll Prinzipien gelandet, die wichtiger sind als jedes spezifische Modell.

Die erste Lektion ist, dass Klarheit wichtiger ist als je zuvor. Wenn ich einem Modell eine verschwommene Aufgabe gebe, gibt es eine verschwommene Antwort in einer sehr überzeugenden Verpackung zurück. Bevor ich eine Sitzung beginne, versuche ich, die Arbeit kleiner und definierter zu machen: was ändert sich, was ändert sich nicht, welche Dateien sind beteiligt, welche Randfälle sind wichtig, wie sieht „fertig“ aus. Diese Planung ist kein Overhead. Sie ist Teil des Builds.

Die zweite Lektion ist, dass wiederverwendbare Standards sich summieren. Ich arbeite besser, wenn ich dem Modell eine stabile Betriebsumgebung gebe: Planen vor dem Programmieren, Annahmen benennen, Unsicherheiten kennzeichnen, Umfangsänderungen ansprechen, die Antwort fundiert halten. Wenn ich diese Regeln einmal aufschreibe, muss ich den Prozess nicht jedes Mal neu aufbauen, wenn ich eine neue Sitzung beginne.

Die dritte Lektion ist, dass langweilige Technologie hilft. Modelle sind auf vertrautem Terrain einfach besser. Gut dokumentierte Sprachen, ausgereifte Frameworks und gängige Muster reduzieren das Bluffen. Das ist ein Grund, warum ich immer wieder zu Flutter und Standard-Webtechnologien zurückkehre.

Die wichtigste Lektion betrifft jedoch die Überwachung. Die eigentliche Frage ist fast nie: „Kann das Modell das generieren?“ Das kann es meistens. Die nützlichere Frage ist: „Kann ich erkennen, wann es falsch liegt?“ Die Obergrenze ist nicht nur die Leistungsfähigkeit des Modells. Es ist meine Fähigkeit, das Ergebnis mit genügend Vertrauen zu bewerten, um ihm zu glauben. Ich kann eine Consumer-App mit verständlichem Verhalten und klaren Einschränkungen souverän überwachen. Ich wäre weit weniger zuversichtlich, etwas sicherheitskritisches in einem Bereich zu überwachen, den ich nicht tiefgreifend verstehe. Der limitierende Faktor ist nicht die Vorstellungskraft des Modells. Es ist mein Urteilsvermögen.

Was sich geändert hat

Der Engpass in meiner Arbeit war früher die Ausführung. Ich konnte das Produkt sehen, aber der Weg von der Idee zur funktionierenden Software bedeutete, auf eine Übergabe zu warten oder die Idee durch die Grenzen eines Tools zu zwängen. Jetzt ist der Engpass die Spezifikation. Kann ich das Problem klar genug beschreiben? Kann ich den Geschmack des Designs bewahren, während ich mich schnell bewege? Kann ich die subtile Falschheit erkennen, bevor es ausgeliefert wird?

Das ist ein anderer Job als der, den ich vor einem Jahr gemacht habe. Er erfordert gleichzeitig visuelles Urteilsvermögen, technische Überwachung und klares Denken. Für mich ist diese Kombination kein nettes Extra mehr. Es ist die Arbeit.

Nach sechs Wochen habe ich mehr ausgeliefert, schneller gelernt und bin näher am Produkt geblieben, als ich es in meinem alten Arbeitsablauf getan hätte. Die Kompromisse sind real. Die Gewinne aber auch. Ich sehe mich nicht zurückkehren.