Od Figmy do kodu: Jak Webflow projektuje w Cursor #EN342

Notatki z podcastu Sneak Peek, w którym JB z Webflow opowiada o wykorzystaniu Cursor do tworzenia wysokojakościowych prototypów bezpośrednio w kodzie.

TL;DR

Cursor eliminuje największe frustracje Figmy – pozwala mieć jednocześnie hover effects, tooltips i clickability, co w Figmie jest niemożliwe
Konfiguracja zajmuje około tygodnia, jednak daje dostęp do w pełni interaktywnych prototypów z działającymi inputami, searchem i złożonymi interakcjami
Wielokrotne agenty zapewniają lepszą organizację – każdy agent odpowiada za konkretne zadanie, co ułatwia cofanie zmian i śledzenie historii
Figma MCP, Chrome Dev Tools i Stagewise wzbogacają przepływ pracy, dając AI więcej kontekstu i możliwość weryfikacji zmian
AI nie zastępuje myślenia – to narzędzie do augmentacji umiejętności, które uwydatnia istniejące mocne strony projektanta
Mobin jako źródło inspiracji – biblioteka wzorców z najlepszych aplikacji pomaga unikać reinwentowania koła
Ciekawość będzie kluczowa – projektanci chętni do eksploracji nowych narzędzi zobaczą największe rezultaty

Ograniczenia Figmy w prototypowaniu interakcji

Jak zauważa JB, „zawsze istnieje przepaść między projektem a rzeczywistym, kodowanym produktem”. Narzędzia do statycznych makiet jedynie symulują działanie aplikacji webowej, nie będąc tym działaniem.

JB od lat zmagał się z fundamentalnym problemem. W Figmie nie można stworzyć elementu, który jednocześnie ma hover effect i jest klikalny.

Przykład? Tag z tooltipmem. Na stronie internetowej cały tag może być klikalny, podczas gdy ikona wyświetla tooltip przy najechaniu. W Figmie trzeba wybierać – albo hover, albo click. JB był zmuszony umieszczać hover effect na body tagu, a clickability tylko na ikonie.

Prototypowanie złożonych interakcji w Figmie wymaga masywnej ilości pracy. Każda permutacja checkboxów, każdy wariant stanu interfejsu to kolejne godziny budowania połączeń między ekranami.

„Sufity” złożoności w tradycyjnych narzędziach

Według JB największy problem pojawia się przy skali i złożoności:

Brak jednoczesnej interaktywności – nie można połączyć hover states z clickability na tym samym elemencie
Ręczne tworzenie każdej permutacji – każdy wariant checkboxów lub stanów wymaga osobnego ekranu
„Sufity” narzędzia – przy próbie prototypowania skomplikowanych interakcji (jak bulk actions) projektanci szybko napotykają na twarde ograniczenia
Marnotrawstwo energii – tracisz czas na walkę z narzędziem zamiast na faktyczne projektowanie

Prototypowanie w Cursor – praca bezpośrednio w przeglądarce

W Cursor wszystko po prostu działa. JB pokazuje tag – hover zmienia stylizację, tooltip się wyświetla, a cały element jest klikalny. Trzy rzeczy jednocześnie. Żadnych sztuczek, żadnych obejść.

Inputy działają od razu. Search funkcjonuje bez dodatkowej konfiguracji. Checkboxy można zaznaczyać w dowolnej kombinacji, a UI reaguje dynamicznie. To nie jest symulacja – to prawdziwy kod działający w przeglądarce.

Jak mówi JB, prototyp „daje świetne odczucie, czuje się prawdziwe doświadczenie, ponieważ nim jest”.

JB zwraca uwagę na detal, którego nie zauważyłby pracując w Figmie. Po otwarciu modalu focus automatycznie przechodzi na pole search. Dlaczego? Bo jeśli użytkownik chce komuś dać dostęp, prawdopodobnie zacznie od wpisania nazwiska. Taki typ interakcji nie przychodzi do głowy przy statycznych makietach.

Interoperability między komponentami

JB demonstruje coś, co w Figmie byłoby prawie niemożliwe do zaprototypowania. Zmienia uprawnienia użytkownika w tabeli site access – z „content editor” na „designer”. Następnie przechodzi do innej części aplikacji, webflow dashboard. Tam ten sam użytkownik ma teraz rozszerzone możliwości w CMS, ponieważ jego rola się zmieniła.

Te dwie sekcje rozmawiają ze sobą w czasie rzeczywistym. Zmiana w jednym miejscu natychmiast wpływa na drugie. Prototypowanie takiej dwukierunkowej komunikacji w Figmie wymagałoby godzin tworzenia wariantów i połączeń dla każdej możliwej kombinacji. W Cursor to po prostu działa, bo to prawdziwy kod z prawdziwym state management.

Konfiguracja techniczna – tydzień intensywnej nauki

JB nie ukrywa, że początek był trudny. Konfigurowanie lokalnego środowiska, podłączanie się do repozytorium, konfiguracja Webflow Cloud do wdrożenia – zajęło mu to prawie tydzień. Spędził sporo czasu w weekendy, żeby wszystko działało.

Wspomina o szczegółach technicznych, które trzeba było ogarnąć: base path, mount paths, autentykacja do GitHub, poprawne wywołanie repozytorium. To nie było trywialne.

✅ Checklista: Co potrzebujesz do startu z Cursor

Przed rozpoczęciem:

Dostęp do repozytorium zespołu (jeśli pracujesz w firmie)
Dokumentacja dla designerów
Konto GitHub i podstawowa znajomość git
Lokalne środowisko developerskie (Node.js, npm)
Około tygodnia czasu na naukę i konfigurację

Podczas konfiguracji:

Sklonuj template/repozytorium do lokalnej maszyny
Zainstaluj wymagane zależności
Skonfiguruj autentykację do GitHub
Połącz się ze środowiskiem wdrożeniowym (np. Webflow Cloud)
Skonfiguruj base path i mount paths
Przetestuj podstawowy przepływ pracy (zmiana → commit → wdrożenie)
Zapewnij tokeny projektowe – upewnij się, że AI ma dostęp do wszystkich zmiennych stylów i jest zobowiązane do ich używania

Po konfiguracji:

Stwórz pierwszy testowy agent
Wypróbuj proste zmiany
Naucz się robić commity i przełączać gałęzie
Zainstaluj dodatkowe narzędzia (MCP, Stagewise)

Co motywowało JB? Frustracja z Figmy i wizja pracy bezpośrednio w przeglądarce. Wiedział, że po przejściu przez trudny początek dostanie narzędzie, które od lat chciał mieć.

Dzisiaj Webflow ma gotowy template – całą replikę aplikacji Webflow zbudowaną w kodzie. Designer może sklonować repozytorium i od razu zacząć prototypować na gotowym fundamencie. Zespół JB ciągle rozwija ten template. Gdy ktoś stworzy coś wartościowego, scala to do głównego repozytorium – wszyscy mogą z tego korzystać.

Prototypy można wdrażać do Webflow Cloud i dzielić się nimi ze stakeholderami. To kolejny element przepływu pracy, który wymaga konfiguracji, ale daje możliwość pokazania działającego prototypu każdemu w firmie.

Cursor Rules – wbudowanie kontekstu design systemu

JB podkreśla kluczowy element, który sprawia, że Cursor daje dobre rezultaty – cursor rules. To instrukcje, które mówią AI: „Gdy projektujesz sekcję, tabelę lub jakikolwiek komponent, używaj naszych gotowych komponentów z design systemu.”

Webflow ma wszystkie komponenty już wystylizowane zgodnie z ich design systemem w repozytorium. Cursor Rules sprawia, że AI automatycznie po nie sięga zamiast tworzyć wszystko od zera.

Dlatego gdy JB prosi o dodanie kolumny do tabeli, Cursor używa już istniejących komponentów – tag component, icon buttons, tooltips. Wszystko jest spójne z resztą aplikacji. Wszystko ma już wbudowaną interaktywność.

Im więcej kontekstu dajesz AI, tym lepiej wykonuje swoją pracę. Cursor Rules to sposób na wbudowanie tego kontekstu raz, żeby nie powtarzać go w każdym prompcie.

Przepływ pracy w praktyce – demonstracja na żywo

Demonstracja na żywo pokazuje prawdziwy proces. JB chce dodać kolumnę „last active” do tabeli z uprawnieniami. Zamiast pisać, używa dyktacji – mówi do AI.

„Na stronie site access, po kolumnie CMS access, dodaj nową kolumnę dla last active, która pokazuje kiedy użytkownik był ostatnio aktywny.”

Plan Mode vs Agent Mode

JB pokazuje dwa tryby pracy w Cursor. Może przełączyć się między:

Agent Mode – wykonuje od razu, bez pytania. Dla prostych zadań.
Plan Mode – najpierw tworzy plan, pyta o potwierdzenie. Dla złożonych zadań.

W tym przypadku wybiera Agent Mode, ponieważ zadanie jest proste. Cursor przechodzi w tryb agenta. Czyta pliki, identyfikuje komponenty, planuje zmiany. W terminalu lecą diffy – kod się zmienia w czasie rzeczywistym.

JB odświeża stronę. Kolumna się pojawia. Ale jest error.

„Staram się nie panikować, gdy coś się psuje w trakcie procesu” – komentuje JB. Kopiuje błąd, wkleja do Cursora. Agent naprawia. Kolejne odświeżenie – działa. Wszystko w toku, błędy się zdarzają, jednak agent je naprawia.

Cały proces zajął pięć minut. W Figmie trzeba by skopiować kolumnę, dostosować szerokości, ręcznie podmienić zawartość każdej komórki. Następnie stworzyć połączenia dla interakcji. To zdecydowanie dłużej niż pięć minut.

Cursor czasem pyta o doprecyzowanie

JB wspomina o nowej funkcji – gdy request jest bardzo złożony lub niejednoznaczny, Cursor czasem zatrzymuje się i zadaje pytania uzupełniające zamiast od razu wszystko wykonywać.

„Where do the existing users come from?” – pyta agent, bo JB prosił o dodanie użytkowników z workspace, ale nie było jasne skąd je pobrać.

To pomaga uniknąć sytuacji, gdzie AI wprowadza masę zmian, które wcale nie były zamierzone. Łatwiej jest odpowiedzieć na pytanie niż potem wszystko cofać.

Figma wciąż jest w grze – podział obowiązków

Ważne rozróżnienie, które JB podkreśla: „Nadal zaczynam w Figmie”.

Cursor nie zastępuje Figmy w fazie eksploracji i iteracji nad zupełnie nowym UI. JB wciąż tworzy statyczne makiety w Figmie, szczególnie dla nowych funkcji, gdzie potrzebuje szybko przetestować różne kierunki.

Według JB nie dostaje przyspieszenia w iterowaniu i eksplorowaniu różnych opcji. Figma jest wciąż szybsza do szkicowania i testowania alternatyw wizualnych.

Jednak gdy ma już kierunek i chce dodać interaktywność? Wtedy przenosi to do Cursor. Tam prototypowanie samej interaktywności jest nieporównywalnie szybsze.

Dlaczego wiele agentów zamiast jednego

W Cursor można pracować w jednym długim chacie albo tworzyć osobne agenty dla każdego zadania. JB konsekwentnie wybiera drugie podejście.

Powód jest prosty – organizacja i higiena kodu. Tak jak w Figmie trzyma uporządkowane strony i sekcje, tak w Cursor trzyma uporządkowanych agentów. Każdy agent równa się jedno zadanie.

Korzyści z wielu agentów:

Łatwiejsze cofanie zmian – gdy chcesz cofnąć jedną zmianę, ale zachować 19 innych
Lepsze śledzenie – każdy commit precyzyjnie opisuje co się zmieniło
Praca równoległa – kilka agentów dla różnych zadań jednocześnie
Łatwe referencje – „użyj tego co zrobiliśmy w tamtym agencie”
Izolowane zatwierdzenia zmian – precyzyjne commity bez ryzyka utraty późniejszej pracy

JB opowiada o sytuacji, gdy pracował dwa dni w jednym chacie. Zrobił 20 różnych rzeczy. Potem chciał cofnąć jedną zmianę, ale zachować pozostałe 19. Nie dało się tego łatwo zrobić. Długi kontekst w jednym chacie sprawia, że cofnięcie jednej zmiany jest niemal niemożliwe bez utraty całej późniejszej pracy.

Z osobnymi agentami każdy commit jest precyzyjnie opisany. JB nauczył się podstaw git workflow z praktyki. Branch, commit, PR – te pojęcia stały się naturalne przez używanie narzędzia. Nie musiał studiować teorii, po prostu zobaczył jak to działa.

Narzędzia wspierające przepływ pracy

Figma MCP

JB czasem zaczyna w Figmie – szczególnie przy zupełnie nowych UI. Następnie kopiuje link do frame’a i wkleja do Cursora. „Dodaj to na górze canvas w designerze” – i Figma MCP przenosi projekt do kodu.

Demo pokazuje toolbar przeniesiony z Figmy. Cursor odtwarza layout, kolory, rozmiary. Dostaje 90% wyniku od razu. Reszta to drobne poprawki.

Pro tip: Jeśli dodasz w prompcie „użyj icon buttons z naszego design systemu”, Cursor automatycznie podmieni komponenty na te z biblioteki. Wtedy interaktywność przychodzi za darmo – hover states, ripple effects, wszystko już jest.

Chrome Dev Tools MCP

Największy problem z AI? Czasem mówi, że coś zrobiło, a tak naprawdę nie działa. JB nazywa to „gaslighting”.

Chrome Dev Tools MCP daje Cursorowi możliwość weryfikacji. Agent może wejść do przeglądarki, zrobić screenshot, przetestować funkcjonalność. Weryfikuje sam siebie zamiast zgadywać.

Stagewise

To floating widget w przeglądarce. JB może wskazać konkretny element na stronie i powiedzieć „zmień ten dropdown na ghost button.”

Stagewise wykrywa dokładnie o który element chodzi – używa inspektora, znajduje ścieżkę w kodzie, opisuje to Cursorowi. Nie trzeba wyjaśniać „na stronie site access, w kolumnie role, w trzecim wierszu…” Wystarczy pokazać.

JB używał tego dużo na początku. Teraz mniej – Cursor się poprawił w rozumieniu opisów tekstowych. Mimo to dla precyzyjnych zmian to wciąż pomocne narzędzie.

Dyktacja AI

JB ma zmapowaną dyktację na prawy command. Naciśnięcie klawisza włącza narzędzie (prawdopodobnie Aqua). Mówi, co chce zrobić. AI usuwa „eee”, „yyy”, poprawia składnię, formatuje.

Dla JB to po prostu szybsze niż pisanie. Mniej literówek. Bardziej naturalne. Szczególnie przy długich, złożonych requestach można po prostu myśleć na głos i opisywać problem w konwersacyjny sposób, a nie formułować go inżynierskim językiem.

JB używa tego samego narzędzia wszędzie gdzie jest text box – Slack, email, Cursor. To stało się naturalną częścią jego przepływu pracy.

Komunikacja ze stakeholderami przez AI

Gdy JB potrzebuje przemyślanej odpowiedzi, transkrybuje swoje myśli i wkleja do ChatGPT z kontekstem. Pokazuje jak to robił przygotowując się do tego podcastu.

Organizacja w ChatGPT

JB trzyma wszystko w folderach projektowych. Ma projekt „Sneak Peek”, projekty dla różnych funkcji nad którymi pracuje. Każdy projekt zachowuje kontekst rozmów związanych z tym tematem.

Proces dopracowania wiadomości:

Transkrybujesz swoje myśli przez dyktację
Wklejasz do ChatGPT z pełnym kontekstem sytuacji
Dostajesz pierwszą wersję odpowiedzi
Iterujesz: „Make it Slack-ready”, „Skróć to”, „Usuń em-dash”
Ostateczna wersja zachowuje twoje myśli, ale lepiej sformułowane

Według JB kluczowe jest, że AI nie zastępuje myślenia – to narzędzie do dopracowania. Orkiestracja, kontekst, decyzje – to wciąż człowiek. AI tylko pomaga wyartykułować myśli lepiej.

JB przyznaje, że kiedyś przejmował się, czy ludzie zauważą że używa ChatGPT. Teraz już nie. Wszyscy to robią. Ważniejsze jest, żeby output brzmiał jak ty i zawierał twoje przemyślenia. Człowiek w pętli jest kluczowy – to widać czy coś zostało prowadzone przez AI czy AI było tylko narzędziem.

Skąd brać inspirację – Mobin jako biblioteka wzorców

JB polega na Mobin – narzędziu z katalogiem aplikacji mobilnych i webowych. Setki przykładów best-in-class UI, podzielone na kategorie, flows, elementy.

Szuka np. „account settings”. Dostaje dziesiątki przykładów – Airbnb, Notion, Linear. Może zobaczyć jak różne firmy rozwiązują te same problemy. Toggles, nested navigation, organizacja sekcji.

Jak JB używa Mobin:

Analizuje wzorce z różnych firm dla tego samego typu UI
Zwraca uwagę na best practices (toggles, nested navigation, organizacja)
Wykonuje competitive analysis – co robi konkurencja, jakie trendy
Ocenia co można wykorzystać vs co wymaga adaptacji do kontekstu

Nie chodzi o kopiowanie. Chodzi o punkt wyjścia. Większość rzeczy nie wymaga reinwencji. Access control, settings, tabele z danymi – są sprawdzone wzorce.

Mobin był szczególnie pomocny wcześniej w karierze JB. Teraz wciąż używa go do studiowania industry standards, jednak ma już więcej intuicji kiedy odstąpić od wzorców.

JB podkreśla – trzeba wiedzieć kiedy odstąpić od wzorców. To co działa w Airbnb może nie działać w Webflow przez inny kontekst, innych użytkowników, inne use cases.

Jak AI zmienia proces designu produktów

Według JB jesteśmy w momencie, gdzie wszyscy próbują to ogarnąć. Niektóre zespoły pozwalają designerom pushować kod bezpośrednio do produkcji.

AI podnosi standardy craftu i nagradza ciekawych ludzi. Ci, którzy chcą eksperymentować, pchać granice możliwości, testować nowe rzeczy – oni zobaczą największe rezultaty. Krajobraz zmienia się błyskawicznie. Nowe narzędzia co tydzień. Nowe możliwości co miesiąc.

Ciekawość będzie najważniejszą cechą. Ci którzy są chętni do eksploracji, pushing limits, testowania nowych rzeczy – zobaczą nieproporcjonalnie duże rezultaty.

Mentalny przełącznik w myśleniu o designie

Proces wymaga, aby projektant dokonał „mentalnego przełącznika” – przestaje myśleć o warstwach i grupach w Figmie, a zaczyna myśleć o strukturach kodu. To fundamentalna zmiana w podejściu do pracy.

Największa zmiana? Zbliżenie do rzeczywistego doświadczenia. Figma jest odłączona od produktu. Tworzysz piękny spec, oddajesz developerom, widzisz w prodzie – i myślisz „gdybym tylko mógł zmienić tę jedną rzecz.”

Co się zmienia w podejściu do designu:

Praca bezpośrednio w medium – brak translacji między narzędziem a rzeczywistością
Odkrywanie detali podczas prototypowania – pointer events, focus states, theming
Skupienie na wykończeniu zamiast na podstawowej funkcjonalności
Uczenie się języka software development przez praktykę
Prawdziwy design dzieje się w produkcie – gdy widzisz rzeczywiste doświadczenie, wtedy projektujesz naprawdę

JB wiele razy w karierze oddawał piękny, szczegółowy spec. Developerzy implementowali. A potem w produkcie widział efekt i myślał „gdybym tylko mógł zmienić tę jedną małą rzecz.” Ale było już za późno.

Gdy projektujesz w Cursor, to co tworzysz jest tym co użytkownik doświadcza. Nie ma translacji. Nie ma utraty detalu w przekazaniu.

JB nauczył się myśleć o rzeczach, o których nigdy by nie pomyślał w statycznych makietach. Pointer events. Focus states. Theming. Browser interactions. Debugowanie. To szczegóły, które składają się na dobre UX.

Gdy wszystkie podstawowe interakcje działają out of the box, możesz skupić się na detalu. Na wykończeniu. Na rzeczach, które robią różnicę.

Praktyczne prompty z sesji JB

Prompty do Cursor

Dodawanie prostej kolumny:

On the site access page, after the CMS access column, add a new column 
for last active to indicate when the user was last active on the site.

Kiedy użyć: Proste zmiany struktury UI, gdzie wiesz dokładnie co chcesz i gdzie.

Złożona funkcjonalność z modalem:

On the right side of the site access title on the page, add a button 
to invite a new user. When the user clicks the button, open a modal 
that lets you add an existing user from the workspace to the site access 
table. By default their access should be all.

Kiedy użyć: Gdy budujesz złożoną interakcję z wieloma elementami – lepiej opisać cały przepływ w jednym prompcie.

Z Figma MCP – przenoszenie UI:

Add this to the top of the canvas on the designer
[paste Figma link]

Kiedy użyć: Gdy masz gotowy design w Figmie i chcesz go szybko przenieść do kodu.

Z instrukcją o design systemie:

Use icon buttons for all the different desktop and devices and also 
icon buttons for the undo and redo buttons

Kiedy użyć: Gdy chcesz upewnić się, że Cursor użyje konkretnych komponentów z Twojego design systemu zamiast tworzyć nowe.

Z Stagewise – bezpośrednie wskazanie elementu:

Let's turn this dropdown into a ghost button
[wskazujesz element na stronie przez Stagewise]

Kiedy użyć: Gdy chcesz zmienić konkretny element na stronie bez opisywania całej ścieżki do niego.

Naturalny, problemowy sposób komunikacji:

Mamy problem z tym tagiem. Chcę, żeby cały obszar był klikalny, 
ale równocześnie, kiedy użytkownik najedzie myszą, ma pokazać się 
dymek podpowiedzi. Załatw to.

Kiedy użyć: Gdy opisujesz problem w naturalny sposób, pozwalając AI na znalezienie rozwiązania.

Prompty do ChatGPT

Dopracowanie komunikacji ze stakeholderami:

Me and the PM were just talking about CMS collection access and one 
of the things that we wanted to build was the invitation flow and do 
we load all sites or do we basically only load the private sites and 
only allow CMS restrictions on those sites? I don't know. One of the 
things that I'm worried about of not loading all the sites is that we 
don't have enough visibility. Help me craft this into a more persuasive 
message that I can share to my PM so that we can make a more informed 
decision.

Kiedy użyć: Gdy masz przemyślenia, ale potrzebujesz pomocy w uporządkowaniu ich w przekonującą wiadomość.

Iteracja na odpowiedzi:

Make it Slack-ready and let's condense this a little bit. 
It's a little bit too long at the moment.

Kiedy użyć: Po otrzymaniu pierwszej wersji – możesz iterować aż dostaniesz format i długość którą chcesz.

Kluczowe zasady promptowania według JB:

1. Bądź konkretny o lokalizacji Zamiast „dodaj kolumnę” → „na stronie site access, po kolumnie CMS access, dodaj kolumnę”

2. Opisz domyślne stany „By default their access should be all” – to eliminuje pytania uzupełniające

3. Wspominaj o komponentach z design systemu „Use icon buttons” zamiast pozwalać AI wymyślać własne rozwiązania

4. Dla złożonych zadań – opisz cały przepływ Nie dziel na mikro-kroki, opisz całą interakcję naraz

5. Używaj dyktacji dla długich promptów JB mówi zamiast pisać – szybsze i bardziej naturalne dla złożonych requestów. Możesz myśleć na głos i opisywać problem konwersacyjnie, zamiast formułować go inżynierskim językiem.

6. Iteruj zamiast dążyć do perfekcji za pierwszym razem Pierwsza wersja to starting point, potem dopracowujesz

Polecane narzędzia

Do prototypowania:

Cursor – główne narzędzie do AI-powered prototypowania
Figma MCP – integracja Figmy z Cursor
Chrome Dev Tools MCP – weryfikacja zmian przez AI
Stagewise – precyzyjne wskazywanie elementów UI

Do pracy:

Aqua (lub podobne) – AI dictation tool
ChatGPT – dopracowanie komunikacji

Do inspiracji:

Mobin – biblioteka wzorców UI z aplikacji webowych i mobilnych

Kluczowy insight

Design dzieje się w produkcie, nie w narzędziu

Standardowo myślimy: Design to to, co tworzymy w naszym design tool (Figma, Sketch). Gdy spec jest gotowy, design jest skończony – reszta to tylko implementacja.

W praktyce okazuje się, że: Prawdziwy design dzieje się dopiero gdy widzisz rzecz w jej naturalnym środowisku. JB wielokrotnie oddawał perfekcyjne speci, a potem w produkcie myślał „gdybym tylko mógł zmienić tę jedną rzecz.” To nie była wina implementacji – to była wada procesu. Projektował OBRAZ produktu, nie SAM produkt.

Dlaczego to jest istotne: Gdy projektujesz w narzędziu do projektowania, tracisz wszystkie subtelności medium. Focus states. Pointer events. Jak naprawdę działa hover. Jak czuje się klikanie. To nie są detale – to fundamenty doświadczenia użytkownika. Cursor pozwala projektować bezpośrednio w przeglądarce, więc odkrywasz te rzeczy podczas projektowania, nie po fakcie.

Test na jutro: Następnym razem gdy budujesz prototyp interakcji w Figmie, zamiast dodawać kolejne połączenia między frame’ami, spróbuj przenieść ten jeden komponent do Cursor i zobacz ile nowych detali odkryjesz gdy rzecz faktycznie działa w przeglądarce.

Dodatkowy insight: Krótki kontekst to czysty kod

Standardowo myślimy: Używamy jednego, długiego czatu AI, by agent miał pełny kontekst naszej pracy, co zwiększa jego „inteligencję” i eliminuje powtarzanie informacji.

W praktyce okazuje się, że: Tworzenie osobnego agenta AI dla każdego zadania (jak strony w Figmie) pozwala na higienę pracy, ułatwiając izolowane zatwierdzenia zmian i precyzyjne wycofywanie błędnych zmian. W przeciwnym razie długi kontekst w jednym chacie sprawia, że cofnięcie jednej zmiany jest niemal niemożliwe bez utraty całej późniejszej pracy.

Dlaczego to jest istotne: Przekształca to agenta AI z ciągłej rozmowy w narzędzie do jednorazowego, weryfikowalnego zadania, co jest kluczowe dla profesjonalnego zarządzania kodem i wersjonowania.

Test na jutro: Następnym razem gdy rozpoczniesz nowe zadanie projektowe, zamiast kontynuować istniejący czat z AI, spróbuj otworzyć zupełnie nową instancję/agenta i sprawdź, jak to ułatwia finalne zatwierdzenie zmian lub wycofanie pomysłu.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: Sneak Peek – rozmowa z JB z Webflow