figmascope vs Locofy
Generierter Code oder strukturierter Kontext?

Locofy macht das Offensichtliche: eine Figma-Datei nehmen, React produzieren. Das ist der natürliche erste Instinkt. Designs rein, Code raus. Warum komplizierter denken?

Hier ist die ehrliche Antwort: Für einige Workflows sollte man nicht komplizierter denken. Locofy ist schnell und real. Aber das Modell hat Grenzen, die sich verstärken, je mehr die Codebase wächst. figmascope setzt auf eine andere Wette — Struktur liefern, den Agenten das Codegen handhaben lassen. Ob sich diese Wette auszahlt, hängt davon ab, was man baut und wer es baut.

Was Locofy macht

Locofy ist ein Figma-Plugin (auch als eigenständige App verfügbar), das Figma-Designs in produktionsähnlichen React-, Next.js-, Vue-, HTML/CSS- oder Tailwind-Code konvertiert. Man installiert das Plugin, taggt Layer mit Locofy-Annotationen (markiert, was ein Input, ein Button, ein Container ist), führt den Export aus und erhält Komponentendateien, die man in ein Projekt einfügen kann.

Es unterstützt responsive Breakpoints, grundlegende Interaktionszustände und etwas Asset-Handling. Der Output soll ein Ausgangspunkt sein, kein finaler Code — aber für einfache Marketing-Seiten oder Landing-Sections kann es 60–80 % des Weges zurücklegen, ohne einen Texteditor zu öffnen.

Locofy hat eine kostenlose Stufe mit begrenzten Exporten und kostenpflichtige Pläne für höheres Volumen und Team-Features. Das Plugin selbst erfordert Installation über die Figma Community und läuft innerhalb von Figmas sandboxed Plugin-Laufzeit.

Wo Locofy gewinnt

Kein Agent erforderlich. Man braucht weder Claude, Cursor noch einen anderen KI-Coding-Assistenten. Die Konvertierung ist in sich abgeschlossen innerhalb des Locofy-Plugins. Für einen Designer, der eine Landing Page ohne Entwicklerbeteiligung ausliefern möchte, kann Locofy diese Lücke schließen.

Schneller erster Output. Für einfache Layouts mit wenigen Komponenten produziert Locofy in Minuten nutzbaren Code. Wenn man prototypiert oder wegwerfbare Marketing-Seiten produziert, ist die Geschwindigkeit real.

Meinungsstarke Struktur. Locofy trifft Entscheidungen für einen: hier ist der Komponentenbaum, so werden Props benannt. Diese Meinungsstärke ist ein Feature, wenn man diese Entscheidungen nicht selbst treffen möchte.

Framework-bewusster Output. Der Code zielt direkt auf den eigenen Stack ab. Man bekommt keine generische JSON, die man dann interpretieren muss — man bekommt eine .tsx-Datei mit Import-Statements, gescaffoldetem Hooks und bereits angewandten CSS-Modules oder Tailwind-Klassen.

Wo Locofy verliert

Einmaliger Schuss, nicht iterativ. Locofy produziert einen Snapshot. Wenn sich das Design ändert — und Designs ändern sich immer — führt man das Plugin erneut aus und gleicht den neuen Output mit der bestehenden Codebase ab. Es gibt kein Diff-Modell. Man mergt Maschinen-Output gegen menschlichen Output von Hand, was schnell teuer wird.

An Locofys Meinungen gebunden. Die Framework-Wahl, die Komponentenbenennungskonventionen, die Prop-Signaturen — diese kommen aus Locofys Modell, nicht aus den Konventionen der eigenen Codebase. Wenn man ein Design-System mit spezifischen Komponenten-APIs hat, weiß Locofy nichts davon. Es generiert seine eigenen. Man verbringt Zeit damit, Locofy-Land mit der eigenen Codebase-Land in Einklang zu bringen.

Plugin-Abhängigkeit. Jeder Entwickler, der einen Export ausführen möchte, braucht das Plugin installiert, ein Locofy-Konto und Zugang zur Figma-Datei. Es passt nicht in einen CLI-Workflow, eine CI-Pipeline oder die Umgebung eines Nicht-Figma-Benutzers.

Annotations-Overhead. Guten Output von Locofy zu bekommen erfordert, dass Designer Locofy-spezifische Tags zu Layern hinzufügen. Das ist Tooling-Schulden: die Annotationen müssen gepflegt werden, fügen der Figma-Datei Lärm hinzu und bedeuten nichts außerhalb von Locofy.

Black Box. Die Codegen-Logik ist proprietär. Wenn der Output falsch ist — und manchmal ist er falsch — kann man nicht sehen warum. Man passt Layer-Namen an, führt erneut aus, hofft. Es gibt keine Intermediate Representation, die man inspizieren oder prüfen kann.

figmascopes anderer Winkel

figmascope generiert keinen Code. Es generiert Kontext.

Das Bundle — CONTEXT.md, tokens.json, screens/*.json, components/inventory.json, strings.json — beschreibt das Design präzise und lässt den gewählten Agenten das Codegen durchführen. Dieser Agent kennt die Codebase, die Komponenten-APIs, die Benennungskonventionen, die Testmuster. Locofy kennt nichts davon. Der Agent tut es, weil er den Code gelesen hat.

Die Intermediate Representation in screens/*.json erfasst Layout-Semantik: stack vs. absolute vs. overlay, Komponentenidentität via componentId auf INSTANCE-Knoten, und Text-Strings via stringRef.key. Wenn man Claude Code sagt "implementiere diesen Screen mit unseren vorhandenen Button- und Input-Komponenten", hat es die räumliche Struktur, die Komponentenreferenzen und die Token-Namen, um das korrekt zu tun. Es schlussfolgert nicht aus einem Screenshot — es liest eine Spezifikation.

Token-Sourcing kaskadiert: Figma-Variablen zuerst (wenn das Design-System verdrahtet ist), aus Häufigkeit abgeleitet zweite (figmascope schaut, welche Werte sich wiederholen und fördert sie), keines wenn beides nicht zutrifft. Der tokens.json-Output ist typisiert und maschinenlesbar. Ein Agent kann color.surface.brand direkt nachschlagen, anstatt einen Screenshot nach einem Hex-Wert zu parsen.

Dieses Modell ist auch iterativ. Wenn sich das Design ändert, exportiert man das Bundle erneut und committet die neue Version. Der Diff in tokens.json oder screens/login.json zeigt genau, was sich geändert hat. Man übergibt den Diff an den Agenten: "tokens.json hat sich geändert — border-radius ging von 8px auf 6px bei allen interaktiven Elementen — betroffene Komponenten aktualisieren." Das ist ein gezielter, diffbarer Workflow. Er erfordert kein Abgleichen zweier generierter Komponentendateien.

Warum "Struktur für einen Agenten" 2026 für viele Teams "Code aus einem Plugin" schlägt

Die Prämisse hinter Locofy — und ähnlichen Tools — ist, dass Codegen aus Design ein gelöstes oder fast gelöstes Problem ist. Code generieren, anpassen, ausliefern. Das funktionierte besser, als der "Anpassen"-Schritt günstig war.

Die Realität 2026: der KI-Coding-Agent ist sehr gut darin, idiomatischen Code in der eigenen Codebase zu schreiben, wenn er guten Kontext hat. Er ist schlecht darin, den eigenen Output mit Locofys Output abzugleichen, wenn sie in Konflikt stehen. Dem Agenten strukturierten, inspizierbaren Kontext zu geben und ihn das vollständige Codegen durchführen zu lassen — in den eigenen Konventionen, gegen die eigenen Komponenten — produziert weniger Abgleicharbeit, nicht mehr.

Locofys Output ist auch framework-final. Sobald man eine JSX-Komponente von Locofy hat, bearbeitet man JSX. figmascopes Output ist framework-neutral. Dasselbe Bundle funktioniert mit Claude Code, der React schreibt, Aider, der Vue schreibt, oder Cursor, der Web Components schreibt. Der Agent wählt das Idiom. Der Kontext bleibt konstant.

Vergleich

Wann Locofy die richtige Wahl ist

Ehrlich gesagt: Locofy verdient seinen Platz für nicht-kodierende Designer, die Marketing-Seiten, Landing-Sections oder wegwerfbare Prototypen ausliefern. Wenn man kein KI-Agenten-Setup hat, keines möchte und einfach eine React-Datei braucht, die man einem Auftragnehmer übergeben kann — Locofy erledigt diesen Job. Der Code ist mittelmäßig, aber er ist da, und mittelmäßiger Code, den man ausliefern kann, schlägt perfekten Kontext, auf den das Team nicht reagieren kann.

Es ist auch genuiner Nutzen für schnelle Mockup-Validierung: "Produziert dieses Layout vernünftiges Markup?" Locofy ausführen, Output anschauen, wegwerfen. Schnelles Feedback ohne einen vollständigen Agenten-Workflow aufzusetzen.

figmascope ist die bessere Wahl, wenn man Produktions-UI mit einer bestehenden Codebase, einem Design-System mit echten Tokens und einem KI-Coding-Agenten in der Schleife baut. Das Bundle gibt dem Agenten die Präzision, die er braucht, um Code zu schreiben, der zum Projekt passt — kein generisches Boilerplate, das neu geschrieben werden muss.