Poniższy tekst stanowi zbiór notatek z rozmowy prowadzonej w podcaście Dive Club z Drew Wilsonem – założycielem Opacity i doświadczonym founderem. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą bezpośrednio od rozmówców i zostały zaczerpnięte z oryginalnej dyskusji.

TL;DR

Tradycyjny model pracy designera (projektowanie → handoff → implementacja) szybko staje się przestarzały
Designerzy, którzy spędzają miesiąc na projekcie i oczekują, że zespół go przepisze w kodzie, mogą wkrótce nie być potrzebni
AI podnosi baseline jakości designu z 5/10 do 8/10, zmniejszając przestrzeń dla unikalności
Paradoks: obecnie musisz rozumieć kod, jednak przyszłe narzędzia (jak Opacity) pozwolą dostarczać working code bez głębokiej znajomości engineeringu
Wilson zbudował Loupe bez otwierania Figmy nawet raz
AI agents mogą zastąpić pracę zespołu siedmiu inżynierów
Software design ma tylko 30-40 lat – być może osiągamy limit możliwości dla desktop i mobile

Koniec handoffu – design i kod stają się jednym

Wilson przedstawia wizję świata, w którym nie istnieje coś takiego jak „przekazanie projektu do wdrożenia”. Projektanci płynnie poruszają się w kodzie, zaś granica między designem a engineeringiem znika. Według założyciela Opacity, ten świat jest bliżej niż mogłoby się wydawać, ponieważ technicznie możliwe jest już stworzenie pojedynczego źródła prawdy, gdzie separacja między designem a inżynierią przestaje istnieć.

Kim jest Drew Wilson i dlaczego warto poznać jego perspektywę?

Wilson przeszedł przez różne modele budowania firm. Przez większość kariery bootstrapował projekty bez zewnętrznego finansowania. W 2016 roku podjął pierwszą rundę finansowania dla już działającej firmy, którą następnie sprzedał do GoDaddy – stała się ich platformą e-commerce. Później założył Letter, bank wspierany przez Y Combinator, który prowadził przez cztery lata.

Obecnie buduje Opacity (narzędzie łączące design z kodem) oraz Loupe (zaprojektowany w 100% bez Figmy). Pracuje zarówno jako designer jak i engineer przez prawie 30 lat w każdej z tych ról, a dodatkowo zarządzał zespołami przez ostatnie 15 lat, co daje mu unikalną perspektywę z obu stron barykady.

Konkretny ból, który napędza rewolucję w narzędziach

Wilson opisuje bardzo specyficzne uczucie towarzyszące osobom łączącym obie role. Jeśli jesteś tylko designerem, skończenie projektu to motywujące doświadczenie – patrzysz na efekt pracy i ciekawie czekasz, czy implementacja będzie tak dobra jak projekt.

Jednak gdy jesteś także engineerem, wiesz że większość pracy jest dopiero przed tobą. Design to dosłownie tylko punkt startowy – ładny obrazek, za którym nie stoi żadna prawdziwa praca. Wilson mówi wprost: ból pojawia się natychmiast po skończeniu projektu. Z jednej strony designer w tobie cieszy się z efektu, ale zaraz potem przychodzi przytłaczające uczucie dread – świadomość, że teraz musisz zbudować całą pieprzoną rzecz od zera.

Właśnie to uczucie Wilson chce wyeliminować budując Opacity.

Brutalna prawda: oczekiwania wobec designerów się zmieniły

Wilson nie owija w bawełnę. Jego przesłanie jest jasne i może boleć. Jeśli nadal funkcjonujesz w przekonaniu, że miesięczny cykl projektowy zakończony przekazaniem do implementacji jest akceptowalny, czeka cię niemiła niespodzianka. Takie podejście przestaje być przyjmowane przez zespoły, dlatego długie cykle projektowe bez implementacji tracą sens – tworzenie artefaktów designerskich, które trzeba przepisać, to marnotrawstwo.

Wilson zauważa także ciekawą prawidłowość: w większości firm zespoły designerskie są mniejsze od zespołów inżynieryjnych. Po zaprojektowaniu UI nie ma już tak wielu czystych artefaktów produktowych do stworzenia, w rezultacie większość pracy design orgu to marketing, nie rozwój produktu.

Według Wilsona, najfajniej zaprojektowane rzeczy to często właśnie elementy marketingowe, nie UI. Dlatego najważniejsza praca w design orgu dla biznesu to właśnie marketing – w ten sposób ludzie dowiadują się o produkcie.

Czy designerzy staną się zbędni?

Niekoniecznie, jednak ich rola radykalnie się zmieni. Wilson widzi dwa równoległe trendy działające w przeciwnych kierunkach.

Trend 1: Kurczenie się przestrzeni dla różnicowania

Przestrzeń dla różnicowania przez design się kurczy, choć jednocześnie staje się bardziej ważna. Szablony, które kiedyś były na poziomie 5 z 10, zbliżają się do świata, gdzie domyślne rozwiązania będą na poziomie 7-8 z 10. W rezultacie pozostaje niewiele miejsca na stworzenie czegoś naprawdę unikalnego.

Trend 2: Eksplozja popytu na uniqueness

Jest jednak druga strona medalu. Skoro budowanie software’u staje się tańsze, każdy będzie chciał coś zbudować i być wyjątkowy. Tam właśnie jest miejsce dla designu.

Wilson używa analogii do świata templates. Od 20 lat istnieją szablony dla WordPress, Squarespace czy Framer. Ludzie nadal tworzą biznesy budując template, a mimo to inni nadal płacą za custom sites. Dlaczego? Po prostu natura bycia człowiekiem polega na tym, że chcesz być unikalnym płatkiem śniegu – chcesz pokazać, że jesteś inny, więc chcesz żeby twoja strona i biznes wyglądały trochę inaczej.

Tak samo będzie z AI i komponentami. Zawsze będzie popyt na uniqueness, zwłaszcza gdy firmy rosną. Wilson spekuluje, że może to oznaczać więcej designerów pracujących jako fractionale – mniej pełnoetatowych stanowisk, ale więcej możliwości dla ludzi, którzy potrafią wnosić unikalną wartość. Być może będzie mnóstwo małych firm zamiast kilku gigantów z ogromnymi zespołami.

Software design to bardzo młoda branża – może osiągamy limit?

Wilson zwraca uwagę na coś fundamentalnego: ta cała branża ma zaledwie 30-40 lat. 15 lat temu to był dziki zachód – nikt nie był pewien jakich przeglądarek używać ani jakiego front-end tech wybierać. Wszystko dopiero się krystalizowało, natomiast teraz wszyscy wylądowali na React i rzeczy zaczynają się stabilizować.

Co ciekawe, Wilson zadaje prowokacyjne pytanie patrząc na najnowsze iOS 26 i macOS 26. Apple zwykle wyznaczało poprzeczkę, którą wszyscy gonili, jednak z tym releasem nie wyszli z najlepszym produktem – wycofali liquid glass tak mocno, że został praktycznie tylko w toggles.

Teraz mamy frosted glass, które w zasadzie jest po prostu pure white. Wilson nie wyobraża sobie, żeby wielu ludzi to naśladowało jak kiedyś naśladowali wszystko od Apple. Pytanie, które zadaje Wilson: czy osiągnęliśmy jakiś limit tego, jak dobry może być design dla desktop i telefonu? Oczywiście będą nowe UI jak Vision Pro czy okulary AR, ale dla tego co mamy teraz – czy jest potrzeba wymyślania czegoś nowego i unikalnego za każdym razem?

Flywheel effect: jak AI prowadzi do standaryzacji

Rozmówcy zauważają istnienie flywheel effect z AI. Wybieramy rzecz, w której modele są najlepsze, ponieważ przyspiesza to budowanie. To z kolei tworzy jeszcze większy popyt na wybranie tej rzeczy, w rezultacie pętla zacieśnia się do punktu, gdzie pojawia się poziom standaryzacji.

Wilson przyznaje, że prawdopodobnie jesteśmy na szczycie krzywej S. Ta perspektywa jest szczególnie wartościowa od kogoś, kto widział już różne cykle w tej branży.

Co konkretnie musisz zmienić w swoim podejściu?

Wilson przedstawia nieco paradoksalną radę, która zależy od narzędzi z jakimi pracujesz.

Jeśli pracujesz dzisiaj z obecnymi narzędziami

Dla budujących design tools jeden z warunków wstępnych to zrozumienie tej przestrzeni i doświadczenie w niej. Jednak kontraintuitywnie – nie możesz być tylko designerem. Na wczesnym etapie, jeśli nie jesteś w stanie wskoczyć w pisanie i rozumienie kodu, Wilson zadaje pytanie: co właściwie robisz?

Dlaczego sama rola designera przestaje wystarczać:

Nie ma już dużo artefaktów designerskich do tworzenia
Nawet w firmach wielkości Figmy, po zaprojektowaniu UI pozostaje niewiele czystej pracy produktowej
Większość design orgu skupia się na marketingu, nie na rozwoju produktu
Praca wymaga bezpośredniego wpływu na kod

Ale w przyszłości z narzędziami jak Opacity

Tutaj Wilson mówi coś zasadniczo innego – i to jest kluczowa zmiana paradygmatu. W przeszłości rada zawsze brzmiała: naucz się engineeringu, żeby rozumieć jak działa budowanie software UI. Teraz jednak Wilson uważa, że nie ma to sensu, ponieważ prawdopodobnie nigdy nie będziesz tego używał w przyszłości.

Dlaczego? Mówisz teraz engineerom: nie martw się o znajomość Reacta, po prostu użyj AI. I to prawda – będzie to znało lepiej niż ty. Jeśli wszystko czego ci zależy to design i UX rzeczy, coś takiego jak Opacity to dokładnie to czego chcesz, ponieważ nie dostarczasz swoim klientom tylko obrazka – dostarczasz im working code, który już przetestowałeś, do którego już dodałeś eventy, który już zaprototypowałeś i masz działającą rzecz.

Praktyczny przewodnik: jak zacząć budować jako designer?

Mimo zmiany paradygmatu, obecnie – w 2024/2025 roku – wciąż musisz nauczyć się podstaw. Wilson ma zaskakująco praktyczną radę: nie musisz być senior engineerem. Byłoby to bezużyteczne, ponieważ zajęłoby ci kilka dekad, a w tym momencie nie będzie już potrzeby bycia naprawdę dobrym senior engineerem.

Możesz być average engineerem i być równie efektywny z AI. Zawsze będzie potrzeba senior engineers – więc jeśli masz na to ochotę, proszę bardzo, jednak nie musisz.

Twoja ścieżka od designera do buildera

Krok 1: Zmień mindset wobec AI

Przestań myśleć o AI jako o kulturowej czy politycznej wypowiedzi. Oddziel AI jako statement od praktyczności pracy z AI do budowania produktu. LLM to nie przerażająca rzecz – wie tylko to, co mu podamy, dlatego nie wymyśla rzeczy samodzielnie. Jesteśmy zaskoczeni jak potrafi wyciągać informacje pozornie losowo, jednak wszystkie te informacje już mu daliśmy.

Krok 2: Wybierz narzędzie początkowe i zacznij budować

Wilson proponuje konkretną ścieżkę: Claude AI (jeśli chcesz zacząć ostrożnie), Cursor (edytor z wbudowanym AI), albo v0, Lovable, bolt – narzędzia no-code/low-code do prototypowania. Nie ucz się teoretycznie, lecz po prostu zacznij prototypować coś, czego ci brakuje, a następnie zobacz, jak daleko możesz zajść.

Krok 3: Traf na ścianę (to dobry znak)

W pewnym momencie te narzędzia no-code przestaną wystarczać, co oznacza, że jesteś gotowy na następny poziom.

Krok 4: Przejdź do prawdziwego kodu

Gdy trafisz na ograniczenia:

Wyeksportuj swój kod z narzędzia no-code
Wrzuć go na GitHub
Użyj VS Code z Claude Code lub Cursor
To da ci bardziej szczegółową kontrolę

Krok 5: Zaakceptuj realność

Wilson ostrzega: jeśli chcesz wyjść poza „fajną małą grę w Lovable”, będzie to bardzo engineeringowe. Nie ma sposobu, żeby jako designer po prostu coś zbudować bez wchodzenia w kod, jednak nie musisz być ekspertem – musisz tylko zacząć.

Jak Drew faktycznie pracuje z AI – lekcje z budowania Loupe

Wilson nie tylko teoretyzuje o pracy z AI – sam intensywnie z niego korzysta. Loupe, jego najnowsze narzędzie, zostało zbudowane w 100% przy użyciu Claude Code, bez otwierania Figmy ani razu.

Największy problem: AI nie widzi co robi

Wilson odkrył fundamentalny problem podczas pracy z coding agents. Najczęstszy scenariusz wygląda następująco: loguje coś do przeglądarki, kopiuje logi, wkleja z powrotem do AI, które widzi co jest nie tak i próbuje to zmienić. Potem znowu logowanie, kopiowanie i wklejanie.

Wilson zastanawiał się: dlaczego do cholery to robię? AI powinno po prostu mieć przeglądarkę. To ciągłe kopiowanie console logów z przeglądarki i wklejanie ich z powrotem do AI było tak frustrujące, że Wilson postanowił rozwiązać ten problem.

Loop – narzędzie zbudowane w 9-10 dni

W odpowiedzi na ten ból Wilson stworzył narzędzie o nazwie Loop w zaledwie 9-10 dni. Loop to nowe IDE do pracy z AI, które:

Używa konta Claude Code
Ma wbudowaną przeglądarkę
Automatycznie wysyła i odbiera console logi między AI chat a przeglądarką
Ma wiele widoków terminala, więc server-side może wysyłać i odbierać server logi do AI
Działa w ciągłej pętli
Ma wbudowane Chrome MCP tools, więc wie o przeglądarce Chrome i może używać wszystkich dev tools, włącznie z robieniem screenshotów

To perfekcyjny przykład tego, co Wilson głosi: nie musisz być senior engineerem – wystarczy zidentyfikować prawdziwy problem i użyć AI żeby go rozwiązać.

Claude Code i produktywność

Wilson jest wielkim fanem Claude Code i obecnie używa wyłącznie tego narzędzia. Jest znacząco wzmocniony przez to narzędzie i może zrobić o wiele więcej niż kiedykolwiek wcześniej, jednak nie w sensie bycia lepszym engineerem – w sensie bycia bardziej produktywnym.

Wilson zauważa też coś ważnego: Claude ani żaden coding agent z którym pracował nie jest najlepszym engineerem z którym kiedykolwiek pracował. Jeśli jesteś senior engineerem, możesz łatwo go prowadzić i widzieć gdzie robi błędy, co oznacza, że nie jest mądrzejszy od ciebie – jest po prostu szybszy niż kiedykolwiek będziesz i może zbudować o wiele więcej.

Jak Opacity będzie pracować z AI

W Opacity, zamiast walczyć z AI żeby trzymało się twojej wizji, design system staje się fundamentem. Budowanie z Opacity oznacza, że definiujesz jak te rzeczy powinny wyglądać, dlatego kiedy pytasz AI w Opacity o stworzenie toast component, buttona czy formularza, będzie trzymać się twojego design systemu.

Jest też creativity slider – możesz go dostosować, żeby AI mogło wyjść trochę poza ramy, ale w podstawie będzie trzymać się tego co masz. W ten sposób, kiedy budujesz z tym narzędziem, działa ono jak prawdziwy design lub engineering partner, który nigdy nie wrzuci czegoś na ekran, gdzie myślisz: skąd do cholery to się wzięło?

Przykładowe interakcje z AI w Opacity:

Wilson wspomina o kilku typowych scenariuszach pracy z AI w kontekście design systemów:

„Stwórz komponent toast/przycisk/formularz w ramach mojego systemu”
„Trzymaj się mojego systemu, z kreatywnością na poziomie niskim/średnim/wysokim”
„Zrefaktoruj ten komponent, zachowując kontrakt właściwości – możesz zmienić DOM i CSS”

Design systems jako język dla AI

Wilson tłumaczy dlaczego design systems są tak kluczowe dla pracy z AI. Nie mamy tej wielkiej systematycznej drogi do budowania designu, natomiast najbliższą rzeczą jaką mamy to code components, kiedy bierzesz swoje projekty i zamieniasz je w front-end components.

W Opacity każdy design i komponent to tak naprawdę node – podobny do DOM object. Opisuje w formacie obiektu design i jak powinien się wyświetlać. To jest ten systematyczny design, gdzie teraz jest jeden sposób opisania designu, na którym AI może polegać.

W przyszłości, z tysiącami UI libraries zbudowanych w Opacity, AI będzie miało masywną bazę do czerpania przy tworzeniu designów, w rezultacie będzie wiedziało czym jest dobry smak, ponieważ wszystkie te biblioteki będą zbudowane na tym samym systemie.

Przyszłość narzędzi designerskich według twórcy Opacity

Wilson buduje Opacity z bardzo konkretną wizją: narzędzie, które pozwala projektować bezpośrednio w kodzie produkcyjnym.

Dlaczego Figma nie jest dla software design?

Wilson jest wielkim fanem Figmy, ma jednak jasne zdanie na jeden temat. Figma nie została zbudowana jako narzędzie do software development czy software design – możesz to tam robić, ale możesz też zaprojektować poster dla swojego zgubionego kotka, zrobić plan piętra dla swojego następnego domu czy zaprojektować UI dla gry wideo. To general design tool i jest w tym świetne.

Figma ma killer vector system, zaś nowe rzeczy z Figma Draw są super i robią Illustrator jeszcze bardziej dostępnym. Wilson nie sądzi, żeby to kiedykolwiek musiało zniknąć, jednak uważa, że nie jest zbudowane dla software design. Kropka.

Import z Figmy do Opacity

Wilson wspomina o kluczowej funkcji Opacity, która ma ułatwić migrację: jednym kliknięciem można zaimportować komponenty i zmienne z Figmy do Opacity. Przekształcenie zachodzi w proporcji 1:1, co oznacza, że wszystkie komponenty designerskie i ich zmienne stają się od razu kodem produkcyjnym. To rozwiązanie ma odpowiadać na pytanie: dlaczego miałbym przejść z Figmy? Odpowiedź: bo możesz przenieść całą swoją pracę jednym kliknięciem i natychmiast mieć kod.

DOM-based canvas vs vector-based – kluczowa różnica

Wilson wyjaśnia fundamentalną różnicę między narzędziami. W Figmie canvas nie jest tym samym co production environment i nigdy nie będzie, natomiast w innych narzędziach (Opacity, Framer) – canvas którego używasz TO production environment. To przeglądarka renderująca HTML i CSS, więc będzie wyglądało 1:1.

I to jest benefit, choć nie w sposób który mogłoby się wydawać. Wilson pamięta jak Figma często mówiło: zrobiliśmy nasz canvas szybszy, szybszy, szybszy, jednak w świecie prawdziwych produktów software’owych niekoniecznie tego chcesz.

Dlaczego? Jeśli jest jakieś spowolnienie w sposobie w jaki renderujesz rzeczy bazując na twoich CSS properties, chcesz to zobaczyć zanim trafi do produkcji. Więc niekoniecznie jest benefitem robić cokolwiek szybszym w canvasie, jeśli robisz DOM-based canvas z założeniem, że wszystko tutaj trafi do DOM-based produktu.

Komponenty i kontrakty zamiast pixel perfect

Wilson mówi o czymś ważnym: w Opacity możesz zmieniać strukturę komponentu (divy, CSS, wszystko), dopóki zachowujesz kontrakt – czyli te same propsy.

Dawniej ograniczenie było takie: nasz table row składa się z 20 divów, opakowaliśmy to w ten i tamten sposób. Nie chcemy zmieniać struktury bo to wszystko zakodowaliśmy, dlatego jeśli chcesz coś zmienić, musisz zachować strukturę. CSS może się zmienić, kolory mogą się zmienić, może padding.

To odchodzi z Opacity. Możesz totalnie zmienić wewnętrzną strukturę divów, wszystko – po prostu chcesz zachować propsy, to wszystko czego ci potrzeba. Dopóki mogą nadal przekazywać te same dane z tymi samymi kontraktami i nazwami propsów, jesteś OK.

Konkretne przykłady pracy z propsami:

Wilson wymienia praktyczne scenariusze:

Promuj zmienną label do publicznej właściwości z możliwością konfiguracji
Oznacz size="xs" jako wycofywaną (deprecated) i wprowadź zamiast tego density="compact"
Dodaj nową właściwość state="loading" bez zmian po stronie konsumentów

Możesz zmienić wszystko o tym jak działa CSS oraz wszystko o tym jak divy są ustrukturyzowane. Absolutnie wszystko możesz zmienić i nadal zachować kontrakt z engineerami i z twoim systemem.

Co więcej – w Opacity gdy tworzysz propsy i je deprecatujesz, automatycznie pojawia się to w TypeScript files które generuje narzędzie. Intellisense w IDE (VS Code) będzie pokazywać przekreślone propsy i wszystkie hinty, w rezultacie zarówno zwykli inżynierowie jak i AI engineers będą wiedzieć kiedy czegoś nie używać.

PR workflow w Opacity – jak GitHub dla designu

Wilson opisuje kluczową funkcję Opacity, która przenosi best practices z engineeringu do designu. Zmiany wprowadzane są na oddzielnych gałęziach (branches), podobnie jak w rozwoju oprogramowania. Kiedy zmiany są gotowe, tworzysz pull request (PR), który pokazuje:

Różnice wizualne „przed/po”
Listę wszystkich zmienionych właściwości
Wpływ zmian na wydajność

Po akceptacji przez zespół, scalenie automatycznie emituje nową wersję pakietu NPM zgodnie z semantic versioning (patch/minor/major w zależności od wpływu zmian). Zespół zyskuje w ten sposób pełną ścieżkę audytu i znacznie mniej niejednoznaczności – wszystko jest udokumentowane i wersjonowane jak w normalnym rozwoju oprogramowania.

Design systems stają się fundamentalne

Wilson podkreśla: design systems nie są już nice-to-have, lecz są absolutnie konieczne dla efektywnej pracy z AI. AI potrzebuje systematycznej struktury, żeby skutecznie generować i modyfikować projekty, bez tego chaos.

Jest popularny pomysł, że design system oznacza brak kreatywności. Wilson rozumie skąd to się bierze w kontekście tego jak design systems są używane – projektujemy coś w Figmie, inżynierowie to kodują, teraz jest zakodowane. Jeśli chcemy zmienić design, nie może to być zbyt dzika zmiana, bo wtedy będą musieli przepisać wszystko od nowa.

To jednak wynika tylko z tego, że mamy dwa źródła prawdy i chodzi o man-hours, woman-hours, wydawanie pieniędzy na przepisanie czegoś co już działa. Jeśli nie masz dwóch źródeł prawdy, wszystko to znika – nie ma znaczenia jak bardzo szalenie zmieniasz swoje rzeczy, ponieważ masz te komponenty które są automatycznie dla ciebie tworzone. Więc to całe przepisywanie odchodzi.

Design systems mogą być tak kreatywne jak chcesz i nie musisz czuć, że nie możesz pracować poza pudełkiem które już dla siebie stworzyłeś.

Loupe jako proof of concept

Loupe to pierwszy produkt Wilsona zaprojektowany całkowicie w nowym paradygmacie – zero Figmy, ani razu nie otworzył tradycyjnego narzędzia do projektowania. Wszystko zbudowane przez Claude Code i samo Loupe.

Wilson mówi, że to pierwszy produkt jaki kiedykolwiek zbudował, gdzie nigdy nie otworzył design toola nawet raz. Czy wygląda idealnie? Jeszcze nie, jednak to zamierzone – Wilson chce żeby wyglądało dobrze, żeby było zaprojektowane i atrakcyjne. Teraz nie jest, ale to OK.

Wilson planuje zaprojektować Loupe po raz pierwszy w Opacity, nie w Figmie czy innym klasycznym narzędziu. Zaprojektował już Opacity w Figmie i przeprojektuje to w Opacity, ale Loupe będzie pierwszą rzeczą zaprojektowaną po raz pierwszy w Opacity.

Lekcje z różnych modeli budowania startupów

Wilson ma unikalną perspektywę, ponieważ przeszedł przez wszystko: bootstrapping, małe rundy, VC backing, YC. Nawet zachodził w długi na karcie kredytowej żeby finansować swoje projekty.

Teraz łączy doświadczenia z obu światów:

Z bootstrappingu: trzymasz się każdego grosza jakiego masz i nie wydajesz nic więcej niż możesz, bo dosłownie nie możesz
Z VC: masz tak głębokie kieszenie jak tylko zebrałeś i możesz to wydawać tak szybko lub wolno jak chcesz

Przy poprzednim VC-backed projekcie Wilson zbudował zespół 10-12 osób w ciągu roku. Tym razem tego nie zrobi – będzie szedł jeszcze wolniej z zatrudnianiem, nie dlatego że chce nadkompensować jakiś błąd, lecz po prostu nie musisz.

Wilson ma już mnóstwo AI agentów pracujących dla niego i szczerze mówi, że robią o wiele więcej niż zatrudnienie zespołu siedmiu inżynierów. To absolutnie szalone i zmienia całą matematykę zatrudniania oraz skalowania startupów.

Praktyczne checklisty dla designerów-builderów

Wilson przedstawia konkretne checklisty, które mogą pomóc w nowym modelu pracy.

Publikacja pakietu komponentu

Przed publikacją nowej wersji komponentu upewnij się że:

Zmiany są kompletne i spójne wizualnie
Kontrakt właściwości jest niezmieniony lub jasno opisany
PR zawiera opis wpływu zmian na użyteczność i wydajność
Wersja pakietu podbita zgodnie z wpływem (patch/minor/major)

Przegląd zmian (Pull Request)

Każdy PR powinien zawierać:

Dołączone różnice wizualne „przed/po”
Wypisane właściwości, które uległy zmianie
Przynajmniej jedną niezależną akceptację
Podgląd i kompilację przechodzącą bez błędów

Refaktoryzacja bez psucia kontraktu

Przy refaktoryzacji komponentu zadbaj o to, żeby:

Nazwy i typy właściwości pozostały bez zmian
Nowe właściwości miały sensowne wartości domyślne
Elementy wycofywane miały opis i wskazaną alternatywę

Co to wszystko znaczy dla ciebie?

Jeśli jesteś designerem:

Dzisiaj – zacznij eksperymentować z AI tools i podstawami kodu (nie musisz być ekspertem)
Jutro – narzędzia jak Opacity pozwolą ci dostarczać working code bez głębokiej znajomości engineeringu
Pamiętaj: średni engineer z AI będzie tak samo efektywny jak senior bez AI
Ludzie zawsze będą chcieli uniqueness – twoja wartość nie znika, ale zmienia formę

Jeśli prowadzisz zespół:

Zastanów się, jak wyglądają twoje procesy handoffu – czy można je skrócić lub wyeliminować?
Jak inwestujesz w design systems? Czy są gotowe na pracę z AI?
Czy twoi designerzy rozumieją podstawy kodu i mają przestrzeń, żeby się tego nauczyć?
Czy AI może zmienić twoją matematykę zatrudniania?

Jeśli budujesz produkty:

Standardy rosną – domyślne rozwiązania będą coraz lepsze dzięki AI (z 5/10 do 8/10)
Przestrzeń dla prawdziwej unikalności się kurczy, ale popyt na customizację może eksplodować
AI zmienia matematykę budowania zespołów – możesz robić więcej mniejszym zespołem
Być może będziemy mieć więcej małych firm zamiast kilku gigantów z ogromnymi zespołami

Kontrowersyjna obserwacja: Być może osiągamy limit tego, jak dobry może być design dla obecnych platform (desktop, mobile). Apple już nie wyznacza poprzeczki, natomiast nowe możliwości czekają w Vision Pro, AR glasses i innych emerging platforms.

Narzędzia wymienione w rozmowie

Do pracy z AI i kodem:

Claude AI / Claude Code – główne narzędzie Wilsona do budowania
Cursor – edytor kodu z wbudowanym AI
VS Code – z integracją Claude Code
Warp – terminal z funkcjami AI (wspomniany przez prowadzącego)

Do prototypowania bez kodu:

v0 – tool do generowania UI
Lovable – platforma no-code/low-code do prototypowania
bolt (b0) – kolejne narzędzie do szybkiego prototypowania

Projekty Drew Wilsona:

Opacity (w budowie) – narzędzie do projektowania w kodzie produkcyjnym, z wbudowanym PR flow i GitHub-like collaboration
Loupe (w alfa) – pierwszy produkt zaprojektowany bez Figmy, IDE do pracy z AI z automatycznym przesyłaniem console logów

Inne narzędzia:

Framer – wspomniany jako przykład DOM-based canvas
GitHub – jako standard collaboration dla engineerów
NPM packages – sposób w jaki Opacity dostarcza komponenty do code base

Kluczowy insight

Stabilny kontrakt, wolna forma

Standardowo myślimy: System projektowy ogranicza zmiany, więc można ruszać jedynie kosmetykę. Każda większa zmiana wymaga przepisania komponentu od zera, dlatego designerzy czują się zamknięci w pudełku własnego systemu.

W praktyce okazuje się, że: Utrzymanie kontraktu właściwości (propsów) pozwala dowolnie zmieniać wewnętrzną strukturę DOM i CSS bez psucia konsumentów. Możesz zamienić 20 divów na CSS Grid, zmienić wszystkie cienie i odstępy, przebudować całą typografię – dopóki nazwy i typy właściwości pozostają takie same, konsumenci nie muszą zmieniać ani linijki kodu.

Dlaczego to jest istotne: Decyzje projektowe przestają blokować wykonanie. Zespół publikuje nową wersję pakietu zamiast przepisywać elementy od zera, natomiast praca w jednym źródle prawdy zmniejsza ryzyko regresji. Design systems mogą być tak kreatywne jak chcesz, a przepisywanie całych komponentów odchodzi do przeszłości.

Test na jutro: Wybierz często używany komponent w twoim projekcie. Zamroź jego właściwości (nazwy i typy) – to twój kontrakt. Oznacz jedną właściwość jako deprecated z alternatywą. Następnie zmień całkowicie układ wewnętrzny i stylowanie – użyj innych tagów HTML, zastosuj CSS Grid zamiast flexbox, zmień kolory i typografię. Opublikuj jako wersję „minor” i zaktualizuj w kilku widokach. Zaobserwuj, że konsumenci nie muszą wprowadzać żadnych zmian w swoim kodzie – wszystko działa automatycznie.

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: [Dive Club Podcast – Drew Wilson: How designers become builders and the future of tooling]

Tag: Designer Jako Builder

Drew Wilson o tym, jak designerzy stają się builderami i przyszłości narzędzi projektowych #EN340