Ryo Lu (Cursor): Jak AI kończy 15-letni rozłam między designerami a developerami #EN352

Poniższy tekst stanowi notatki z podcastu AI + a16z. Wszystkie przedstawione obserwacje, przemyślenia i wnioski pochodzą od Ryo Lu, Head of Design w Cursor. Moją rolą jest jedynie uporządkowanie i przekazanie tych treści.

TL;DR

Przez ostatnie 15 lat role w tworzeniu oprogramowania rozdzieliły się – designerzy w Figmie, PM-owie w Google Docs, inżynierowie w IDE. Narzędzia AI takie jak Cursor odwracają jednak ten trend.
W tradycyjnym procesie trzeba czekać rok na realizację 20% wizji. Z kolei Cursor daje 60-70% na pierwszy strzał, a następnie umożliwia szybką iterację.
Pojęcie „gustu” jest zdaniem Lu przereklamowane – LLM widział wszystko, ale nie ma opinii. W rezultacie bez ludzkiej decyzji powstaje bezwartościowa treść.
Rola twórcy ewoluuje w kierunku kuratora – to człowiek musi wskazać maszynie, co jest wartościowe, a co należy odrzucić.
Design to nie tylko estetyka, lecz także architektura i koncepcje – najprostszy możliwy system dla największej liczby ludzi.
Dedykowane narzędzia tworzą silosy, natomiast uniwersalne systemy jak Notion czy Cursor dają elastyczność kosztem początkowej krzywej uczenia.
Fundamentalne koncepcje interfejsów nie zmieniły się od 1984 roku – okna, ikony, desktop pozostają te same.

Kontekst

Ryo Lu zbudował swoją karierę przechodząc przez Asana i Notion, by ostatecznie objąć stanowisko Head of Design w Cursor. W rozmowie dla podcastu AI + a16z dzieli się obserwacjami na temat ewolucji ról w tworzeniu oprogramowania. Centralnym tematem dyskusji jest pytanie: co się dzieje, gdy AI zaciera granice między designerem a developerem?

Od fragmentacji do unifikacji

Przez ostatnie 15 lat sztuka tworzenia oprogramowania uległa fragmentacji. Jak zauważa Lu, każda rola dostała własne narzędzie i własny język. Designerzy utknęli w Figmie, wcześniej w Sketch, a jeszcze wcześniej w osobnych plikach. PM-owie z kolei piszą dokumenty i prowadzą spotkania w Google Docs. Analitycy danych pracują w jeszcze innych narzędziach. W efekcie wszyscy funkcjonują w silosach, a później trzeba wymyślać procesy, żeby to wszystko spiąć.

Lu opisuje własne doświadczenie z tym modelem. Kiedy przyjechał do USA, dostał tytuł „product designer” i przestał kodować. Robił makiety oraz prototypy, po czym czekał latami na ich realizację. Czasem projekty nie realizowały się wcale, a czasem kończyły jako film na YouTube.

Tak jednak nie było zawsze. Lu odwołuje się do wczesnej ery komputerów, gdy nie istniały jeszcze tytuły stanowisk. Ludzie określani jako „researchers” projektowali architekturę niskiego poziomu, budowali UI i wyświetlali rzeczy na ekranie – robili wszystko. Jedna osoba, dwie, pięć. Nie było też tylu ograniczeń ekonomicznych – zespoły były finansowane i nie musiały od razu zarabiać. Dzięki temu mogły tworzyć produkty całościowo.

Obecnie wszystko rozbija się przez optymalizację kosztów i procesów. Ludzie zostają zamknięci w wąskich obszarach problemowych, choć w rzeczywistości wszystko jest połączone. Lu stwierdza wprost: gdzieś po drodze zgubiliśmy pewien ideał – ludzie myślą za dużo o problemach technicznych, designerskich i finansowych, zamiast o całości i o tym, co robimy lepszym dla użytkowników.

W miarę jak zespół rośnie, produkt zaczyna odzwierciedlać strukturę organizacji. Różne role zaczynają ze sobą rywalizować – designerzy mają rację, inżynierowie mają rację, PM-owie też mają rację. Istnieje jednak wspólna prawda, czyli kod.

Narzędzia AI takie jak Cursor zmieniają tę dynamikę. Nie trzeba już rozumieć każdej warstwy tworzenia oprogramowania, żeby coś zbudować. Można zacząć od pomysłu – nawet nieco mglistego – przekazać go agentowi i otrzymać coś działającego. Lu postrzega wszystkich – designerów, PM-ów, inżynierów – jako twórców oprogramowania. Tak właśnie zaczynaliśmy i teraz do tego wracamy.

60-70% na pierwszy strzał

W tradycyjnym procesie designer tworzy makiety w Figmie, dzieli się nimi, a PM pisze dokumentację. Następują kolejne spotkania z udziałem kolejnych osób. Może rok później design trafia do produkcji, ale stanowi już tylko 20% pierwotnej wizji.

Figma zbliżyła ten proces – umożliwiła współpracę wokół jednego artefaktu, gdzie wszyscy mogą wnosić swój wkład i prototypować. Cursor idzie jednak jeszcze dalej, ponieważ artefakty są funkcjonalne i działające.

W przypadku Cursor cykl kurczy się dramatycznie. Lu tłumaczy to następująco: masz pomysł, przekazujesz go agentowi i dostajesz około 60-70% na pierwszy strzał. Wynik jest niedoskonały, nie do końca taki jak chciałeś, ale proces iteracji staje się bardzo szybki.

W miarę jak modele się rozwijają, agenci komunikują się z kolejnymi narzędziami. Lepiej rozumieją wizualia, mogą czytać Figmę oraz Notion – pomysły, dokumenty, notatki ze spotkań. Co najważniejsze, znają kod, który stanowi źródło prawdy i materiał do budowania oprogramowania.

Agent zna trzy wymiary czasu

Lu konceptualizuje możliwości agenta w trzech wymiarach:

Teraźniejszość – co jest w bazie kodu, jakie zadania i projekty są aktualnie realizowane, informacje zwrotne z realnego świata
Przeszłość – zgromadzona wiedza, preferencje zespołu, ewolucja bazy kodu
Przyszłość – planowanie, wizja, większe idee które dopiero powstają

Wszystko to można realizować za pomocą jednego narzędzia i jednego agenta, choć dla każdego użytkownika lub zespołu może to przybrać inną formę.

Dlaczego „gust” to złe słowo

Wielu mówi o „guście” jako kluczowej kompetencji w erze AI. Lu jednak otwarcie przyznaje, że nie lubi tego słowa, ponieważ uważa je za zbyt mgliste.

Jego interpretacja jest bardziej precyzyjna. To, co nazywamy gustem, stanowi rezultat eksploracji opcji – trzeba widzieć dużo, analizować przeszłość i rozumieć, jak ludzie rozwiązywali podobne problemy wcześniej. Chodzi o łączenie rzeczy z przeszłości z tym, co chcemy zrobić teraz. Z czasem budują się preferencje oraz granice tego, co jest dobre, piękne i właściwe.

Problem z LLM polega na tym, że widział wszystko, ale nie ma opinii. Lu ujmuje to obrazowo: model myli się, myśląc że ludzie wszędzie lubią fioletowe gradienty. LLM dobrze radzi sobie z tworzeniem podstawy – robi to szybko i solidnie. Warstwa na wierzchu, czyli selekcja tego co jest dobre, pozostaje jednak decyzją człowieka. Bez tej opinii powstaje bezwartościowa treść – zjawisko, które Lu określa mianem cyfrowej przeciętności.

W tym kontekście rola twórcy ewoluuje w kierunku kuratora. To człowiek musi wskazać maszynie, co jest wartościowe, a co należy odrzucić, opierając się na znajomości kontekstu i historii.

Cursor wprowadził tryb planowania. Wpisujesz prompt bez wypełniania szczegółów, a agent buduje specyfikację. Możesz dodawać detale i zmieniać co chcesz. Lu podkreśla jednak, że nie działa dawanie agentowi czegoś długiego i niespecyficznego z oczekiwaniem dokładnie takiego wyniku, jaki sobie wyobraziłeś.

Design to nie tylko piksele

Lu sprzeciwia się sprowadzaniu designu do estetyki. Jego definicja jest znacznie szersza – design obejmuje architekturę, koncepcje oraz to, czym jest produkt lub firma.

Notion stanowi dobry przykład: to produkt czysto koncepcyjny, gdzie każda koncepcja została zaprojektowana przez człowieka. W Notion istnieją tak naprawdę tylko bloki, strony, bazy danych i workspace. Wszystko działa wokół tych koncepcji, a na każdej warstwie znajduje się reprezentacja tych samych elementów – od UI i marki na górze, przez architekturę kodu frontendowego, po sposób przechowywania obiektów i ich wzajemne relacje.

Oprogramowanie okazuje się właściwie proste, jeśli patrzeć na same koncepcje. Design to szukanie najlepszej konfiguracji i najprostszego stanu dla wszystkich. Nie chodzi o 6-pikselowy czy 4-pikselowy border radius, lecz o zaprojektowanie najprostszego systemu z najmniejszą liczbą koncepcji i ścieżek kodu, który robi najwięcej dla największej liczby ludzi.

Ograniczenia jako przyjaciel kreatywności

Rozmówczyni pyta Lu: skoro więcej ograniczeń często pomaga kreatywności, a teraz mamy bardziej otwarty świat dzięki AI, jak to pogodzić?

Lu odpowiada, że największym ograniczeniem jest prostota. Istnieje limit tego, ile koncepcji można pokazać danej osobie w danym momencie – to ograniczenie poznawcze, które się nie zmienia. Jest też ograniczenie przestrzeni: okno Cursor może być szerokie lub wąskie. Gdy je zwężasz, zaczynasz redukować elementy i priorytetyzować to, co pokazać.

To prowadzi do istotnej zmiany w roli designera. Nie chodzi już o decydowanie, gdzie umieścić przyciski i zamrażanie tego układu. Chodzi raczej o współdzielone koncepcje i mechanizmy tej samej rzeczy, które mogą przyjmować różne formy. Można eksponować sposoby personalizacji dla użytkowników.

Designer myśli teraz o tym: jakie są najważniejsze koncepcje? Jak się do siebie odnoszą na każdej warstwie? Jakie powinny być domyślne ustawienia dla 80% ludzi? Co powinno stanowić najprostszy stan aplikacji? Dopiero potem można różnicować dla różnych użytkowników – na drugiej warstwie eksponować funkcje dla zaawansowanych.

Dedykowane narzędzia tworzą silosy

Lu przedstawia dwie filozofie budowania oprogramowania. Pierwsza to podejście zorientowane na użytkownika: zaczynasz od problemu, identyfikujesz grupę ludzi i budujesz specyficzne rozwiązania. Jest łatwiejsze, ale ogranicza od startu, ponieważ specyficzne rozwiązania działają tylko dla specyficznych ludzi. Żeby rosnąć, trzeba rozbierać wszystko na części i zaczynać od podstawowych koncepcji.

Druga filozofia to podejście systemowe: analizujesz samo oprogramowanie, jego złożoność i szukasz miejsc do optymalizacji, żeby spełnić wymagania lub obsłużyć przypadek użycia. Jest trudniejsze, ale skalowalne.

Lu twierdzi, że dedykowane aplikacje są egoistyczne – izolują ludzi, przepływy pracy i formaty plików, tworząc wyspy.

Asana	Notion
Podstawowe koncepcje: zadania i projekty	Podstawowe koncepcje: bloki, strony, bazy danych
Wszystko musi działać z zadaniami i projektami	Każdy blok to niemal obiekt JSON
Naturalnie ogranicza możliwości	Można robić z tym praktycznie wszystko

Problem uniwersalnych aplikacji polega na tym, że są tak otwarte, iż trudno zacząć. Jeśli użytkownik nie ma cierpliwości, żeby zrozumieć jak działają, może nie dotrzeć do sedna. To wieczne napięcie, które da się jednak rozwiązać lepszym wprowadzeniem i AI, które pomaga.

Cursor jako zestaw narzędzi

Cursor skupia się głównie na profesjonalnych developerach i zespołach, ale przez to ludzie wokół nich też zaczynają przychodzić. Lu przyznaje, że Cursor celowo utrudniał wejście dla nietechnicznych osób. Mimo to przychodzą i naprawdę chcą korzystać z narzędzia.

Przykład bariery: otwierasz Cursor i widzisz trzy przyciski – „Open project”, „connect to SSH”, „clone repo”. Dla początkującego to niezrozumiałe. Co gdyby po prostu dać pusty widok agenta i pozwolić zacząć działać?

Dwa tryby pracy

Lu rozróżnia dwa typy użytkowników w Cursor. Jedni szczycą się tym, że piszą przemyślany i czysty kod – dla nich jest autouzupełnianie, które podpowiada następny krok niemal intuicyjnie. Coraz więcej osób korzysta jednak z agentów, nawet najbardziej profesjonalni programiści zaczynają to robić.

Dla designera przepływ pracy mógłby wyglądać następująco: rozmowa z przeglądarką obok, agent wykonuje edycje w tle, designer podgląda zmiany, może wchodzić w interakcję, wybierać elementy i modyfikować je natychmiast.

Zespół pokrywający słabości

Wizja Lu wygląda tak: zbierz naprawdę dobrych inżynierów infrastruktury, front-endu oraz PM-ów, którzy nie tylko prowadzą spotkania. Daj im to samo narzędzie i tę samą bazę kodu. Mogą wtedy pokrywać swoje słabości i wzmacniać mocne strony, a agent trzyma wszystko razem. Zamiast pytać „gdzie jest twój design?” – wszystko znajduje się w jednym miejscu.

Lu podkreśla, że nie chodzi o tworzenie osobnych produktów ani dzielenie Cursora. To ta sama rzecz, ale różne wstępne konfiguracje i opakowania. Podstawowe koncepcje Cursora – i agentów AI ogólnie – są właściwie proste. ChatGPT agent, Cursor, Replit, v0 czy agent w Notion mają niemal identyczną architekturę i sposób działania.

AI jako uniwersalny interfejs

Lu postrzega AI jako uniwersalny interfejs. Minimum to prompt i odpowiedź, które można ubrać w różne formy – małe pole tekstowe, boczny panel z czatem, zaznaczenie czegoś i działanie na tym. Pod spodem to jednak wciąż to samo: ten sam AI, ten sam agent, ta sama architektura.

Gdyby istniał tylko czat, byłoby to również złe doświadczenie. Użytkownik patrzy na puste pole i musi coś zrobić – zainicjować rozmowę, zadać właściwe pytania. Nowa osoba może spróbować raz, otrzymać wynik który nie odpowiada oczekiwaniom i stwierdzić „to nie dla mnie”.

Trzeba projektować mechanizmy transformacji tego wejścia-wyjścia w formy pasujące do dzisiejszych użytkowników. Przeprowadzić ich przez to, co znają, do czegoś nowego – nie zmuszać do korzystania z narzędzia bez zrozumienia, jak łączy się z ich przepływem pracy.

Lu krytykuje też obecne agenty CLI. Zmuszają do korzystania z małego okienka z małym promptem, gdzie deleguje się wszystko agentowi bez wiedzy o tym, jak rzeczy działają. W Cursor można preferować coś minimalnego, ale można też zacząć kopać głębiej – dostosować agenta, stworzyć własny tryb z preferencjami modelu, narzędziami i promptami, wybrać widok (kod, podgląd, dokumentacja, przeglądarka), zmienić kolory, preferować klawiaturę albo mysz.

Real OS: lekcje z 1984 roku

Lu opowiada o swoim projekcie Real OS. Zaczęło się, gdy odchodził z Notion i chciał zrobić prezent dla zespołu – soundboard z dźwiękami ze spotkań. Zbudował to z Cursor, ale wyglądało okropnie ze standardowymi stylami Tailwind.

Zapytał więc: co gdyby nadać temu bardziej retro wygląd w stylu Mac OS? Agent umieścił aplikację w oknie przypominającym stary Mac OS. Lu dodał kolejne polecenie: dodaj pasek menu. Teraz miał pasek menu i okno. Dlaczego nie zrobić więcej aplikacji i więcej okien? Tak to się zaczęło i nie mógł przestać przez trzy-cztery miesiące.

Interfejsy inspirowane są System 7. Jest w nich dokładność, ale też dodane elementy z przyszłości. Później doszły kolejne motywy: Mac OS X, pierwsza Aqua, Windows 95 i XP. Przełączając między nimi, każdy czuje się autentycznie, choć pod spodem to ta sama rzecz.

Lu chce tym przekazać pewną wiadomość: robimy prawie to samo w kółko od samego początku. Przenosimy te same koncepcje i wzorce przez dekady, wciąż w nich żyjemy. Okna, ikony, desktop – nic się naprawdę nie zmieniło.

Jak Lu kultywuje inspiracje

Lu nie ma rutyny. Nie siedzi w Figmie cały dzień robiąc makiety, lecz robi wszystko naraz. Może myśleć o dłuższym problemie albo po prostu pisać – lubi wyjść z biura na spacer, wziąć telefon ze stroną w Notion i zacząć pisać w punktach. Robi szkice, buduje prototypy w kodzie.

Dużo inspiracji przychodzi z niezmuszania się i zostawiania pustej przestrzeni, żeby rzeczy mogły się uformować. Pomaga też patrzenie na wszystko, nie tylko oprogramowanie – print design, graphic design, motion, filmy, muzyka, sztuka. Natura również stanowi źródło inspiracji. Lu ma wykształcenie biologiczne i widzi podobieństwa w tym, jak wiele warstw można zbudować i jak ze sobą interagują.

Patrzenie w przeszłość okazuje się szczególnie pomocne. Projekt Real OS zaczął się od tego, że Lu kupił kilka starych Maców i iPodów, bawił się nimi i chciał odtworzyć te uczucia.

Jak Lu rozmawia z AI – przykłady promptów

W rozmowie Lu przytacza konkretne przykłady komunikacji z agentem. Nie stosuje skomplikowanej inżynierii promptów, lecz naturalny język i metodę małych kroków.

Eksploracja wizualna Polecenie: „Zrób tego cztery warianty” Kiedy stosować: Gdy element interfejsu jest już wybrany, ale brakuje pewności co do detali. Zamiast rysować ręcznie, zleca się AI wygenerowanie opcji do porównania.

Zmiana stylu Polecenie: „A gdybyśmy zrobili to bardziej w stylu retro Mac OS?” Kiedy stosować: Gdy funkcjonalność już działa, ale chcemy całkowicie zmienić charakter wizualny bez przepisywania logiki.

Iteracyjne budowanie Polecenie: „Dodaj pasek menu na górze” Kiedy stosować: Budowanie metodą małych kroków. Zamiast opisywać całą aplikację w jednym poleceniu, dodaje się elementy jeden po drugim.

Edycja kontekstowa Polecenie: „Zamień to na coś innego” Kiedy stosować: Podczas pracy z podglądem na żywo, wskazując konkretny element w przeglądarce.

Skalowanie pomysłu Polecenie: „Dlaczego by nie zrobić po prostu więcej aplikacji i więcej okien?” Kiedy stosować: W momencie przełomowym, gdy prosty prototyp działa dobrze i zapada decyzja o rozwinięciu go w pełny system.

Lista kontrolna: Jak uniknąć bezwartościowej treści

Przed promptowaniem:

Mam opinię na temat tego, co jest „dobre” w tym kontekście
Wiem czego NIE chcę (granice)
Prompt jest konkretny, nie mglisty i długi

Podczas pracy z agentem:

Iteruję szybko zamiast czekać na perfekcyjny pierwszy strzał
Używam trybu planowania gdy nie mam szczegółów – agent buduje specyfikację, ja modyfikuję
Podglądam co agent robi (nie deleguję wszystkiego bez kontroli)
Buduję metodą małych kroków zamiast opisywać wszystko w jednym poleceniu

Proces twórczy:

Zaczynam od pisania – myślenie w punktach i słowach to najczystsza forma projektowania
Pozwalam myślom się uformować z dala od ekranu (spacer, przerwa)
Prototypuję w kodzie zamiast rysować statyczne obrazy
Unikam przesuwania pikseli na wczesnym etapie – to często strata czasu

Myślenie systemowe:

Zdefiniowałem podstawowe koncepcje (co jest czym?)
Mam domyślne ustawienia dla 80% użytkowników
System jest tak prosty, jak to możliwe

Długoterminowo:

Eksploruję opcje – widzę dużo różnych rozwiązań
Szukam inspiracji poza oprogramowaniem (druk, natura, biologia, sztuka)
Patrzę w przeszłość – fundamentalne wzorce pozostają niezmienne od dekad
Buduję własne preferencje i granice z czasem

Kluczowe spostrzeżenia

Im więcej AI wie, tym bardziej potrzebuje Twojej opinii

Standardowo myślimy: AI widział miliony przykładów, więc wie co jest dobre. Wystarczy dać mu kontekst i szczegółowy prompt, a dostanę świetny wynik.

W praktyce okazuje się, że: LLM widział wszystko – i właśnie dlatego nie ma opinii. Bez wyraźnej decyzji co jest dobre, a co nie, AI uśrednia wszystko co widział. Im potężniejszy model, tym bardziej potrzebuje Twoich granic.

Dlaczego to jest istotne: Odwraca to dominującą narrację „AI zastąpi Twój gust” na „AI wymaga więcej Twojego gustu niż kiedykolwiek”. To nie jest kwestia lepszych promptów czy więcej kontekstu, lecz przyjścia z gotową opinią, zanim w ogóle otworzysz okno rozmowy.

Test na jutro: Następnym razem gdy będziesz promptować AI, zamiast opisywać czego chcesz, zacznij od tego czego NIE chcesz. Napisz 2-3 rzeczy które byłyby „złe” w tym kontekście i sprawdź czy wynik jest bliższy Twojej wizji.

Pułapka projektowania pod użytkownika

Standardowo myślimy: Należy zdefiniować konkretną personę użytkownika i zbudować narzędzie rozwiązujące jej specyficzny problem (podejście zorientowane na użytkownika).

W praktyce okazuje się, że: Takie podejście szybko ogranicza rozwój produktu, ponieważ ludzie i ich problemy ewoluują. Narzędzia ściśle dopasowane do konkretnej grupy stają się z czasem zamkniętymi silosami, wymagającymi ciągłego dodawania nowych funkcji.

Dlaczego to jest istotne: Najbardziej trwałe produkty (jak Notion czy Excel) nie są projektowane pod konkretny zawód. Są projektowane jako systemy abstrakcyjnych jednostek (blok, komórka, kod), które pozostają neutralne względem użytkownika.

Test na jutro: Planując nowe rozwiązanie, zamiast pytać „Czego potrzebuje użytkownik?”, zadaj pytanie: „Jaka jest najprostsza, uniwersalna jednostka, którą użytkownik sam będzie mógł wykorzystać do rozwiązania swojego problemu?”.

Ten wpis stanowi część 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ć. Oryginalne źródło: AI + a16z Podcast – Ryo Lu (Cursor): AI Turns Designers to Developers