Tak się czuję w kwestii kodowania wibracji. Każdy projekt, który próbuję, a który ma jakiekolwiek komplikacje, ma natychmiastowy zastrzyk postępu. Rzeczy są niesamowite i czuję się jakbym miał supermoc. Potem... gdy dodaję więcej złożoności, wszystko zatrzymuje się w miejscu. Jedynymi projektami, które myślę, że mogę stworzyć, są te, które mieszczą się w tej "strefie wibracji". Prototypy, interfejsy użytkownika, produkty — wszystko, co jest proste i ma niską złożoność, idealnie pasuje do tej strefy. Dowody koncepcji, interakcje, takie rzeczy. Narzędzia są w stanie tworzyć rzeczy, które pasują do tego slotu. Ale. Wszystko się rozpada, gdy ta krzywa złożoności rośnie. A problem polega na tym, że każdy dobry proces projektowania produktu ma rosnącą złożoność. Podstawowy prototyp staje się dobrym prototypem, gdy tylko ma warstwowe interakcje, przejścia, dobre affordancje, stany najechania, 1000 drobnych szczegółów, które sprawiają, że coś wydaje się poprawne i realne. Korzyścią z kodowania wibracji ma być to, że poruszasz się szybko i możesz szybko tworzyć rzeczy — pozwalając AI wykonać całą pracę za Ciebie. Problem polega na tym, że traci impet, gdy tylko dodana zostaje niezbędna złożoność. Wciąż się powtarza, przepisuje kod, wpływa na rzeczy, które są niezwiązane, a następnie powoduje inne problemy. Ale jeśli dodasz tę złożoność, każda sesja kodowania wibracji szybko zamienia się w sesję bicia robaków w whack-a-mole. Nie jestem pewien, jakie jest rozwiązanie. W tradycyjnym prototypowaniu rozwiązaniem jest duplikowanie, dodawanie większej złożoności, tworzenie większej liczby ramek/scen, dostosowywanie, forkowanie itd. Jednak w kodowaniu wibracji jeden mały prompt może dosłownie zniszczyć wszystko. Jest etap, w którym kończę chodząc po skorupkach promptów — starając się nie dać zbyt dużo ani zbyt mało kontekstu, aby nie poszło w złym kierunku i nie zniszczyło wszystkiego. Jest tylko kilka wyjątków od tej zasady. @cursor i @framer. Mogę osiągnąć świetny postęp z Cursor, dając mu wąski kontekst, i muszę zatwierdzić edycje, które wprowadza. To wydaje się poprawnym przepływem pracy. Problem polega na tym, że nie mogę zobaczyć rzeczy, którą tworzy, ponieważ to IDE, a nie wizualne środowisko. Tak, mogę tworzyć lokalne wersje i odświeżać przeglądarkę i wszystkie te rzeczy. Ale aspekt wizualny jest całkowicie utracony w doświadczeniu kodowania. To narzędzie dla deweloperów. Framer robi to dobrze, ponieważ pozwala tylko na wąskie aktualizacje w obrębie jednego komponentu na stronie. Tak, to ograniczające, ponieważ może zrobić tylko jedną rzecz na raz, ale przynajmniej nie próbuje stworzyć całej strony od podstaw i zarządzać wszystkim przez interfejs promptu. To wydaje się być właściwym podejściem. @Cursor: Pozwól AI edytować cokolwiek, ale pozwól użytkownikowi zatwierdzić te edycje i zobaczyć je w kontekście. @Framer: Pozwól AI edytować tylko wąsko pojedynczy plik lub komponent, aby zminimalizować złożoność i zredukować katastrofalne edycje. Jestem optymistyczny, że narzędzia takie jak @Figma, @Lovable, @Bolt i @V0 mogą tworzyć fajne prototypy, ale wciąż napotykam ściany, gdy chodzi o robienie czegokolwiek więcej niż tylko podstawowy prototyp interakcji. Muszą robić mniej, moim zdaniem. Mam nadzieję, że te narzędzia dodadzą więcej kontroli, które są w tym samym duchu co Cursor i Framer. Dodam również, że to jest podobne do tego, jak robimy to z generowaniem wykresów w @Basedash. Ale nie jesteśmy narzędziem wibracyjnym w normalnym sensie, więc paralele są trochę trudniejsze do narysowania.