AI-Design-Workflows · 2026 Guide
Du konvertierst Figma gar nicht zu Code. Du designst im falschen Tool zuerst.
Kennst du den Ablauf. Du öffnest Figma. Du baust einen Screen. Du jagst ihn durch Anima oder Builder.io oder Locofy, je nachdem welches Plugin dieses Quartal angesagt ist. Du bekommst einen Ordner React-Komponenten zurück. Du öffnest deinen Editor. Du verbringst die nächsten drei Stunden damit, Inline-Styles zu löschen, Layouts umzubauen, das Component-Library-Mapping wiederherzustellen und die paar Komponenten zu fixen, die das Tool nicht erkannt hat.
Im Jahr 2026 ist dieser Workflow eine Generation zu spät. Der Gewinn-Move ist kein besseres Figma-to-Code-Plugin. Es ist, Figma für den Design-Schritt komplett zu überspringen, sauberes HTML zu exportieren und deinen Coding-Agent (Cursor, Claude Code, Bolt) die Konvertierung in dein ausgeliefertes Framework machen zu lassen. Dieser Artikel zeigt, warum der alte Workflow an seine Grenzen kommt, wie der neue aussieht und wie du ihn heute Nachmittag ausprobieren kannst.
Der aktuelle Figma-to-Code-Workflow, ehrlich
Vor dem Argument, die Würdigung. Tools wie Anima, Builder.io Visual Copilot, Locofy und Figmas eigener Dev Mode mit MCP haben legitim verändert, wie Design an Entwicklung übergeben wird. Für isolierte Komponenten und einfache Marketingseiten funktioniert das. Die Plugin-Szene ist gut geworden.
Das Problem sind nicht die Plugins. Das Problem ist, was du von ihnen verlangst. Du verlangst von einer Konvertierungsebene, ein Tool für visuelle Treue (Figma) in ein Tool für Laufzeitverhalten (Code) zu übersetzen. Diese Übersetzung ist probabilistisch. Jedes echte Projekt trifft die Naht zwischen diesen beiden Welten, wo die Übersetzung leckt.
Die Frage, die sich wirklich lohnt: nicht "welches Plugin leckt am wenigsten?" Sondern "brauche ich diesen Konvertierungsschritt überhaupt?"
Wo Plugin-basiertes Figma-to-Code immer wieder scheitert
Vier Fehlermodi tauchen in fast jedem echten Projekt auf. Keiner davon ist ein Bug, den die Tools einfach fixen können, weil sie der "Figma-Datei konvertieren"-Denke eigen sind.
1. Komponentenerkennung ist probabilistisch
Das Tool muss raten, welche Cluster von Shapes "ein Button" sind und welche zufällig nur nebeneinander liegen. Es verpasst welche. Du bekommst Divs, wo du eine Komponente erwartet hast, und Komponenten, die wiederverwendet hätten werden sollen, stattdessen inline-dupliziert. Die Nacharbeitskosten skalieren mit der Screen-Zahl.
2. Output ist framework-spezifisch und brüchig
Die meisten Plugins geben React aus. Wenn du Vue, Flutter, Svelte, React Native oder PHP ausliefers, übersetzt du zweimal: Figma zu React, dann React zu deinem Stack. Jede Übersetzung verliert Treue. Jede braucht Nacharbeit. Die Marketing-Versprechen "funktioniert für jedes Framework" überleben selten ein echtes Projekt.
3. Auto-Layout mappt selten sauber auf Flexbox und Grid
Figmas Auto-Layout ist ein vereinfachtes Modell von CSS-Layout. Wenn das Tool es konvertiert, bekommst du Output, der technisch valide ist, sich aber nicht verhält wie Code, den ein Mensch schreiben würde. Resizing bricht, Min-Widths driften, Content, der wrappen soll, tut es nicht. Das erste Breakpoint-Audit wird zur Neuschreibung.
4. Design-Tokens werden in Inline-Werte abgeflacht
Deine Figma-Datei hat Farb-Tokens, Type-Scale, Spacing-Tokens. Plugin-Output verliert sie oft und paste Hex-Codes und Pixel-Werte inline. Jetzt ist dein Theming kaputt und jede Farbänderung ist ein 200-Datei-Edit. Das Design-System, das du gebaut hast, überlebt den Handoff nicht.
Einer davon allein ist händelbar. Alle vier zusammen, auf einem 20-Screen-Projekt, ist der Grund, warum "Figma to Code" bei Dev-Teams, die es wirklich versucht haben, zu "Wochenende Nacharbeit" geworden ist.
Der Workflow, der ihn ersetzt
Drei Schritte. Es funktioniert nur, weil beide Hälften, prompt-first Design und agentisches Coding, in den gleichen sechs Monaten richtig gut wurden.
1. Designe in einem prompt-first Tool, nicht in Figma.
Öffne dMaya. Beschreibe, was du brauchst. Die Canvas füllt sich mit einem echten Design, gebunden an ein Design-System, das über jeden weiteren Screen konsistent bleibt. Keine Figma-Datei. Kein Auto-Layout-Übersetzungsproblem. Der Output ist bereits code-strukturiert, weil er von Anfang an mit Code im Sinn gebaut wurde.
2. Exportiere sauberes HTML, nicht React.
Das ist der Move, den die meisten Figma-to-Code-Tools nicht machen können, weil ihre Prämisse ist, dass React der Output ist. dMaya exportiert HTML absichtlich. HTML ist framework-agnostisch, semantisch und die Lingua Franca, die jeder Coding-Agent bereits fließend spricht.
3. Übergib das HTML an deinen Coding-Agent.
Gib Cursor, Claude Code oder Bolt das exportierte HTML plus deinen Projekt-Kontext. Der Agent konvertiert zu React, Vue, Flutter, React Native oder deinem Stack, in Code, der zu deinen Konventionen passt (Komponentenbibliothek, State-Patterns, Ordnerstruktur, Tests). Der Output passt, weil der Agent deine Codebase bereits kennt. Kein Plugin-generierter Code mehr zum Reverse-Engineering.
Das ganze Argument: hör auf, "Figma to Code" als Konvertierungsproblem zu denken. Denk es als Design-Problem und Code-Problem, jeweils vom richtigen Tool gelöst. Design passiert in einem Tool, gebaut für prompt-first Generierung. Code passiert durch einen Agenten, der dein Repo bereits kennt. Der Konvertierungsschritt verschwindet, und das war der Schritt, der von Anfang an leckte.
Wie ein echter Lauf aussieht
Hier dMaya, wie es aus einem Prompt ein Freelancer-SaaS-Dashboard erzeugt, laufend auf Claude Opus 4.7. Zweieinhalb Minuten Ende-zu-Ende. Der Output ist die Canvas, die du siehst, kein Bild einer Canvas. Der Export ist ein Klick.
Wir haben den gleichen Prompt am gleichen Tag gegen Claude Design und Google Stitch laufen lassen. dMaya auf Opus war ca. 4× schneller als Claude Design auf dem gleichen Modell, zu grob einem Zehntel der Kosten pro Lauf. Zahlen und Videos im Same-Prompt-Vergleich.
Alt vs neu, nebeneinander
| Figma + Plugin | dMaya + Coding-Agent | |
|---|---|---|
| Projektstart | Figma-Datei bauen, dann konvertieren | Beschreiben, was du brauchst, Figma überspringen |
| Design-Konsistenz | Abhängig von deiner Figma-Disziplin | Über jeden Screen per Default erzwungen |
| Output-Format | React (meistens); brüchig für andere Stacks | HTML, dann was auch immer dein Agent konvertiert |
| Framework-Flexibilität | Plugin pro Framework wählen | Agent handhabt React, Vue, Flutter, RN, PHP |
| Passt zu deiner Codebase | Generischer Output, braucht Refactoring | Agent kennt bereits deine Konventionen |
| Nacharbeitszeit | Stunden bis Tage pro Screen | Minuten; agent-geformt von Anfang an |
| Kunden-Iterationsschleife | In Figma neu designen, neu konvertieren, neu nacharbeiten | Auf Canvas neu prompten, neu exportieren, fertig |
Was ist, wenn ich schon eine Figma-Datei habe?
Berechtigte Frage. Wenn dein Projekt schon in Figma modelliert ist und du es nicht wegwerfen kannst, ist Plugin-basierte Konvertierung weiterhin der richtige Griff. Anima, Builder.io Visual Copilot und Locofy sind in dieser Reihenfolge die, die wir ausprobieren würden. Figma Dev Mode mit MCP ist anständig, wenn dein Team tief in Figma steckt.
Aber das nächste neue Projekt ist das, das du dir überlegen solltest. Wenn du noch keine Figma-Abhängigkeit hast, wird die Frage nicht mehr "welches Plugin?" Sondern "will ich überhaupt eines?"
Warum das der Workflow ist, der gewinnt
Zwei Dinge sind 2026 passiert, mit denen der alte Workflow nicht gerechnet hat. Erstens: Coding-Agents sind richtig gut geworden darin, framework-spezifischen Code aus einer Spec zu erzeugen. Cursor, Claude Code und Bolt schreiben jetzt Code, der zu den Konventionen eines Projekts besser passt als die meisten fertigen Plugins. Zweitens: prompt-first Design-Tools haben angefangen, produktionsreifen Output zu erzeugen statt Skizzen.
Diese zwei Verschiebungen treffen sich in der Mitte bei sauberem HTML. Das Design-Tool kann es erzeugen. Der Coding-Agent weiß, was damit zu tun ist. Das Plugin, das zwischen ihnen lebte, ist überflüssig.
Teams, die das zuerst merken, liefern schneller aus, iterieren in Echtzeit vor Kunden und hören auf, die Steuer zu zahlen, die jede Figma-to-Code-Konvertierung schon immer kostete. Teams, die es nicht merken, warten weiter auf das nächste Plugin, das das Komponentenerkennungsproblem fixt.
Weiterlesen
- What is vibe design? für die Kategoriedefinition, was es ist und nicht ist, und wie eine echte Session abläuft.
- Vibe coding vs vibe design für wann jedes zu greifen und wann beide im gleichen Projekt.
- Google Stitch vs Claude Design vs dMaya für gleicher Prompt, drei Tools, echte Zeit und Kosten erfasst.
- Wie der dMaya-HTML-Export funktioniert für die Feature-Seite mit Export-Details.
Häufig gestellte Fragen
Überspring das Plugin. Probier den neuen Workflow.
Beschreibe einen Screen. Sieh die Canvas sich füllen. Exportiere HTML. Übergib es deinem Agent.
Start Designing