Figma-Agent-Funktionen setzen Designregeln zwischen KI und Canvas
Figma hat neue Figma-Agent-Funktionen vorgestellt, die Teams trotz des unvorhersehbaren Verhaltens der Technologie mehr Kontrolle über KI-Ausgaben geben. Das Release verknüpft Agents innerhalb derselben Plattform mit schriftlichen Spezifikationen, Designbibliotheken, Codequellen und funktionierenden Prototypen.
Es geht um mehr als einen weiteren Assistenten mit zusätzlichen Befehlen. Figma versucht, die Betriebsumgebung rund um Agents zu definieren, bevor generierte Interfaces sich in Produktteams verbreiten. Das Unternehmen setzt darauf, dass gemeinsamer Kontext, sichtbare Arbeit und durchsetzbare Designregeln wichtiger sind als uneingeschränkte Generierung.
Diese Position platziert Figma zwischen Designerinnen und Designern sowie externen Coding-Agents wie Claude Code, Codex, GitHub Copilot und Cursor. Statt nur über Modellleistung zu konkurrieren, will Figma seine Canvas zur Steuerungsebene machen, auf der Teams entscheiden, was Agents bauen sollen.
Die neuen Figma-Agent-Funktionen definieren die Regeln vor der Generierung
Figma verlagert die Steuerung von Agents von individuellen Prompts in eine gemeinsame Produktinfrastruktur.
Das Unternehmen kündigte den erweiterten Workflow bei seinem ersten Config-Event in Indien an. Die zentrale Ergänzung ist Figma Specs, ein Markdown-basierter Arbeitsbereich zur Dokumentation von Produktanforderungen, Entscheidungen, Referenzen und technischem Kontext.
Eine Spezifikation kann als eigene Figma-Datei oder neben der Arbeit auf der Canvas liegen. Teams können Designs, FigJam-Diagramme, Code-Ebenen und andere Materialien referenzieren, ohne alles auf losgelösten Text zu reduzieren.
Diese Struktur ist wichtig, weil ein Agent nur selten allein an schwacher Sprachgenerierung scheitert. Häufig fehlen ihm die Beziehungen zwischen einer Anforderung, einer visuellen Komponente, einer Code-Implementierung und einer früheren Teamentscheidung.
Eine herkömmliche Markdown-Datei kann diese Beziehungen beschreiben, erhält sie aber nicht automatisch. Links veralten, Bilder verlieren ihren Kontext, und unterschiedliche Dateien können widersprüchliche Anweisungen enthalten.
Figma Specs soll diese Verbindungen nativ machen. Laut der Launch-Übersicht des Unternehmens können Teams grobe Ideen in detaillierte Spezifikationen überführen und sie über Figmas MCP-Server an Coding-Agents weitergeben.
Model Context Protocol, kurz MCP, ist ein Standard, mit dem KI-Systeme externe Werkzeuge und strukturierten Kontext anbinden können. In Figmas Umsetzung kann es Produktinformationen zwischen der Canvas und unterstützten Entwicklungs-Agents übertragen.
Der Workflow beginnt, bevor ein Agent Code schreibt. Ein Team kann Anforderungen, Diagramme, Designreferenzen und Codekontext innerhalb einer Spezifikation zusammenstellen und dieses Material dann bei der Generierung verwenden.
Derselbe Kontext kann eine Code-Ebene unterstützen, also einen interaktiven Prototypen, der durch laufenden Code auf der Figma-Canvas gestützt wird. Dadurch lässt sich der Prototyp neben den Designs und Entscheidungen prüfen, aus denen er entstanden ist.
Figma hat außerdem die Informationen erweitert, die über Designsysteme verfügbar sind. Teams können veröffentlichten Bibliotheken schriftliche Richtlinien hinzufügen und Codequellen aus GitHub-Repositories oder npm-Paketen anbinden.
Richtlinien können Regeln, bevorzugte Muster, unzulässige Gestaltungen und Implementierungsdetails dokumentieren. Agents können dieses Material lesen, wenn eine relevante Bibliothek aktiviert ist.
Codequellen fügen eine weitere Ebene der Verankerung hinzu. Sie geben einem Agent Zugriff auf implementierte Komponenten, statt ihn zu zwingen, jedes Interface-Element aus Screenshots oder visuellen Frames abzuleiten.
Diese Kombination schafft eine Kontexthierarchie. Spezifikationen beschreiben, was ein Team bauen will, Designbibliotheken definieren dessen visuelle Sprache, und Codequellen zeigen, wie Elemente in Software funktionieren.
Die Agent-Ankündigung hob außerdem die zentralisierte Verwaltung von Designbibliotheken, Codebibliotheken und Richtlinien hervor. Figma zufolge können Agents dieses System beim Erstellen oder Bearbeiten von Arbeit konsultieren.
Diese Kontrollen adressieren ein wiederkehrendes Problem generativer Interfaces. Ein Modell kann einen überzeugenden Bildschirm erzeugen und dennoch die Komponentenregeln, Interaktionsmuster oder Barrierefreiheitspraktiken einer Organisation ignorieren.
Ein poliertes Ergebnis ist nicht zwangsläufig ein valides Produktergebnis. Es kann korrekt aussehen und dennoch doppelte Komponenten, nicht unterstützte Zustände oder Implementierungsarbeit erzeugen, die Entwickler später ersetzen müssen.
Figmas Antwort besteht nicht darin, Prompts abzuschaffen. Vielmehr werden Prompts mit dauerhaftem Kontext umgeben, der dem Team gehört und nicht der Person, die einen Chat startet.
Dadurch verändert sich die Rolle des Prompts selbst. Er wird zu einer Anfrage innerhalb eines kontrollierten Arbeitsbereichs und nicht zur einzigen Anweisung zwischen einem Agent und dem Produkt.
Figma Code Layers bringen laufende Software auf die Canvas
Figma Code Layers machen die Canvas zu einem Ort, an dem Verhalten getestet wird, nicht nur visuelle Darstellungen geprüft werden.
Code Layers wechselten mit dem Release von der geschlossenen in die offene Beta. Figma zufolge wird die Funktion schrittweise in allen Tarifen eingeführt, wobei einzelne Konten zu unterschiedlichen Zeitpunkten Zugriff erhalten können.
Eine Code-Ebene enthält ein funktionierendes Interface, das durch laufenden Code gestützt wird. Teams können sie neben herkömmlichen Design-Frames platzieren, duplizieren, unterschiedliche Ansätze testen und interaktive Zustände prüfen.
Der Unterschied ist wichtig. Traditionelle Prototypen können einen Pfad durch verknüpfte Frames simulieren, stellen aber möglicherweise nicht das Verhalten einer realen Komponente dar.
Eine laufende Implementierung kann Ladeverhalten, leere Zustände, Fehler, responsive Layouts und komplexe Interaktionen sichtbar machen. Diese Details legen oft Produktfragen offen, die statische Bildschirme ungelöst lassen.
Der Leitfaden zu Code Layers beschreibt mehrere Einstiegspunkte. Nutzer können eine Ebene über den Figma-Agent generieren, ein Design konvertieren, Code importieren oder mit einer bestehenden Team-Codebasis beginnen.
Eine Designerin oder ein Designer könnte einen etablierten Checkout-Ablauf auswählen und den Agent bitten, eine alternative Lieferoption hinzuzufügen. Die resultierende Code-Ebene könnte Validierung, Laden sowie Erfolgs- und Fehlerverhalten zeigen.
Das Team könnte diese Version anschließend duplizieren und daneben eine weitere Interaktion testen. Produktmanager, Designer und Ingenieure würden funktionierende Optionen in einer gemeinsamen Datei vergleichen.
Figma zufolge können Änderungen zurück in die Code-Ebene und in unterstützten Workflows auch in die angebundene Codebasis fließen. Dieses Versprechen ist folgenreicher als ein einfacher Design-zu-Code-Export.
Ein Export ist meist ein Übergabeartefakt. Eine angebundene Code-Ebene soll Teil eines iterativen Kreislaufs zwischen Designexploration und Implementierung bleiben.
Figma führte Code Layers erstmals im Juni 2026 in einer geschlossenen Beta ein. Die frühere Canvas-Vorschau unterstützte GitHub-Importe, lokale Ordner, Vorlagen, Figma Make-Ausgaben und von Agents generierte Ausgangspunkte.
Die offene Beta bringt dieses Modell zu einem breiteren Publikum. Sie schafft zugleich einen größeren Test dafür, ob codegestützte Zusammenarbeit außerhalb sorgfältig ausgewählter Teams funktioniert.
Der unmittelbare Anwendungsfall besteht nicht darin, generierten Code automatisch auszuliefern. Es geht darum, Code günstig genug zu machen, um ihn bei der Produktfindung einzusetzen.
Figma Chief Design Officer Loredana Crisan beschrieb eine wachsende Lücke zwischen Codeerstellung und tatsächlichen Releases. Gegenüber TechCrunch sagte sie, Unternehmen produzierten 17-mal mehr Code, während die Zahl der Releases nur um das 1,3-Fache gestiegen sei.
Diese Zahlen stammen vom Unternehmen und sollten nicht als unabhängiger Branchenbenchmark behandelt werden. Dennoch erklären sie die Strategie hinter Figma Code Layers.
Generierter Code wird zunehmend genutzt, um Möglichkeiten zu erkunden, die nie die Produktion erreichen. Figma will, dass diese explorative Arbeit dort stattfindet, wo Teams sie gemeinsam sehen, diskutieren und verfeinern können.
Dadurch wird Code von einem Medium der finalen Implementierung zu einem Designmaterial. Produktteams können funktionierende Software nutzen, um zu klären, was sie bauen sollten, bevor sie sich auf eine Produktionsarchitektur festlegen.
Der Ansatz erkennt auch an, dass terminalbasierte Agent-Sitzungen oft schwer zu teilen sind. Ein Entwickler kann mehrere Interfaces schnell generieren, doch Mitarbeitende erhalten danach möglicherweise nur einen Link oder eine Aufzeichnung.
Dieser Prozess verbirgt die Alternativen, Prompts und Abwägungen hinter dem Ergebnis. Eine funktionierende Version auf die Canvas zu bringen, macht die Exploration sichtbar und leichter hinterfragbar.
Sichtbarkeit macht Prototyp-Code jedoch nicht produktionsreif. Teams benötigen weiterhin Engineering-Reviews, Tests, Sicherheitskontrollen, Barrierefreiheitsvalidierung und wartbare Architektur.
Der Wert von Code Layers hängt daher davon ab, wie Teams ihre Ergebnisse einordnen. Als exploratives Artefakt eingesetzt, können sie Feedbackschleifen verkürzen, ohne vorzutäuschen, dass generierte Prototypen fertige Software sind.
Der eigentliche Wettbewerb lautet gemeinsamer Kontext gegen isolierte Agent-Chats
Figma setzt darauf, dass kontrollierter Kontext wichtiger wird als der Agent, der den schnellsten ersten Entwurf generiert.
Der wichtigste Gegner in dieser Geschichte ist nicht ein anderer Designanbieter. Es ist der isolierte Agent-Workflow, der Produktarbeit in privaten Chats, Terminals oder getrennten Browser-Sitzungen platziert.
Coding-Agents generieren bereits Interfaces aus Text und Bildern. Ihre Geschwindigkeit schafft ein neues Koordinationsproblem, wenn alle Beteiligten mit unterschiedlichen Anweisungen und lokalem Kontext arbeiten.
Ein Designer kann die neueste Komponentenbibliothek anhängen. Ein Entwickler verwendet möglicherweise einen älteren Repository-Branch, während ein Produktmanager Anforderungen bereitstellt, die aus einem separaten Dokument kopiert wurden.
Jeder Agent kann eine plausible Antwort liefern. Die Ergebnisse können dennoch widersprüchlich sein, weil die Systeme nie dieselbe Quelle der Wahrheit erhalten haben.
Figma Specs versucht, diese Fragmentierung zu verringern, indem es dem Kontext einen sichtbaren Ort gibt. Anforderungen bleiben nahe bei den Diagrammen, Designs, Code-Ebenen und Entscheidungen, auf die sie sich beziehen.
Die Erweiterung des Designsystems geht ein verwandtes Problem an. Figma will, dass Agents nicht nur verfügbare Komponenten verstehen, sondern auch die Regeln für ihren Einsatz.
Eine Bibliothek kann mehrere Button-Varianten enthalten, ohne zu erklären, welche davon zu einer destruktiven Aktion gehört. Richtlinien können diese fehlende Entscheidungslogik liefern.
Ebenso kann Zugriff auf Codequellen einem Agent zeigen, ob eine Komponente bereits existiert. Das kann die Versuchung verringern, einen visuell ähnlichen Ersatz mit inkompatiblem Verhalten zu generieren.
Figmas bestehender Agent unterstützt inzwischen die Suche über Dateien hinweg, das Anhängen von Plattforminhalten, das Referenzieren von Bibliothekselementen und das parallele Ausführen mehrerer Prompts. Die Agent-Dokumentation unterscheidet außerdem zwischen dem integrierten Agent und externen MCP-Clients.
Der integrierte Agent arbeitet direkt in Design-Dateien. Externe Agents können Figmas Write-to-Canvas-Funktionen nutzen, um Inhalte aus Codebasen oder anderen KI-Projekten in die Plattform zu bringen.
Diese Unterscheidung erlaubt Figma, mehrere Agents zu unterstützen, ohne von einem Assistenten zu verlangen, jede Aufgabe zu übernehmen. Das Unternehmen kann die gemeinsame Ebene unter einer sich wandelnden Gruppe von Modellen und Entwicklungstools bleiben.
Die MCP-Unterstützung umfasst laut Unternehmen inzwischen mehr als 20 neue Partner. Zur angekündigten Liste gehören OpenCode, Dia, Meta Muse und das indische KI-Startup Sarvam.
Figma hatte bereits Claude Code, Codex, GitHub Copilot und Cursor als Beispiele für externe Agents genannt, die in Dateien schreiben können. Die erweiterte Partnerunterstützung macht Modellneutralität zu einem Teil der Plattformstrategie.
Das ist eine vertretbare Position, weil sich Modellrankings schnell ändern. Ein Team kann einen Agent für Interface-Code und einen anderen für Recherche, Dokumentation oder Bildgenerierung bevorzugen.
Figma muss nicht jeden Modellvergleich gewinnen, wenn es den gemeinsamen Produktkontext kontrolliert. Entscheidend ist, dass Agenten Figmas Dateien, Bibliotheken und Regeln als maßgebliche Eingaben behandeln.
Das MCP-Canvas-Update des Unternehmens macht diesen Anspruch deutlich. Skills können externe Agenten anweisen, wie sie Workflows ausführen, Schritte sequenzieren und Teamkonventionen befolgen sollen.
Ein Skill ist hier ein wiederverwendbares Set von Anweisungen, das das Verhalten eines Agenten prägt. Es kann operatives Wissen kodieren, das sonst in der Prompt-Historie einzelner Mitarbeitender verborgen bliebe.
Ein Design-System-Team könnte einen Skill zum Erstellen von Formularen entwickeln. Die Anweisungen könnten freigegebene Feldkomponenten, barrierefreie Beschriftungen, dokumentierte Validierungszustände und bestimmte Spacing-Tokens vorschreiben.
Ein externer Coding-Agent könnte diese Regeln dann beim Erstellen oder Aktualisieren von Assets anwenden. Figmas Canvas würde die resultierende Arbeit dort zeigen, wo das gesamte Team bereits zusammenarbeitet.
Das ähnelt einer strukturierten technischen Wissensdatenbank, doch der Kontext ist direkt an Produktartefakte gebunden. Der Unterschied liegt darin, wo Entscheidungen in konkrete Handlungen übergehen.
Der entstehende Wettbewerb dreht sich daher um Orchestrierung. Designtools, Code-Editoren, Repositories und Dokumentationssysteme wollen allesamt der Ort werden, an dem Agenten vertrauenswürdigen Kontext erhalten.
Figma hat einen Vorteil, weil viele Entscheidungen zur Benutzeroberfläche bereits auf seinem Canvas liegen. Dieser Vorteil besteht jedoch nur, wenn die Plattform diese Entscheidungen mit dem Produktionscode synchron hält.
Vorhersehbare Agenten sind weiterhin von unvollständigen Eingaben abhängig
Figma kann das Verhalten von Agenten einschränken, aber nicht garantieren, dass jede Regel vollständig, aktuell oder korrekt interpretiert ist.
Das Unternehmen führt diese Kontrollen ein, weil generative KI weiterhin nicht deterministisch ist. Dieselbe Anfrage kann über mehrere Durchläufe hinweg unterschiedliche Strukturen, Details und Implementierungsentscheidungen hervorbringen.
Leitlinien können diese Varianz eingrenzen. Sie können sie nicht beseitigen, insbesondere wenn Anweisungen einander widersprechen oder eine neue Situation nicht abdecken.
Ein Team könnte einem Agenten vorgeben, eine bevorzugte Komponente zu verwenden, während das angebundene Repository zwei Implementierungen enthält. Die Designbibliothek kann eine Version ausweisen, doch der Produktionscode könnte von einer anderen abhängen.
Spezifikationen schaffen eine weitere Wartungsverpflichtung. Eine gut strukturierte Spezifikation hilft nur dann, wenn ihre Anforderungen die aktuellen Entscheidungen widerspiegeln.
Veralteter Kontext kann dazu führen, dass ein Agent dauerhaft falsch liegt. Dieses Versagen ist gefährlicher als eine offensichtliche Halluzination, weil das Ergebnis geregelt und vertrauenswürdig wirken kann.
Design-System-Teams werden klare Zuständigkeiten für Agentenanweisungen benötigen. Sie müssen festlegen, wer Leitlinien veröffentlichen, Codequellen anbinden, Konflikte lösen und Änderungen freigeben darf.
Figma stellt eine zentralisierte Design-System-Verwaltung mit Maps und Systemprüfungen als Vorschau vor. Diese Werkzeuge sollen Abhängigkeiten und Lücken sichtbar machen, einschließlich fehlender Beschreibungen oder Interaktionszustände.
Diese Verwaltungsebene ist notwendig, weil der Zugriff von Agenten die Folgen schwacher Systemdokumentation verstärkt. Für Menschen war es früher schwieriger, eine undokumentierte Komponente korrekt zu verwenden.
Jetzt kann ein Agent das Missverständnis innerhalb von Minuten über viele Bildschirme hinweg reproduzieren. Schnellere Generierung verstärkt sowohl gute Standards als auch vernachlässigte.
Die Zugriffskontrolle wirft ein weiteres Problem auf. Die Anbindung von Agenten an Designs, Spezifikationen, Repositories und externe Dienste erweitert die Angriffsfläche mit proprietären Produktinformationen.
Figma sagt, dass die MCP-Funktion von seinen Sicherheits- und Zuverlässigkeitskontrollen profitiert. Enterprise-Teams werden dennoch Berechtigungen, Datenaufbewahrung, verbundene Clients und Repository-Zugriffe prüfen müssen.
Die Plattform ermöglicht Administratoren, KI-Funktionen zu deaktivieren, doch die verfügbaren Kontrollen könnten für einige Organisationen zu grob sein. Laut Figmas Support-Dokumentation kann das Deaktivieren von Code-Layern auch andere KI-Funktionen deaktivieren.
Teams könnten granularere Richtlinien nach Projektsensibilität, Repository, Modellanbieter oder Nutzerrolle wünschen. Die Wirksamkeit der Governance wird davon abhängen, wie sich diese Kontrollen entwickeln.
Auch die Akzeptanz bleibt unsicher. Designer könnten codegestützte Exploration schätzen, ohne Agentenanweisungen pflegen oder importierte Repositories diagnostizieren zu wollen.
Entwickler könnten generierten Strukturen widerstehen, die überzeugend aussehen, aber mit der etablierten Architektur kollidieren. Produktmanager könnten detaillierte Spezifikationen erstellen, die zu einem weiteren synchronisationsbedürftigen Dokument werden.
Frühe Diskussionen unter Nutzern haben bereits Fragen zu Repository-Importen, Infrastrukturfehlern und dazu aufgeworfen, ob KI-Funktionen von seit Langem bestehenden Produktwünschen ablenken. Diese Einzelberichte belegen keine allgemeine Produktqualität.
Sie zeigen jedoch, was die offene Beta testen muss. Figma muss nachweisen, dass Code-Layer mit realen Repositories und alltäglichen Teamvorgaben zuverlässig funktionieren.
Die Plattform steht zudem vor einem konzeptionellen Risiko. Die Verbindung von Anforderungen, Design, Code, Inhalten und Agentenkontrollen kann Fragmentierung reduzieren, Figma selbst jedoch auch komplexer machen.
Ein gemeinsamer Canvas funktioniert, wenn jede beteiligte Person den relevanten Zustand verstehen kann, ohne jedes zugrunde liegende System beherrschen zu müssen. Zu viele überlappende Oberflächen würden das Koordinationsproblem innerhalb eines Produkts neu erzeugen.
Figmas Behauptungen zu hochwertigerer, markenkonformer Generierung benötigen ebenfalls unabhängige Belege. Das Unternehmen hat gezeigt, wie Kontext in den Workflow einfließt, nicht jedoch, wie konsequent Agenten ihm folgen.
Teams sollten Ergebnisse messen, statt sie vorauszusetzen. Nützliche Kennzahlen sind die Wiederverwendung von Komponenten, Barrierefreiheitsmängel, Nacharbeit, Prüfzeit und Abweichungen zwischen Prototypen und Produktionscode.
Die zentrale Frage ist nicht, ob ein Agent einen attraktiven Bildschirm generieren kann. Es geht darum, ob dieser Bildschirm dem Kontakt mit einem realen Design-System und einer realen Codebasis standhält.
Figma Specs erweitert die Plattform über Designdateien hinaus
Specs macht Figmas Agentenstrategie zu einem umfassenderen Versuch, Produktentscheidungen vor und nach dem Canvas zu prägen.
Eine Produktspezifikation lag traditionell in einem Dokumententool, Ticketsystem oder Repository. Visuelle Arbeit wechselte anschließend zu Figma, während die technische Umsetzung andernorts erfolgte.
Jeder Übergang schuf einen Übersetzungsschritt. Anforderungen konnten Nuancen verlieren, Designs von genehmigtem Verhalten abweichen und Entwickler unvollständige Übergabenotizen unterschiedlich interpretieren.
Figma Specs stellt diese Trennung infrage. Es behandelt Markdown als flexibles Medium, während es zugleich in Figmas Netzwerk visueller und technischer Artefakte eingebettet wird.
Ein Produktmanager kann eine Anforderung entwerfen und auf ein FigJam-Diagramm verweisen. Ein Designer kann relevante Bildschirme verknüpfen, während ein Entwickler Code-Kontext aus GitHub ergänzt.
Ein Agent kann das kombinierte Material dann verwenden, um einen Code-Layer zu erstellen oder die Spezifikation über MCP zu übertragen. Die Spezifikation wird zu einer aktiven Eingabe statt zu einem Dokument, das nur von Menschen geprüft wird.
Das erweitert Figmas adressierbaren Workflow. Die Plattform beschränkt sich nicht länger darauf, Interface-Designs zu erstellen und an Entwicklungsteams zu übergeben.
Sie will an Produktdefinition, Prototyping, Implementierungskontext und Content-Operationen mitwirken. Jede zusätzliche Oberfläche macht den gemeinsamen Kontext für Agenten wertvoller.
Figmas Payload-Integration unterstreicht diese Richtung. Payload ist ein Open-Source-Headless-Content-Management-System, das 2025 zu Figma kam.
Die neue Integration verbindet Payload mit Figma Make, dem promptbasierten Builder der Plattform für Anwendungen und Websites. Teams können datengestützte Erlebnisse erstellen und Inhalte verwalten, ohne den visuellen Prototypen von seinem Inhaltsmodell zu trennen.
Figma zufolge haben sich die Payload-Downloads in den vorherigen zwölf Monaten versechsfacht. Das ist eine vom Unternehmen gemeldete Kennzahl und zeigt nicht, wie viele Projekte die neue Integration nutzen.
Dennoch adressiert die Kombination eine praktische Einschränkung generierter Websites. Eine hochwertige Seite ist weniger nützlich, wenn Inhalte fest im Code verankert bleiben oder nicht mit Publishing-Workflows verbunden sind.
Payload stellt Content-Speicher, APIs, Workflows und eine Verwaltungsoberfläche bereit. Figma sagt, dass Marketingteams Inhalte verwalten können, während Entwickler Zugriff auf das Open-Source-Framework behalten.
Dadurch wird auch die Unterscheidung zwischen Bauen zum Erkunden und Bauen zum Ausliefern geschärft. Ein wegwerfbarer Prototyp benötigt nur genug Verhalten, um eine Idee zu testen.
Eine Produktionswebsite benötigt persistente Inhalte, Berechtigungen, Datenstrukturen und operative Workflows. Die Integration eines CMS rückt Figma Make näher an diese zweite Kategorie.
Das Unternehmen achtet darauf, einen Ausstiegspfad zu bewahren. Es sagt, Teams könnten ihre auf Payload basierende Arbeit aus Figma herausführen, was für Entwickler wichtig ist, die Plattformbindung befürchten.
Die Portabilität muss jedoch anhand tatsächlicher Projekte bewertet werden. Exportierbarer Code ist nicht automatisch leicht wartbar ohne die Umgebung, die ihn erzeugt hat.
Die umfassendere Strategie setzt mehrere Kategorien gleichzeitig unter Druck. Dokumententools hosten Spezifikationen, Coding-Agenten erzeugen Implementierungen und Website-Builder kombinieren visuelle Bearbeitung mit Deployment.
Figma ersetzt sie nicht alle durch ein einziges Modell. Es versucht, zum gemeinsamen Untergrund zu werden, auf dem ihre Ergebnisse zusammenlaufen.
Dieser Ansatz passt zum bestehenden Kollaborationsmodell des Unternehmens. Figma wurde für Produktteams zentral, weil Dateien gemeinsames Bearbeiten in Echtzeit, Kommentare, Komponenten und gemeinsame Bibliotheken unterstützten.
Agenten bringen eine neue Art von Beteiligten hinzu. Anders als menschliche Mitwirkende können sie große Bereiche schnell verändern und über maschinenlesbare Schnittstellen hinweg arbeiten.
Die Plattform muss daher sowohl Zusammenarbeit als auch Begrenzungen unterstützen. Sie muss Agentenarbeit sichtbar machen und zugleich einschränken, wie weit sich eine falsche Anweisung verbreiten kann.
Figma Specs, Codequellen und Leitlinien sind separate Funktionen, doch ihr Wert verstärkt sich, wenn sie gemeinsam eingesetzt werden. Jede adressiert einen anderen Teil des Kontextproblems.
Specs erklären die Absicht. Bibliotheken bilden wiederverwendbare Designentscheidungen ab, während Codequellen diese Entscheidungen in der Implementierung verankern.
Code-Layer bieten einen ausführbaren Ort, um das Ergebnis zu testen. MCP verbindet diesen Prozess anschließend mit Agenten, die anderswo arbeiten.
So funktionieren Figma-Agenten im entstehenden Modell des Unternehmens. Sie erhalten nicht einfach einen Prompt und erzeugen einen Bildschirm.
Sie arbeiten innerhalb einer Kette aus Produktkontext, gemeinsamen Regeln, funktionierenden Artefakten und menschlicher Prüfung. Diese Kette ist die Produktstrategie.
Drei Signale werden zeigen, ob Figmas Agentenstrategie funktioniert
Der nächste Test besteht darin, ob gesteuerte Agenten-Workflows reale Teamergebnisse verbessern, ohne eine weitere Wartungsebene hinzuzufügen.
Das erste Signal ist die Akzeptanz von Code-Layern nach dem Rollout der offenen Beta. Zugang allein belegt noch keinen Wert.
Teams müssen wiederholt laufende Prototypen auf dem Canvas erstellen, duplizieren, prüfen und verfeinern. Eine fortgesetzte Nutzung würde nahelegen, dass codegestützte Exploration ein reales Kollaborationsproblem löst.
Die nützlichsten Belege würden Workflows vor und nach der Einführung vergleichen. Kürzere Prüfzyklen, weniger Überarbeitungen bei der Übergabe oder eine bessere Darstellung interaktiver Zustände würden Figmas These stützen.
Aufgegebene Importe, unzuverlässige Ausführung oder häufige Neuerstellung in externen Tools würden sie schwächen. Die offene Beta gibt Figma eine größere Nutzerbasis, um diese Probleme zu finden.
Das zweite Signal ist, ob Designleitlinien und Codequellen Agentenfehler reduzieren. Teams sollten eine stärkere Wiederverwendung freigegebener Komponenten und weniger Abweichungen bei Marke oder Implementierung beobachten.
Figmas Release Notes vom Oktober bestätigen, dass der Agent Bibliotheksleitlinien lesen, Dateien durchsuchen, Plattformkontext anhängen und benutzerdefinierte Skills unterstützen kann. Diese Fähigkeiten etablieren den Mechanismus, nicht das Ergebnis.
Die entscheidenden Belege werden aus wiederholter Nutzung in der Produktion stammen. Ein erfolgreiches System sollte Agenten helfen, Konventionen zu befolgen, ohne dass Nutzer sie in jedem Prompt erneut formulieren müssen.
Sie sollte außerdem Konflikte sichtbar machen. Wenn die Designbibliothek und das Code-Repository widersprüchliche Angaben enthalten, muss das System Teams dabei helfen zu erkennen, welche Quelle maßgeblich ist.
Andernfalls kann zusätzlicher Kontext die Mehrdeutigkeit erhöhen. Ein Agent kann mehr Informationen erhalten und zugleich unsicherer werden, welcher Anweisung er folgen soll.
Das dritte Signal ist die Entwicklung externer Agent-Unterstützung. Figmas Plattformargument gewinnt an Stärke, wenn Teams Modelle wechseln können, ohne ihren Designkontext neu aufbauen zu müssen.
Die Unterstützung weiterer MCP-Clients schafft Verbreitung, doch die Kompatibilität muss über grundlegenden Schreibzugriff hinausgehen. Externe Agenten benötigen zuverlässigen Zugriff auf Komponenten, Variablen, Richtlinien, Bilder und Code-Zusammenhänge.
Figma hat erklärt, dass es auf eine umfassendere Gleichwertigkeit mit seiner Plugin API hinarbeitet. Der Fortschritt dabei wird darüber entscheiden, ob externe Agenten zu vollwertigen Mitarbeitenden oder zu begrenzten Importwerkzeugen werden.
Auch die Reaktion des Wettbewerbs wird eine Rolle spielen. Code-Editoren und Entwicklungsplattformen können ihre eigenen Designintegrationen vertiefen, während Dokumentsysteme Spezifikationen besser für Agenten lesbar machen können.
Wenn diese Werkzeuge Kontext bewahren, ohne die Arbeit über Figma zu leiten, könnten Teams einen verteilten Workflow bevorzugen. Figma muss beweisen, dass Konsolidierung zu klareren Entscheidungen führt und nicht nur zu größerer Plattformabhängigkeit.
Für Designer lautet die praktische Frage, ob die Arbeitsfläche ein Ort für Urteilskraft bleibt. Agenten sollten Varianten und Routineänderungen beschleunigen, ohne Design-Reviews in die Bereinigung von Ergebnissen zu verwandeln.
Für Entwickler stellt sich die Frage, ob Code-Ebenen nützlichen Implementierungskontext bewahren. Generierte Prototypen müssen Abwägungen sichtbar machen, ohne mit geprüftem Produktionscode verwechselt zu werden.
Für Produktverantwortliche liegt der Wert in der Nachvollziehbarkeit. Eine Anforderung sollte mit dem Design, dem Prototyp, der Codequelle und der Entscheidung verknüpft sein, die sie geprägt hat.
Die Agent-Funktionen von Figma liefern inzwischen die Bausteine für diesen Workflow. Die kommenden Monate werden zeigen, ob Teams diese Bausteine unter dem Druck des Alltags synchron halten können.
Betrachten Sie die offene Beta als operatives Experiment. Wählen Sie einen klar abgegrenzten Workflow, verbinden Sie die aktuellen Quellen, definieren Sie Zuständigkeiten und messen Sie Nacharbeit, bevor Sie den Ansatz ausweiten.
Die entscheidende Frage lautet nicht mehr, ob ein KI-Agent eine Benutzeroberfläche entwerfen kann. Sie lautet, ob Ihr Team erklären kann, warum diese Benutzeroberfläche seinen Standards entspricht – und sie korrigieren kann, wenn sie es nicht tut.
