Kontext wird zum Engpass in der KI-gestützten Entwicklung. Nicht die Modellfähigkeit. Modelle verbessern sich schnell genug, dass sie regelmäßig nicht die Einschränkung sind. Was die Qualität von KI-generiertem Code begrenzt, ist die Qualität des Kontexts, den diese Modelle erhalten.
Für Figma-zu-Code-Workflows kommt Kontext in zwei fundamental verschiedenen Formen: Pixel-Kontext (Screenshots, gerenderte Bilder) und strukturierter Kontext (typisiertes IR, Tokens, semantische Beziehungen). Das sind nicht nur verschiedene Formate für dieselbe Information. Es sind verschiedene Kategorien von Input, mit verschiedenen Eigenschaften, verschiedenen Verlustkennzahlen und verschiedenen Obergrenzen für das, was ein Agent daraus produzieren kann.
Die Branche verwendet immer noch größtenteils Pixel-Kontext. Das ist ein Fehler. figmascope exportiert strukturierten Kontext — den richtigen Input von Anfang an.
Was Pixel-Kontext ist
Pixel-Kontext ist jede rasterisierte Darstellung eines Designs: ein aus Figma exportierter Screenshot, ein PNG aus "Frame exportieren", ein Render aus einem Design-Tool. Das ist, was man bekommt, wenn man Cmd+Shift+4 über den Figma-Canvas drückt.
Visionsfähige LLMs können Pixel-Kontext beeindruckend gut verarbeiten. Sie erkennen UI-Muster, identifizieren Layout-Bereiche, schlussfolgern Komponenten-Typen aus dem visuellen Erscheinungsbild und generieren plausiblen Code aus Bildern allein. Wer Claude oder GPT-4V für Screenshot-zu-Code verwendet hat, hat das gesehen. Die Outputs sehen öfter richtig aus, als man erwarten würde.
Aber "sieht richtig aus" und "ist richtig" sind nicht dasselbe, und die Lücke zwischen ihnen ist da, wo Design-System-Compliance, Token-Treue, Komponentenidentität und Reproduzierbarkeit alle leben.
Was strukturierter Kontext ist
Strukturierter Kontext ist eine typisierte, maschinenlesbare Darstellung, die die Semantik des Designs bewahrt: was jedes Element ist, nicht nur wie es aussieht. Er umfasst:
- Typisierte Nodes: jedes Element hat eine Art (
FRAME,TEXT,INSTANCE,VECTOR), die semantische Bedeutung über seine Rolle im Layout trägt - Benannte Werte: Farben sind Token-Referenzen, keine Hex-Strings; Abstände sind Token-Keys, keine Pixelwerte
- Räumliche Beziehungen: Layout-Richtung, Gap, Padding, Ausrichtung — als Eigenschaften erhalten, nicht aus Position abgeleitet
- Identitätslinks: Komponenteninstanzen tragen ihre Quellkomponenten-ID; Strings tragen Querverweisungs-Keys
- Hierarchie: der vollständige Node-Baum, mit intakten Eltern-Kind-Beziehungen
Das figmascope-IR ist das. Jeder Node in einem per-Screen-JSON hat kind, name, absoluteBoundingBox, children, Fills auf Token-Referenzen aufgelöst wo verfügbar, Auto-Layout-Eigenschaften wenn zutreffend, und componentId auf Instanzen. Es ist der Design-Baum explizit gemacht.
Pixel-Kontext sagt einem Agenten, wie ein Design aussieht. Strukturierter Kontext sagt ihm, was ein Design bedeutet. Ein Coding-Agent braucht Bedeutung, um Code zu schreiben, nicht Erscheinungsbild. Erscheinungsbild ist für visuelle Tests.
Was in der Pixel-zu-Struktur-Richtung verloren geht
Der Kernfehler-Modus von Pixel-Kontext ist irreversibler Informationsverlust. Wenn Figma einen Frame zu PNG rendert, verwirft es genau die Information, die am wichtigsten für die Code-Generierung ist:
Der Layer-Baum kollabiert. Es gibt keine "Gruppe von drei Elementen mit 8px Abständen" mehr. Es gibt eine Pixelregion, die eine Gruppe andeutet. Der Agent muss die Baumstruktur aus visuellen Beweisen rekonstruieren, und Rekonstruktion ist approximativ. Sie wird in einem bestimmten Prozentsatz der Zeit falsch sein. Dieser Prozentsatz wächst, je komplexer Designs werden.
Token-Bindungen verschwinden. Der orangefarbene Hintergrund, der auf color/action/primary mappt, wird zu #FF6B00. Der Agent generiert einen hartcodierten Hex. Wenn sich die Farbe jemals ändert, oder wenn Dark Mode unterstützt wird, oder wenn Token-Nutzung geprüft werden muss, ist dieser hartcodierte Wert eine Haftung.
Komponentenidentität ist weg. Vier Instanzen derselben Kartenkomponente sind vier ähnlich aussehende Rechtecke. Der Agent generiert möglicherweise eine wiederverwendbare Komponente oder vier ähnliche-aber-nicht-identische Blöcke, abhängig davon, wie viel strukturelle Ähnlichkeit er ableitet. Man möchte vorhersehbaren Output; man bekommt probabilistischen Output.
Layout-Intention ist mehrdeutig. Ist das eine Flex-Row oder ein Grid? Ist der Abstand zwischen Elementen ein Gap, eine Margin oder Padding auf jedem Element? Die Pixel sagen es nicht. Der Agent wählt. Die Wahlen unterscheiden sich zwischen Läufen.
Die Figma → React-Pipeline, mit und ohne Struktur
Den Pfad von Figma zu Produktions-React betrachten.
Mit Pixel-Kontext: PNG exportieren. In Claude einfügen. JSX bekommen. JSX auf Korrektheit überprüfen. Hartcodierte Werte bemerken. Falsche Komponentenstruktur bemerken. Um Korrekturen bitten. Iterieren. Irgendwann etwas Plausibles bekommen. Manuell bearbeiten, um mit dem Design-System übereinzustimmen. Ausliefern. Nächster Screen: von vorne beginnen, weil die Outputs des vorherigen Laufs nicht komponieren.
Mit strukturiertem Kontext: Bundle exportieren (ein Klick, läuft im Browser). CONTEXT.md + Screen-IR an Claude übergeben mit dem System-Prompt, der Framework und Design-System-Konventionen angibt. JSX bekommen, das die eigenen Token-Namen, Komponentennamen, korrekte Layout-Struktur verwendet. Auf Korrektheit überprüfen. Ausliefern. Nächster Screen: gleiches Bundle, gleicher Agent, komponierbare Outputs, weil die Inputs konsistent sind.
Die Arbeitseinsparungen sind real, aber sekundär. Der primäre Gewinn ist Komponierbarkeit. Strukturierter Kontext ermöglicht Outputs, die über Screens und Agenten hinweg komponieren. Pixel-Kontext nicht — jeder Screen-Output ist eine Insel, die aus einem frischen Inferenz-Durchgang generiert wird.
Struktur bedeutet: typisiert
Jeder Node im IR hat eine kind. Das ist sofort wichtig. Ein TEXT-Node generiert ein Text-Element. Ein FRAME mit Auto-Layout generiert einen Container. Eine INSTANCE von Button/Primary/Large generiert einen Button-Komponenten-Aufruf mit den richtigen Props. Ein VECTOR generiert eine Icon-Referenz.
Der Agent rät nicht. Er mappt Arten auf Code-Primitive. Das Mapping ist in CONTEXT.md für das Ziel-Framework spezifiziert. "Für INSTANCE-Nodes den Komponentennamen verwenden, um die React-Komponente zu bestimmen. Für FRAME mit layoutMode HORIZONTAL eine Flex-Row verwenden. Für TEXT mit Style typography/heading.lg die Heading-Komponente verwenden." Das sind Compiler-ähnliche Regeln, keine Inferenz-Aufgaben.
Struktur bedeutet: räumlich
Die absoluteBoundingBox auf jedem Node gibt Position und Größe im Figma-Koordinatenraum. Kombiniert mit Auto-Layout-Eigenschaften — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — hat der Agent alles, was er braucht, um korrekten Layout-Code ohne Pixel-Zählen zu generieren.
Die absoluten Bounding Boxes ermöglichen dem Agenten auch, seinen Output zu verifizieren: wenn eine generierte Komponente andere Dimensionen hat als im IR angegeben, ist etwas schiefgelaufen. Das ist eine testbare Eigenschaft von strukturiertem Kontext, die kein Äquivalent in Pixel-Kontext hat.
Struktur bedeutet: identitätsbewusst
Wenn vier Nodes im IR eine componentId teilen, weiß der Agent, dass sie Instanzen derselben Komponente sind. Er generiert die Komponentendefinition einmal, leitet Props aus den Varianten in den Instanzen ab und rendert vier Aufrufe. Das ist der korrekte Output. Er ist aus Pixel-Kontext ohne erhebliches Prompt-Engineering nicht erreichbar, das den Agenten im Wesentlichen bittet, Struktur wieder abzuleiten, die die Design-Datei bereits hatte.
String-Querverweise funktionieren genauso. Wenn mehrere Text-Nodes stringRef.key: "action.continue" referenzieren, weiß der Agent, eine einzelne i18n-Abfrage zu verwenden, nicht drei hartcodierte Strings. Die Identitätsinformation ist im IR; der Agent liest sie einfach.
Struktur bedeutet: versionskontrollierbar
Einfache JSON-Dateien differn sauber. Ein geänderter Padding-Wert erscheint als Eine-Zeilen-Änderung im per-Screen-IR. Ein umbenannter Token erscheint als Find-Replace-Diff über die Tokens-Datei. Eine neue Komponenteninstanz erscheint als hinzugefügtes Objekt im Children-Array.
Das ist Design-Versionsgeschichte, die für Ingenieure tatsächlich nützlich ist. Nicht "das Design wurde am Dienstag aktualisiert", sondern "hier sind die drei Eigenschaften, die sich zwischen den v2- und v3-Exporten dieses Screens geändert haben." Das kann in die PR-Beschreibung eingefügt werden. Automatisierte Checks können darauf ausgeführt werden. Es kann verwendet werden, um zu prüfen, ob die Code-Änderung mit der Design-Änderung übereinstimmt.
Wohin das führt: Design-Kontext-Infrastruktur
Die sich hier bildende Tooling-Kategorie ist nicht "Figma-Export, aber besser". Es ist eine neue Schicht im Stack: Design-Kontext-Infrastruktur. Die Aufgabe dieser Schicht ist es, Design-Quelle (Figma-Dateien, Komponentenbibliotheken, Token-Systeme) in strukturierte, agenten-lesbare, versions-kontrollierte Artefakte zu transformieren, die die Code-Generierungs-Schicht speisen.
Diese Schicht sitzt zwischen dem Design-Tool und dem Coding-Agenten. Sie hat Verantwortlichkeiten, die derzeit weder die eine noch die andere Seite besitzt: Snapshot-Management, semantische Extraktion, Token-Auflösung, Komponenteninventar, screen-übergreifende String-Indexierung, Bundle-Versionierung. Das sind Infrastruktur-Belange, keine Design-Tool-Belange und keine LLM-Belange.
Es als Infrastruktur zu behandeln bedeutet: es ist automatisiert, es ist versioniert, es läuft in CI, es hat ein definiertes Format, es ist inspizierbar. Genauso wie ein Build-System Infrastruktur für Code ist — nicht der Code selbst, nicht das Ziel-Binary, sondern die zuverlässige, reproduzierbare Pipeline, die eines in das andere konvertiert.
Ehrlich: Pixels sind immer noch wichtig
figmascope-Bundles enthalten 2×-PNGs jedes exportierten Screens. Nicht weil das PNG die Code-Generierung antreibt, sondern weil visuelle Bestätigung wichtig ist. Ein Agent sollte seinen generierten Output mit dem PNG querverweisen können. Ein Entwickler sollte den Screen anschauen können, ohne Figma zu öffnen. Das PNG ist eine Plausibilitätsprüfung, keine Spezifikation.
Diese Unterscheidung — Pixels für Bestätigung, Struktur für Spezifikation — ist das richtige mentale Modell. Man eliminiert Pixel-Kontext nicht; man degradiert ihn auf seine korrekte Rolle. Es ist das QA-Artefakt, nicht der Build-Input.
Genauso wie man einem Compiler keinen Screenshot des Quellcodes geben würde: man gibt ihm die Quelle, und Screenshots für die Dokumentation verwenden. Die Design-Datei ist die Quelle. Das Bundle ist das Kompilierungsartefakt. Das PNG ist das Dokumentations-Bild.
Wohin das für Multi-Target-Codegen führt
Strukturierter Kontext ermöglicht einen Workflow, den Pixel-Kontext nicht kann: ein Design, mehrere Ziele. Dasselbe IR kann einen React/Tailwind-Generator, einen Jetpack-Compose-Generator und einen SwiftUI-Generator speisen. Das zugrunde liegende Design ist dasselbe; der zielspezifische Kontext (Framework-Primitive, Benennungskonventionen, Layout-APIs) lebt in CONTEXT.md, das pro-Ziel generiert wird.
Das ist Multi-Target-Codegen, das tatsächlich skaliert. Man exportiert ein Bundle aus dem Design. Man führt drei Agenten mit drei verschiedenen CONTEXT.md-Dateien aus. Man bekommt drei Implementierungen, die strukturell äquivalent sind, weil sie aus demselben IR generiert wurden, nicht aus drei separaten Inferenz-Durchgängen über drei Screenshots.
Der Engpass für diesen Workflow ist nicht die Modellfähigkeit. Es ist die Kontext-Qualität. Strukturierter Kontext macht es möglich.
Das strukturierte Kontext-Bundle aus der figmascope-Haupt-App exportieren, dann mit Cursor, Claude Code oder Aider für multi-target, komponierbare UI-Generierung verwenden.