Funkcje Figma Agent wprowadzają zasady projektowania między AI a płótno

Figma wprowadziła nowe funkcje agenta Figma, które dają zespołom większą kontrolę nad wynikami pracy AI, mimo nieprzewidywalnego zachowania tej technologii. Wydanie łączy agentów z pisemnymi specyfikacjami, bibliotekami projektowymi, źródłami kodu i działającymi prototypami na jednej platformie.

To coś więcej niż kolejny asystent zyskujący nowe polecenia. Figma próbuje zdefiniować środowisko działania agentów, zanim generowane interfejsy rozprzestrzenią się w zespołach produktowych. Firma stawia na to, że wspólny kontekst, widoczna praca i egzekwowalne zasady projektowe mają większe znaczenie niż nieograniczone generowanie.

Takie podejście stawia Figmę między projektantami a zewnętrznymi agentami programistycznymi, takimi jak Claude Code, Codex, GitHub Copilot i Cursor. Zamiast konkurować wyłącznie wydajnością modeli, Figma chce, aby jej płótno stało się centrum sterowania, w którym zespoły decydują, co agenci powinni tworzyć.

Nowe funkcje Figma Agent określają zasady przed generowaniem

Figma przenosi kontrolę nad agentami z pojedynczych promptów do wspólnej infrastruktury produktowej.

Firma ogłosiła rozszerzony proces pracy podczas swojego pierwszego wydarzenia Config w Indiach. Kluczowym dodatkiem jest Figma Specs, oparte na Markdownie środowisko robocze do zapisywania wymagań produktowych, decyzji, odniesień i kontekstu technicznego.

Specyfikacja może funkcjonować jako osobny plik Figma lub obok pracy na płótnie. Zespoły mogą odwoływać się do projektów, diagramów FigJam, warstw kodu i innych materiałów bez sprowadzania wszystkiego do oderwanego tekstu.

Ta struktura ma znaczenie, ponieważ agent rzadko zawodzi wyłącznie z powodu słabego generowania języka. Często brakuje mu powiązań między wymaganiem, komponentem wizualnym, implementacją w kodzie i wcześniejszą decyzją zespołu.

Tradycyjny plik Markdown może opisywać te relacje, ale nie zachowuje ich automatycznie. Linki stają się nieaktualne, obrazy tracą kontekst, a różne pliki mogą zawierać sprzeczne instrukcje.

Figma Specs ma sprawić, że te połączenia staną się natywne. Według przeglądu premiery zespoły mogą przekształcać wstępne pomysły w szczegółowe specyfikacje i przekazywać je agentom programistycznym za pośrednictwem serwera MCP Figmy.

Model Context Protocol, czyli MCP, to standard umożliwiający systemom AI łączenie się z zewnętrznymi narzędziami i ustrukturyzowanym kontekstem. W implementacji Figmy może on przenosić informacje o produkcie między płótnem a obsługiwanymi agentami deweloperskimi.

Proces pracy zaczyna się, zanim agent napisze kod. Zespół może zgromadzić wymagania, diagramy, odniesienia projektowe i kontekst kodu w specyfikacji, a następnie wykorzystać te materiały podczas generowania.

Ten sam kontekst może wspierać warstwę kodu, czyli interaktywny prototyp oparty na działającym kodzie na płótnie Figmy. Dzięki temu prototyp można analizować obok projektów i decyzji, które doprowadziły do jego powstania.

Figma rozszerzyła również informacje dostępne za pośrednictwem systemów projektowych. Zespoły mogą dodawać pisemne wytyczne do opublikowanych bibliotek i łączyć źródła kodu z repozytoriów GitHub lub pakietów npm.

Wytyczne mogą dokumentować zasady, preferowane wzorce, niedozwolone rozwiązania i szczegóły implementacyjne. Agenci mogą odczytywać te materiały, gdy odpowiednia biblioteka jest włączona.

Źródła kodu dodają kolejną warstwę oparcia w faktach. Dają agentowi dostęp do zaimplementowanych komponentów, zamiast zmuszać go do wywnioskowania każdego elementu interfejsu ze zrzutów ekranu lub ramek wizualnych.

To połączenie tworzy hierarchię kontekstu. Specyfikacje opisują, co zespół zamierza zbudować, biblioteki projektowe definiują jego język wizualny, a źródła kodu pokazują, jak elementy działają w oprogramowaniu.

Ogłoszenie dotyczące agentów zwróciło również uwagę na scentralizowane zarządzanie bibliotekami projektowymi, bibliotekami kodu i wytycznymi. Figma twierdzi, że agenci mogą korzystać z tego systemu podczas tworzenia lub edytowania pracy.

Mechanizmy te odpowiadają na powracający problem generatywnych interfejsów. Model może stworzyć wiarygodny ekran, jednocześnie ignorując zasady komponentów organizacji, wzorce interakcji lub praktyki dostępności.

Dopracowany rezultat nie musi być poprawnym rezultatem produktowym. Może wyglądać właściwie, a jednocześnie prowadzić do powielonych komponentów, nieobsługiwanych stanów lub prac implementacyjnych, które deweloperzy będą musieli później zastąpić.

Odpowiedzią Figmy nie jest wyeliminowanie promptów. Chodzi o otoczenie ich trwałym kontekstem należącym do zespołu, a nie do osoby rozpoczynającej pojedynczy czat.

Zmienia to rolę samego promptu. Staje się on prośbą w zarządzanym środowisku roboczym, a nie jedyną instrukcją stojącą między agentem a produktem.

Figma Code Layers przenoszą działające oprogramowanie na płótno

Warstwy kodu Figmy zmieniają płótno w miejsce testowania zachowania, a nie tylko przeglądania wizualnych reprezentacji.

Warstwy kodu przeszły z zamkniętej bety do otwartej bety w ramach tej premiery. Figma informuje, że funkcja jest stopniowo udostępniana w jej planach, choć poszczególne konta mogą otrzymać dostęp w różnym czasie.

Warstwa kodu zawiera działający interfejs oparty na uruchomionym kodzie. Zespoły mogą umieszczać ją obok konwencjonalnych ramek projektowych, duplikować ją, testować różne kierunki i analizować stany interaktywne.

To rozróżnienie jest istotne. Tradycyjne prototypy mogą symulować ścieżkę przez połączone ramki, ale nie muszą odzwierciedlać zachowania rzeczywistego komponentu.

Działająca implementacja może ujawnić zachowanie podczas ładowania, puste stany, błędy, responsywne układy i złożone interakcje. Takie szczegóły często ujawniają pytania produktowe, które statyczne ekrany pozostawiają bez odpowiedzi.

Przewodnik po warstwach kodu opisuje kilka punktów wyjścia. Użytkownicy mogą wygenerować warstwę za pośrednictwem agenta Figma, przekonwertować projekt, zaimportować kod lub zacząć od istniejącej bazy kodu zespołu.

Projektant mógłby wybrać sprawdzony proces płatności i poprosić agenta o dodanie alternatywnej opcji dostawy. Powstała warstwa kodu mogłaby pokazać zachowanie walidacji, ładowania, powodzenia i niepowodzenia.

Zespół mógłby następnie zduplikować tę wersję i przetestować obok niej inną interakcję. Menedżerowie produktu, projektanci i inżynierowie porównywaliby działające opcje w jednym wspólnym pliku.

Figma twierdzi, że zmiany mogą wracać do warstwy kodu, a w obsługiwanych procesach także do połączonej bazy kodu. Ta obietnica pozostaje ważniejsza niż prosty eksport projektu do kodu.

Eksport jest zazwyczaj artefaktem przekazania pracy. Połączona warstwa kodu ma pozostać częścią iteracyjnej pętli między eksploracją projektu a implementacją.

Figma po raz pierwszy wprowadziła warstwy kodu w zamkniętej becie w czerwcu 2026 roku. Jej wcześniejszy podgląd płótna obsługiwał importy z GitHub, lokalne foldery, szablony, wyniki Figma Make oraz punkty wyjścia generowane przez agentów.

Otwarta beta udostępnia ten model szerszej grupie odbiorców. Tworzy również większy test tego, czy współpraca oparta na kodzie działa poza starannie wybranymi zespołami.

Bezpośrednim przypadkiem użycia nie jest automatyczne wdrażanie wygenerowanego kodu. Chodzi o to, by kod był wystarczająco łatwy do wykorzystania podczas odkrywania produktu.

Dyrektor ds. projektowania Figmy, Loredana Crisan, opisała rosnącą lukę między tworzeniem kodu a rzeczywistymi wydaniami. Powiedziała TechCrunch, że organizacje tworzą 17 razy więcej kodu, podczas gdy liczba wydań wzrosła jedynie 1,3 raza.

Dane te pochodzą od firmy i nie powinny być traktowane jako niezależny punkt odniesienia dla branży. Mimo to wyjaśniają strategię stojącą za warstwami kodu Figmy.

Wygenerowany kod jest coraz częściej wykorzystywany do badania możliwości, które nigdy nie trafiają do produkcji. Figma chce, aby ta eksploracyjna praca odbywała się tam, gdzie zespoły mogą ją wspólnie oglądać, omawiać i doskonalić.

Przekształca to kod z końcowego medium implementacyjnego w materiał projektowy. Zespoły produktowe mogą wykorzystywać działające oprogramowanie, aby doprecyzować, co powinny zbudować, zanim zobowiążą się do architektury produkcyjnej.

To podejście uwzględnia również fakt, że sesje agentów oparte na terminalu często trudno udostępniać. Deweloper może szybko wygenerować kilka interfejsów, ale współpracownicy mogą później otrzymać jedynie link lub nagranie.

Proces ten ukrywa alternatywy, prompty i kompromisy stojące za wynikiem. Umieszczenie działającej wersji na płótnie sprawia, że eksploracja staje się widoczna i łatwiejsza do zakwestionowania.

Widoczność nie sprawia jednak, że kod prototypu jest gotowy do produkcji. Zespoły nadal potrzebują przeglądu inżynieryjnego, testów, mechanizmów bezpieczeństwa, walidacji dostępności i architektury łatwej w utrzymaniu.

Wartość warstw kodu zależy zatem od tego, jak zespoły klasyfikują ich wyniki. Używane jako artefakt eksploracyjny mogą skrócić pętle informacji zwrotnej, nie udając, że wygenerowane prototypy są ukończonym oprogramowaniem.

Prawdziwa rywalizacja to wspólny kontekst kontra odizolowane czaty z agentami

Figma stawia na to, że zarządzany kontekst będzie ważniejszy niż to, który agent wygeneruje najszybszy pierwszy szkic.

Głównym przeciwnikiem w tej historii nie jest inny dostawca narzędzi projektowych. Jest nim odizolowany proces pracy z agentem, który umieszcza pracę produktową w prywatnych czatach, terminalach lub niepołączonych sesjach przeglądarki.

Agenci programistyczni już generują interfejsy na podstawie tekstu i obrazów. Ich szybkość tworzy nowy problem koordynacyjny, gdy każdy uczestnik pracuje na podstawie innych instrukcji i lokalnego kontekstu.

Jeden projektant może dołączyć najnowszą bibliotekę komponentów. Deweloper może korzystać ze starszej gałęzi repozytorium, podczas gdy menedżer produktu przekazuje wymagania skopiowane z osobnego dokumentu.

Każdy agent może zwrócić wiarygodną odpowiedź. Wyniki mogą jednak pozostawać ze sobą w sprzeczności, ponieważ systemy nigdy nie otrzymały tego samego źródła prawdy.

Figma Specs próbuje ograniczyć tę fragmentację, zapewniając kontekstowi widoczne miejsce. Utrzymuje wymagania blisko diagramów, projektów, warstw kodu i decyzji, do których się odnoszą.

Rozszerzenie systemu projektowego rozwiązuje powiązany problem. Figma chce, aby agenci rozumieli nie tylko dostępne komponenty, lecz także zasady regulujące ich użycie.

Biblioteka może zawierać kilka wariantów przycisku, nie wyjaśniając, który z nich należy zastosować w działaniu destrukcyjnym. Wytyczne mogą dostarczyć brakującej logiki decyzji.

Podobnie dostęp do źródeł kodu może pokazać agentowi, czy komponent już istnieje. Może to ograniczyć pokusę wygenerowania wizualnie podobnego zamiennika o niezgodnym zachowaniu.

Istniejący agent Figmy obsługuje obecnie wyszukiwanie w plikach, dołączanie zawartości platformy, odwoływanie się do elementów biblioteki oraz równoczesne uruchamianie wielu promptów. Jego dokumentacja agenta rozróżnia również wbudowanego agenta od zewnętrznych klientów MCP.

Wbudowany agent działa bezpośrednio w plikach projektowych. Zewnętrzni agenci mogą korzystać z możliwości zapisu na płótnie Figmy, aby przenosić na platformę treści z baz kodu lub innych projektów AI.

To rozróżnienie pozwala Figmie obsługiwać kilku agentów, bez wymagania, by jeden asystent wykonywał każde zadanie. Firma może pozostać wspólną warstwą pod zmieniającą się grupą modeli i narzędzi deweloperskich.

Według firmy jej obsługa MCP obejmuje obecnie ponad 20 nowych partnerów. Ogłoszona lista obejmuje OpenCode, Dia, Meta Muse oraz indyjski startup AI Sarvam.

Figma wcześniej wymieniała Claude Code, Codex, GitHub Copilot i Cursor jako przykłady zewnętrznych agentów, którzy mogą zapisywać do plików. Rozszerzone wsparcie partnerów czyni neutralność wobec modeli częścią strategii platformy.

To pozycja, którą można obronić, ponieważ rankingi modeli szybko się zmieniają. Zespół może preferować jednego agenta do kodu interfejsu, a innego do badań, dokumentacji lub generowania obrazów.

Figma nie musi wygrywać każdego porównania modeli, jeśli kontroluje wspólny kontekst produktu. Potrzebuje, by agenci traktowali pliki, biblioteki i reguły Figma jako autorytatywne dane wejściowe.

Aktualizacja MCP canvas firmy jasno wyraża tę ambicję. Umiejętności mogą instruować zewnętrznych agentów, jak realizować przepływy pracy, porządkować kroki i przestrzegać zespołowych konwencji.

W tym kontekście umiejętność to zestaw instrukcji wielokrotnego użytku, który kształtuje zachowanie agenta. Może kodować wiedzę operacyjną, która w przeciwnym razie pozostałaby w historii promptów pojedynczego pracownika.

Zespół odpowiedzialny za system projektowy mógłby stworzyć umiejętność do budowania formularzy. Instrukcje mogłyby wymagać stosowania zatwierdzonych komponentów pól, dostępnych etykiet, udokumentowanych stanów walidacji i określonych tokenów odstępów.

Zewnętrzny agent programistyczny mógłby następnie stosować te reguły podczas tworzenia lub aktualizowania zasobów. Kanwa Figma prezentowałaby efekt pracy tam, gdzie szerszy zespół już współpracuje.

Przypomina to uporządkowaną bazę wiedzy inżynierskiej, ale kontekst jest tu bezpośrednio powiązany z artefaktami produktu. Różnica polega na tym, gdzie decyzje stają się możliwe do wdrożenia.

Wyłaniająca się konkurencja dotyczy więc orkiestracji. Narzędzia projektowe, edytory kodu, repozytoria i systemy dokumentacji chcą stać się miejscem, w którym agenci otrzymują wiarygodny kontekst.

Figma ma przewagę, ponieważ wiele decyzji dotyczących interfejsu już znajduje się na jej kanwie. Ta przewaga utrzyma się jednak tylko wtedy, gdy platforma będzie synchronizować te decyzje z kodem produkcyjnym.

Przewidywalni agenci nadal zależą od niedoskonałych danych wejściowych

Figma może ograniczać zachowanie agentów, ale nie może zagwarantować, że każda reguła jest kompletna, aktualna i właściwie interpretowana.

Firma wprowadza te mechanizmy, ponieważ generatywna AI pozostaje niedeterministyczna. To samo żądanie może prowadzić do różnych struktur, szczegółów i wyborów implementacyjnych w kolejnych uruchomieniach.

Wytyczne mogą zmniejszać tę zmienność. Nie mogą jej jednak całkowicie wyeliminować, zwłaszcza gdy instrukcje są sprzeczne albo nie obejmują nowej sytuacji.

Zespół może nakazać agentowi użycie preferowanego komponentu, podczas gdy połączone repozytorium zawiera dwie implementacje. Biblioteka projektowa może wskazywać jedną wersję, lecz kod produkcyjny może zależeć od drugiej.

Specyfikacje wprowadzają kolejny obowiązek utrzymaniowy. Dobrze uporządkowana specyfikacja pomaga wyłącznie wtedy, gdy jej wymagania odzwierciedlają aktualne decyzje.

Nieaktualny kontekst może sprawić, że agent będzie konsekwentnie się mylił. Taka porażka jest groźniejsza niż oczywista halucynacja, ponieważ wynik może sprawiać wrażenie kontrolowanego i wiarygodnego.

Zespoły systemów projektowych będą potrzebować zasad odpowiedzialności za instrukcje dla agentów. Muszą ustalić, kto może publikować wytyczne, łączyć źródła kodu, rozstrzygać konflikty i zatwierdzać zmiany.

Figma prezentuje zapowiedź scentralizowanego zarządzania systemem projektowym za pomocą map i kontroli systemowych. Narzędzia te mają ujawniać zależności i luki, w tym brakujące opisy lub stany interakcji.

Ta warstwa administracyjna jest konieczna, ponieważ dostęp agentów zwiększa konsekwencje słabej dokumentacji systemu. Niegdyś nieudokumentowany komponent był po prostu trudniejszy do poprawnego użycia przez ludzi.

Teraz agent może powielić to nieporozumienie na wielu ekranach w ciągu kilku minut. Szybsze generowanie wzmacnia zarówno dobre standardy, jak i zaniedbania.

Kontrola dostępu rodzi kolejne obawy. Łączenie agentów z projektami, specyfikacjami, repozytoriami i usługami zewnętrznymi rozszerza obszar zawierający zastrzeżone informacje o produkcie.

Figma twierdzi, że funkcja MCP korzysta z jej mechanizmów bezpieczeństwa i niezawodności. Zespoły korporacyjne nadal będą musiały przeanalizować uprawnienia, retencję danych, połączonych klientów i dostęp do repozytoriów.

Platforma pozwala administratorom wyłączać funkcje AI, jednak dostępne mechanizmy kontroli mogą być zbyt szerokie dla części organizacji. Zgodnie z dokumentacją wsparcia Figma wyłączenie warstw kodu może również wyłączyć inne funkcje AI.

Zespoły mogą potrzebować bardziej precyzyjnych zasad opartych na wrażliwości projektu, repozytorium, dostawcy modelu lub roli użytkownika. Skuteczność nadzoru będzie zależała od rozwoju tych mechanizmów kontroli.

Wdrożenie również pozostaje niepewne. Projektanci mogą doceniać eksplorację wspieraną przez kod, nie chcąc jednocześnie utrzymywać instrukcji dla agentów ani rozwiązywać problemów z importowanymi repozytoriami.

Programiści mogą sprzeciwiać się wygenerowanym strukturom, które wyglądają przekonująco, lecz są sprzeczne z ustaloną architekturą. Menedżerowie produktu mogą tworzyć szczegółowe specyfikacje, które staną się kolejnym dokumentem wymagającym synchronizacji.

Wczesne dyskusje użytkowników już poruszały kwestie importów repozytoriów, błędów infrastruktury oraz tego, czy funkcje AI odwracają uwagę od od dawna zgłaszanych oczekiwań wobec produktu. Te anegdoty nie stanowią dowodu na szeroką ocenę jakości produktu.

Pokazują jednak, co musi sprawdzić otwarta beta. Figma musi udowodnić, że warstwy kodu działają niezawodnie z prawdziwymi repozytoriami i codziennymi ograniczeniami zespołów.

Platforma mierzy się także z ryzykiem koncepcyjnym. Łączenie wymagań, projektu, kodu, treści i mechanizmów kontroli agentów może ograniczyć fragmentację, ale może też uczynić samą Figma bardziej złożoną.

Wspólna kanwa odnosi sukces, gdy każdy uczestnik może zrozumieć istotny stan bez konieczności opanowania każdego systemu leżącego pod spodem. Zbyt wiele nakładających się warstw odtworzyłoby problem koordynacji wewnątrz jednego produktu.

Twierdzenia Figma o generowaniu wyższej jakości, zgodnym z marką wymagają również niezależnych dowodów. Firma pokazała, jak kontekst trafia do przepływu pracy, ale nie jak konsekwentnie agenci go przestrzegają.

Zespoły powinny mierzyć wyniki, zamiast je zakładać. Przydatne wskaźniki obejmują ponowne wykorzystanie komponentów, błędy dostępności, poprawki, czas przeglądu oraz rozbieżność między prototypami a kodem produkcyjnym.

Kluczowe pytanie nie brzmi, czy agent potrafi wygenerować atrakcyjny ekran. Chodzi o to, czy ten ekran wytrzymuje kontakt z rzeczywistym systemem projektowym i bazą kodu.

Figma Specs rozszerza platformę poza pliki projektowe

Specs przekształca strategię agentową Figma w szerszą próbę przejęcia kontroli nad decyzjami produktowymi przed i po pracy na kanwie.

Specyfikacja produktu tradycyjnie znajdowała się w narzędziu dokumentowym, systemie zgłoszeń lub repozytorium. Praca wizualna trafiała następnie do Figma, a implementacja techniczna — gdzie indziej.

Każde przejście tworzyło etap tłumaczenia. Wymagania mogły tracić niuanse, projekty mogły oddalać się od zatwierdzonego zachowania, a programiści mogli odmiennie interpretować niepełne notatki przekazania.

Figma Specs podważa ten podział. Traktuje Markdown jako elastyczne medium, jednocześnie osadzając go w sieci wizualnych i technicznych artefaktów Figma.

Menedżer produktu może przygotować wymaganie i odwołać się do diagramu FigJam. Projektant może połączyć odpowiednie ekrany, a inżynier może dodać kontekst kodu z GitHub.

Agent może następnie użyć połączonych materiałów do stworzenia warstwy kodu lub przekazać specyfikację przez MCP. Specyfikacja staje się aktywnym danym wejściowym, a nie dokumentem przeglądanym wyłącznie przez ludzi.

Rozszerza to zakres obsługiwanego przepływu pracy Figma. Platforma nie ogranicza się już do tworzenia projektów interfejsów i przekazywania ich zespołom programistycznym.

Chce uczestniczyć w definiowaniu produktu, prototypowaniu, kontekście implementacyjnym i operacjach związanych z treścią. Każda dodatkowa warstwa zwiększa wartość wspólnego kontekstu dla agentów.

Integracja Figma z Payload wzmacnia ten kierunek. Payload to open-source’owy bezgłowy system zarządzania treścią, który dołączył do Figma w 2025 roku.

Nowa integracja łączy Payload z Figma Make, opartym na promptach kreatorem aplikacji i stron internetowych platformy. Zespoły mogą tworzyć doświadczenia oparte na danych i zarządzać treścią bez oddzielania wizualnego prototypu od jego modelu treści.

Figma informuje, że liczba pobrań Payload wzrosła sześciokrotnie w ciągu poprzednich 12 miesięcy. Jest to wskaźnik podawany przez firmę i nie ujawnia, ile projektów korzysta z nowej integracji.

Mimo to połączenie to rozwiązuje praktyczne ograniczenie generowanych stron internetowych. Dopracowana strona staje się mniej użyteczna, gdy treść pozostaje zakodowana na stałe lub odłączona od przepływów publikowania.

Payload zapewnia przechowywanie treści, API, przepływy pracy i interfejs administracyjny. Figma twierdzi, że marketerzy mogą zarządzać treścią, podczas gdy programiści zachowują dostęp do frameworka open source.

To również wyostrza różnicę między budowaniem w celu eksploracji a budowaniem w celu wdrożenia. Jednorazowy prototyp potrzebuje tylko tyle zachowania, by sprawdzić pomysł.

Strona produkcyjna wymaga trwałej treści, uprawnień, struktur danych i operacyjnych przepływów pracy. Integracja CMS przybliża Figma Make do tej drugiej kategorii.

Firma ostrożnie zachowuje możliwość wyjścia. Twierdzi, że zespoły mogą przenieść swoją pracę opartą na Payload poza Figma, co ma znaczenie dla programistów obawiających się uzależnienia od platformy.

Przenośność należy jednak oceniać na podstawie rzeczywistych projektów. Eksportowalny kod nie staje się automatycznie łatwy w utrzymaniu bez środowiska, które go wygenerowało.

Szersza strategia wywiera presję na kilka kategorii jednocześnie. Narzędzia dokumentowe obsługują specyfikacje, agenci programistyczni generują implementacje, a kreatory stron łączą edycję wizualną z wdrażaniem.

Figma nie zastępuje ich wszystkich jednym modelem. Próbuje stać się wspólnym podłożem, na którym ich rezultaty się łączą.

Podejście to pasuje do istniejącego modelu współpracy firmy. Figma stała się centralnym narzędziem zespołów produktowych, ponieważ pliki wspierały wieloosobową edycję, komentarze, komponenty i współdzielone biblioteki.

Agenci dodają nowy rodzaj uczestnika. W przeciwieństwie do ludzkich współpracowników mogą szybko modyfikować duże obszary i działać między narzędziami za pośrednictwem interfejsów odczytywalnych przez maszyny.

Platforma musi więc wspierać zarówno współpracę, jak i ograniczenia. Musi uwidaczniać pracę agentów, jednocześnie ograniczając zasięg rozprzestrzeniania się błędnej instrukcji.

Figma Specs, źródła kodu i wytyczne to odrębne funkcje, ale ich wartość się kumuluje, gdy są używane razem. Każda z nich rozwiązuje inną część problemu kontekstu.

Specs wyjaśnia intencję. Biblioteki wyrażają decyzje projektowe wielokrotnego użytku, a źródła kodu osadzają te decyzje w implementacji.

Warstwy kodu zapewniają wykonywalne miejsce do testowania rezultatu. MCP łączy następnie ten proces z agentami działającymi gdzie indziej.

Tak działają agenci Figma w wyłaniającym się modelu firmy. Nie otrzymują po prostu promptu i nie tworzą ekranu.

Działają w łańcuchu kontekstu produktu, wspólnych reguł, roboczych artefaktów i ludzkiej kontroli. Ten łańcuch jest strategią produktu.

Trzy sygnały pokażą, czy strategia agentowa Figma działa

Kolejnym testem będzie to, czy zarządzane przepływy pracy agentów poprawiają rzeczywiste wyniki zespołów bez dodawania kolejnej warstwy utrzymania.

Pierwszym sygnałem będzie adopcja warstw kodu po wdrożeniu otwartej bety. Sam dostęp nie potwierdzi wartości.

Zespoły muszą wielokrotnie tworzyć, duplikować, przeglądać i udoskonalać działające prototypy na kanwie. Dalsze użycie sugerowałoby, że eksploracja wsparta kodem rozwiązuje realny problem współpracy.

Najbardziej użyteczne dowody porównywałyby przepływy pracy przed i po wdrożeniu. Krótsze cykle przeglądów, mniej poprawek przekazania lub lepsze odwzorowanie stanów interaktywnych wspierałyby tezę Figma.

Porzucone importy, niewiarygodne wykonanie lub częste odtwarzanie pracy w zewnętrznych narzędziach ją osłabią. Otwarta beta daje Figma większą populację do wykrywania tych problemów.

Drugim sygnałem będzie to, czy wytyczne projektowe i źródła kodu ograniczają błędy agentów. Zespoły powinny obserwować częstsze użycie zatwierdzonych komponentów oraz mniej niezgodności z marką lub implementacją.

Październikowe informacje o wydaniu Figma potwierdzają, że agent może odczytywać wytyczne bibliotek, przeszukiwać pliki, dołączać kontekst platformy i wspierać niestandardowe umiejętności. Te możliwości ustanawiają mechanizm, a nie rezultat.

Rozstrzygające dowody pojawią się wraz z powtarzalnym użyciem produkcyjnym. Skuteczny system powinien pomagać agentom przestrzegać konwencji bez konieczności ponownego formułowania ich przez użytkowników w każdym prompcie.

Powinno to również uwidaczniać konflikty. Jeśli biblioteka projektowa i repozytorium kodu są ze sobą niezgodne, system musi pomagać zespołom ustalić, które źródło jest autorytatywne.

W przeciwnym razie dodatkowy kontekst może zwiększać niejednoznaczność. Agent może otrzymać więcej informacji, a jednocześnie mieć mniejszą pewność, której instrukcji powinien przestrzegać.

Trzecim sygnałem jest rozwój wsparcia dla zewnętrznych agentów. Argument Figma dotyczący platformy staje się silniejszy, gdy zespoły mogą zmieniać modele bez konieczności odbudowywania kontekstu projektowego.

Wsparcie dla większej liczby klientów MCP zapewnia dystrybucję, ale zgodność musi wykraczać poza podstawowy dostęp do zapisu. Zewnętrzni agenci potrzebują niezawodnego dostępu do komponentów, zmiennych, wytycznych, obrazów i relacji z kodem.

Figma poinformowała, że pracuje nad szerszą zgodnością z jej Plugin API. Postępy w tym obszarze zdecydują o tym, czy zewnętrzni agenci staną się pełnoprawnymi współpracownikami, czy jedynie ograniczonymi narzędziami importu.

Znaczenie będzie mieć również odpowiedź konkurencji. Edytory kodu i platformy programistyczne mogą pogłębiać własne integracje projektowe, a systemy dokumentowe mogą uczynić specyfikacje bardziej czytelnymi dla agentów.

Jeśli te narzędzia zachowają kontekst bez kierowania pracy przez Figma, zespoły mogą preferować rozproszony przepływ pracy. Figma musi udowodnić, że konsolidacja prowadzi do jaśniejszych decyzji, a nie jedynie do większej zależności od platformy.

Dla projektantów praktyczne pytanie brzmi, czy płótno pozostaje miejscem podejmowania osądów. Agenci powinni przyspieszać tworzenie wariantów i rutynowe poprawki, nie zamieniając przeglądu projektu w porządkowanie wyników.

Dla programistów pytanie dotyczy tego, czy warstwy kodu zachowują użyteczny kontekst implementacyjny. Wygenerowane prototypy muszą ujawniać kompromisy, nie będąc mylone ze sprawdzonym kodem produkcyjnym.

Dla liderów produktu wartość tkwi w możliwości śledzenia powiązań. Wymaganie powinno łączyć się z projektem, prototypem, źródłem kodu i decyzją, która je ukształtowała.

Funkcje agentowe Figma zapewniają obecnie elementy potrzebne do takiego przepływu pracy. Najbliższe miesiące pokażą, czy zespoły potrafią utrzymać te elementy w synchronizacji pod codzienną presją.

Traktuj otwartą betę jako eksperyment operacyjny. Wybierz jeden ograniczony przepływ pracy, połącz aktualne źródła, określ odpowiedzialność i zmierz zakres poprawek przed rozszerzeniem wdrożenia.

Najważniejsze pytanie nie brzmi już, czy agent AI potrafi narysować interfejs. Chodzi o to, czy Twój zespół potrafi wyjaśnić, dlaczego ten interfejs spełnia jego standardy, oraz poprawić go, gdy tak nie jest.