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

Vor ein paar Monaten habe ich ein FlutterFlow-Projekt in Claude Code exportiert. Seitdem habe ich FlutterFlow nicht mehr geöffnet. Das klingt sauberer, als sich die tatsächliche Erfahrung damals anfühlte, was eher der Erkenntnis glich, dass ein Werkzeug, auf das ich mich verlassen hatte, nicht mehr im Mittelpunkt der Arbeit stand.

Mein aktueller Workflow ist grob gesagt Figma zu Figma Make zu VS Code zu Claude Code oder Codex, wobei Figma MCP und Tests auf echten Geräten den Kreis schließen. Die nützliche Änderung ist, dass ich jetzt mehr von der Produktschleife selbst übernehmen kann: die Absicht entwerfen, zu funktionierender Software gelangen, sie unter realen Bedingungen testen und weiter iterieren, während die Idee noch frisch in meinem Kopf ist.

Was ich ausgeliefert habe

Mir ist diese Unterscheidung wichtig, weil die Arbeit für mich nicht mehr theoretisch ist.

Halo ist eine Live-Gute-Nacht-App für Kinder auf iOS und Android, und dieser Workflow hat mir geholfen, den Kauf einzelner Geschichten, die Unterstützung für fünf Sprachen und ein Performance-Refactoring für ältere Geräte in wenigen Wochen auszuliefern. Das war der Punkt, an dem sich KI-Programmierwerkzeuge nicht mehr wie ein interessantes Nebenexperiment anfühlten und Teil meiner normalen Produktpraxis wurden.

Die nützlichere Lektion kam von einem WordPress-Übersetzungs-Plugin, denn die erste Version scheiterte auf teure Weise. Ich richtete ein LLM auf eine WordPress-Codebasis ohne ausreichende Struktur in Bezug auf Kontext, Fehlerbehandlung oder Kostenüberwachung, und es verbrannte stillschweigend $250 an API-Aufrufen, bevor ich das Problem bemerkte. Ich habe das Plugin von Grund auf neu erstellt, die Arbeit auf die offiziellen WordPress-Plugin-Dokumentationen gestützt, den Kontext eingegrenzt und Berichte hinzugefügt. Die zweite Version verarbeitet nun mehr als 5.000 Beiträge in zehn Sprachen mit einem gesperrten Glossar für doktrinäre Begriffe. Das Modell war wichtig, aber die Überwachung war noch wichtiger.

Ein Raum-Visualisierer für Immobilien kam viel schneller voran, weil das Problem konkret war. Die Aufgabe bestand darin, Käufern zu zeigen, wie ein leerer Raum möbliert aussehen könnte, sodass die Produkteinschränkung von Anfang an sichtbar war.

Das Kommentarmodul, das ich für einen gemeinsamen Arbeitsprototypen gebaut habe, war kleiner, aber es fängt denselben Wandel auf eine alltäglichere Weise ein. Ich brauchte Kommentare direkt auf dem Prototyp, also habe ich sie gebaut. Vor ein paar Jahren hätte dieser Satz mehr Leute, mehr Wartezeit oder einen viel gröberen Kompromiss erfordert.

Was Prototyping früher bedeutete

Für den Großteil meiner Karriere passte Prototyping in eine von zwei Kategorien.

Bei Unternehmen wie Meta und Careem bedeutete es normalerweise, in Figma zu designen, Übergabenotizen zu schreiben, den Leuten die Absicht zu erklären und dann darauf zu warten, dass die Entwicklung es baut. Manchmal war das Endergebnis nah am Design. Manchmal nicht. So oder so war die Schleife langsam. Jede Iterationsrunde erforderte Zeit, Koordination und ein wenig Verhandlung.

Für meine eigenen Produkte habe ich FlutterFlow verwendet. Es war schneller, brachte aber immer noch den bekannten Kompromiss von No-Code-Tools mit sich: anfangs Geschwindigkeit, später Reibung. Je spezifischer die Idee wurde, desto mehr kämpfte man mit der Abstraktionsschicht, anstatt das Produktproblem zu lösen. Etwas, das im Code einfach gewesen wäre, konnte im Builder umständlich und zeitaufwendig werden.

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

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

Der Workflow, den ich jetzt nutze

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

Schritt 0: Wissen, was man bauen will

Ich beginne immer noch mit Produktklarheit, bevor ich die Werkzeuge anfasse. KI macht unklares Denken sichtbarer, weil ein verschwommener Prompt als selbstbewusste, polierte, falsche Antwort zurückkommen kann. Bevor ich mit dem Bauen beginne, versuche ich, die Arbeit kleiner und definierter zu machen: Was ändert sich, was bleibt fest, welche Dateien oder Bildschirme sind wichtig, welche Randfälle könnten kaputtgehen und wie sollte das fertige Ergebnis aussehen.

Schritt 1: Ich fange immer noch in Figma an

Figma ist immer noch der Ort, an dem ich das visuelle Denken erledige. KI kann Interface-Code produzieren, aber sie hat immer noch Probleme mit Geschmack: Hierarchie, Abstände, Betonung, Dichte und die kleinen visuellen Entscheidungen, die dafür sorgen, dass sich ein Produkt durchdacht und nicht generiert anfühlt. Ich verwende Figma für die Bildschirme, bei denen das Urteilsvermögen am wichtigsten ist, insbesondere an den Stellen, an denen sich das Produkt ruhig, klar oder poliert anfühlen muss. Code ist der Ort, an dem ich teste, ob diese Absicht den Kontakt mit echtem Verhalten überlebt.

Schritt 2: Ich nutze Figma Make, um schnell zu einem ersten Entwurf zu kommen

Sobald ich den Ausgangspunkt habe, verwende ich Figma Make, um einen ersten Prototyp zu generieren. Ich behandle es als Entwurfswerkzeug, denn da ist es am stärksten. Es bringt mich schnell von einem statischen Bildschirm zu etwas Klickbarem, was mir Schwung gibt und offensichtliche Probleme früher aufdeckt. Ich möchte dort jedoch nicht durch die chaotische Mitte eines Produkts leben. Das Styling kann abdriften, größere Änderungen können umständlich werden und die Iterationsschleife fühlt sich langsamer an, sobald der Prototyp eine stärkere Struktur benötigt.

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

Hier fängt der Workflow an, sich wirklich anders anzufühlen.

Ich exportiere den generierten Code in VS Code und mache von dort aus mit KI-Programmiertools 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 nutze hauptsächlich Claude Code und GPT Codex. Claude Code ist oft schneller und generativer. GPT Codex ist langsamer, aber beständiger in längeren Sitzungen. Ich wechsle zwischen ihnen, je nach Problem und, ehrlich gesagt, je nachdem, welches an diesem Tag klarer denkt.

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

Wenn der Code funktional richtig, aber visuell daneben 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. Dadurch kann das Modell mit der Wahrheitsquelle arbeiten, anstatt mit meiner Beschreibung davon.

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

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

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

Dieser Teil ist wichtiger als jedes Modell. Echte Software sagt schnell die Wahrheit. Scrollverhalten, Performance, Ladezustände, ungeschickte Ü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 Ganze scheitert

Die Erfolgsgeschichten sind real, aber das gilt auch für die Fehlerquellen.

Die erste ist Kontextverlust. Lange Chats mit Programmiermodellen können sich produktiv anfühlen, weil eine sichtbare Spur von Arbeit hinter einem liegt. 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 verworfene Ideen wieder aufleben oder behandelt jede vergangene Anweisung als gleich wichtig. Ich habe gelernt, Threads öfter zurückzusetzen, als es sich intuitiv richtig anfühlt, und die wichtigsten Einschränkungen jedes Mal neu zu formulieren.

Die zweite ist Design-System-Drift. Der Code, den diese Tools produzieren, kann nah an der richtigen Antwort aussehen, ohne sinnvoll mit dem richtigen System verbunden zu sein. Er ähnelt den Design-Tokens und Komponenten, ohne sie tatsächlich zu referenzieren. Für Einzelarbeit ist das machbar. Für Teams wird es zu einem Übergabeproblem. Die Pipeline vom Design-System zur Implementierung ist besser als früher, aber sie ist immer noch nicht wirklich geschlossen.

Die dritte ist kognitive Ermüdung. Dies ist vielleicht der am wenigsten diskutierte Teil des Workflows und einer der wichtigsten. KI-gestütztes Programmieren ist nicht mühelos. Es verschiebt die eigene Rolle. Man ist gleichzeitig Macher, Prüfer, Redakteur und Qualitätsfilter. Jede Ausgabe durchläuft einen mentalen Checkpoint: Ist das richtig? Ist es vollständig? Ist es auf eine subtile Weise 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.

Die vierte ist, dass die Qualität der Tools inkonsistent ist. Ich hatte wiederholt Sitzungen, in denen die Qualität von Claude Code während der Hauptnutzungszeiten spürbar nachließ. Die Ausgaben werden fauler. Die Argumentation 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 bei normaler Nutzung auf.

Was dies für mich zum Funktionieren gebracht hat

Nach ein paar Monaten des Bauens auf diese Weise bin ich bei einer Handvoll Prinzipien gelandet, die wichtiger sind als jedes spezifische Modell.

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

Die zweite Lektion ist, dass wiederverwendbare Standards potenzieren sich. Ich fahre besser damit, wenn ich dem Modell eine stabile Arbeitsumgebung gebe: vor dem Programmieren planen, Annahmen benennen, Unsicherheiten markieren, Änderungen des Umfangs aufzeigen, die Antwort bodenständig halten. Wenn ich diese Regeln einmal aufschreibe, höre ich auf, den Prozess jedes Mal neu aufzubauen, wenn ich eine neue Sitzung öffne.

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 auf Flutter und Standard-Webtechnologien zurückkomme.

Die wichtigste Lektion betrifft jedoch die Überwachung. Die eigentliche Frage lautet fast nie: „Kann das Modell das generieren?“ Meistens kann es das. Die nützlichere Frage ist: „Kann ich erkennen, wenn es falsch ist?“ Die Obergrenze ist nicht nur die Leistungsfähigkeit des Modells. Es ist meine Fähigkeit, die Ausgabe mit genügend Zuversicht zu bewerten, um ihr zu vertrauen. Ich kann eine Verbraucher-App mit verständlichen Verhaltensweisen und Einschränkungen souverän überwachen. Ich wäre weitaus weniger zuversichtlich, etwas Sicherheitskritisches in einem Bereich zu überwachen, den ich nicht tiefgreifend verstehe. Der begrenzende Faktor ist nicht die Vorstellungskraft des Modells. Es ist mein Urteilsvermögen.

Was sich geändert hat

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

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

Nach sechs Wochen habe ich mehr ausgeliefert, schneller gelernt und bin näher am Produkt geblieben, als ich es in meinem alten Workflow getan hätte. Die Kompromisse sind real. Die Gewinne aber auch. Ich kann mir nicht vorstellen, wieder zurückzugehen.