Kodowanie intuicyjne 101: Warsztaty praktyczne od zera do jedynki

Przeczytaj transkrypcję:

Wypróbowujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Wybaczcie wszelkie literówki, ponieważ bot nie zawsze działa w 100% poprawnie.

Hannah Clark: Dobrze, kochani. Zastrzeżenie dotyczące odcinka — jeśli jesteście już ekspertami od kodowania intuicyjnego, ten odcinek może nie być dla was. Ale jeśli słyszeliście o kodowaniu intuicyjnym i chcecie poznać fakty oraz mity, a także ciekawi was, jak możecie wykorzystać tę technologię do realizacji własnych celów, pokochacie ten odcinek.

Jeśli nie śledziliście naszych newsletterów, czyli tych, które można subskrybować pod adresem theproductmanager.com/subscribe, to nie mogłam przestać mówić o świetnych praktycznych warsztatach z kodowania intuicyjnego, które zorganizowaliśmy kilka tygodni temu z Drew Falkmanem, dyrektorem w Moves The Needle. Ten odcinek podcastu Product Manager Podcast jest właściwie nagraniem 30-minutowego seminarium, które przeprowadziliśmy przed rozpoczęciem naszej sesji prototypowania na żywo. Usłyszycie wyjaśnienie, czym jest kodowanie intuicyjne, a czym nie jest, inspirujące przypadki użycia tej technologii oraz rekomendacje narzędzi, dzięki którym możecie zacząć eksperymentować i odkrywać własne zastosowania. Zaczynajmy.

A tak przy okazji, co tydzień prowadzimy takie rozmowy. Jeśli więc brzmi to dla was interesująco, dlaczego nie zasubskrybować? Dobrze, zaczynajmy.

Nazywam się Hannah Clark. Jeśli mnie nie znacie, jestem redaktorką naczelną Klubu CPO i prowadzącą podcast Klubu CPO. Jest ze mną moja współprowadząca, Katie.

Katie Sanders: Cześć wszystkim, jestem Katie Sanders. Jestem redaktorką naczelną w Klubie CTO. Być może także w The QA Lead. Są tu osoby z połączonych przez nas stron. Jestem więc podekscytowana. To moje pierwsze warsztaty i naprawdę cieszę się, że robię to z Hannah, ponieważ między produktem a CTO istnieje wiele obszarów wspólnych. Tak więc jestem podekscytowana, że mogę wszystkich poznać. Witajcie!

Hannah Clark: Bardzo się cieszę, że pracuję nad tym z Katie. Jeśli jeszcze nie obserwujecie jej na LinkedIn, Katie Sanders jest naprawdę świetna. Tworzy wspaniałe treści, więc bardzo się cieszę, że będziecie mogli się poznać.

Chciałabym również przedstawić naszego gościa. Jest z nami Drew Falkman. Drew jest liderem produktowym, doradcą i edukatorem skupiającym się na strategii produktu od etapu przed zalążkowego do zalążkowego. Usprawnia pracę wczesnych zespołów. Optymalizuje działania pod kątem dopasowania produktu do rynku.

Zrobił już wszystko. Jest świetnym przyjacielem naszej publikacji. Wielokrotnie z nami pracował. Pracował też ze mną, co oznacza, że jest bardzo cierpliwym człowiekiem. Jesteście więc dziś w dobrych rękach. Ma również ogromne doświadczenie w tworzeniu produktów internetowych, mobilnych, blockchainowych i opartych na sztucznej inteligencji. Mamy więc tutaj niesamowitego eksperta.

Drew, chcesz przywitać się z miłymi ludźmi?

Drew Falkman: Cześć wszystkim, bardzo się cieszę, że tu jestem. Będzie świetnie.

Hannah Clark: Zaczniemy od obalania mitów. Rozpocznę od pierwszego pytania, a następnie moja wspaniała współprowadząca Katie przejdzie przez kilka mitów, a Drew je dla nas obali. Zacznijmy od przedstawienia kontekstu.

Wygląda na to, że wszyscy mówią teraz o kodowaniu intuicyjnym i pojawia się ono w każdym poście na LinkedIn, w tym w wielu moich postach. Ludzie wydają się albo bardzo podekscytowani, albo bardzo przestraszeni, albo bardzo zdezorientowani. Porozmawiajmy więc o tym, dlaczego kodowanie intuicyjne jest tak popularne. Dlaczego jest teraz tak ważne? Przyjrzyjmy się związanemu z tym mitowi.

Katie Sanders: Dobrze, pierwszy mit: kodowanie intuicyjne zastępuje inżynierów. Oczywiście ogólnie mówi się, że sztuczna inteligencja zastępuje pracę wszystkich. Powiedziałabym, że to mit i że być może zmienia ona pracę inżyniera oraz tworzy kod gotowy do wykorzystania w aplikacji, ale z pewnością nie zastępuje całkowicie pracy inżyniera.

Jak zawsze w przypadku sztucznej inteligencji, chcemy, aby człowiek pozostawał w pętli, więc powiedziałabym, że nic nie zostanie wdrożone bez ludzkiej kontroli. Myślę więc, że możemy obalić ten mit.

Hannah Clark: Drew, chcesz coś dodać?

Drew Falkman: Tak, powiedziałbym, że jako inżynier trzeba mieć świadomość tego, co nadchodzi.

Może to po prostu przyspieszyć wasz proces. Jako projektanci, menedżerowie produktu i nietechniczni założyciele macie teraz możliwość tworzenia produktów w wersji MVP, prototypów oraz ich walidacji, a następnie przekazywania ich inżynierom. Kiedy chcecie przejść do kodu na poziomie produkcyjnym, ogólnie rzecz biorąc, po etapie MVP,

w dzisiejszych czasach z pewnością trzeba przeprowadzać przeglądy kodu i sprawdzać, czy wszystko zostało dopracowane, szczególnie jeśli występują kwestie związane ze zgodnością z przepisami lub inne zagadnienia, o których trzeba pamiętać.

Hannah Clark: Przejdźmy do mitu numer dwa. Niektórzy twierdzą, że kodowanie intuicyjne znajduje się poza cyklem wytwarzania oprogramowania.

Innymi słowy, jeśli zbudujecie coś w aplikacji do kodowania intuicyjnego, to nie będzie to naprawdę użyteczne i trzeba będzie całkowicie odtworzyć to od zera z programistą, który zakoduje wszystko ręcznie. Drew, czy rzeczywiście tak jest?

Drew Falkman: Narzędzia bardzo się rozwinęły i jest to jedna z tych rzeczy, które dosłownie zmieniają się każdego dnia.

Claude wydał w ciągu ostatniego miesiąca mniej więcej nową wersję generowania kodu i jest ona o wiele lepsza niż wcześniej. Narzędzia stale się więc poprawiają. Działają jednak jak wszystkie rozwiązania generatywnej sztucznej inteligencji. Mogą halucynować, robić dziwne rzeczy i zachowywać się w nieoczekiwany sposób. W ramach cyklu można je jednak włączyć do procesu i rzeczywiście tworzyć takie fragmenty kodu.

Można przekazywać je inżynierom, ale trzeba mieć świadomość, że prawdopodobnie będą wymagały przeróbek. Być może będzie trzeba ponownie wykorzystać niektóre komponenty. Myślę, że niektórzy inżynierowie mogą być nawet zaskoczeni tym, jak dobry jest ten kod.

Hannah Clark: Dobrze. Kolejny często powtarzany mit mówi, że do intuicyjnego zakodowania narzędzia nie potrzebujecie dokumentu wymagań produktu ani strategii produktowej.

Drew, Katie, jakie macie przemyślenia?

Drew Falkman: Zawsze trzeba myśleć. Czasami ludzie sądzą, że jeśli kodują intuicyjnie, mogą po prostu zacząć, otworzyć narzędzie i mieć aplikację następnego dnia. Tak jak we wszystkim innym, jeśli nie poświęcicie czasu na wcześniejsze przemyślenia, rezultat nie będzie tym, czego chcecie. Trzeba zastanowić się, kim są odbiorcy i jaki jest rynek docelowy.

Trzeba przemyśleć propozycję wartości oraz to, jakie będą podstawowe funkcje i przepływy w aplikacji. Warto więc poświęcić czas na przygotowanie czegoś. Piękno tego rozwiązania polega jednak na tym, że nie trzeba tworzyć pięcio- czy dziesięciostronicowego dokumentu wymagań produktu, który definiuje wykorzystywane technologie oraz opisuje wszystkie przepływy za pomocą diagramów.

Nie trzeba się nad tym wszystkim zastanawiać. Wystarczy zarysować swoją wizję i to, co budujecie. Właściwie opracowałem mały dokument wymagań produktu do kodowania intuicyjnego. Ma on od jednej do dwóch stron i jest przeznaczony dla was oraz wszystkich osób, z którymi możecie współpracować, abyście mieli wspólne rozumienie projektu i mogli podejść do niego w uporządkowany sposób.

Dzięki temu wasz kod będzie ostatecznie czystszy.

Hannah Clark: Dobrze wiedzieć. Przejdźmy do kolejnego mitu dotyczącego silnie regulowanych branż. Katie reprezentuje Klub CTO, więc może chcesz się tym zająć?

Katie Sanders: Tak, myślę, że jest jeszcze jeden temat, który chciałam poruszyć. Chodzi o to, że jest to nowe rozwiązanie, podczas gdy kodujemy intuicyjnie od lat.

Po prostu do niedawna tak tego nie nazywaliśmy. Kopiowanie i wklejanie z GitHuba, Reddita czy Hacker News — gdziekolwiek — jest czymś, co robią świetni inżynierowie. Rozwiązują problemy, wyszukują informacje, rozpoznają wzorce, dostosowują je i budują. Myślę więc, że ten sposób formułowania poleceń jest kolejną ewolucją czegoś, co zawsze istniało. A Hannah, jaki był drugi mit, który chciałaś obalić?

Hannah Clark: Że jeśli pracujesz w silnie regulowanej branży, nie możesz kodować intuicyjnie. Że to nie jest bezpieczne.

Katie Sanders: Oczywiście, kiedy myślimy o opiece zdrowotnej czy finansach, mówimy o silnie regulowanych branżach. Tak jak w każdej innej branży, trzeba więc upewnić się, że przestrzega się wymogów HIPAA i wszystkich pozostałych zasad.

Wiem, że modele językowe mogą czasami pobierać informacje. Trzeba więc brać pod uwagę kwestie zgodności z przepisami. Szczególnie w tych branżach. Myślę jednak, że przy opiece zdrowotnej, finansach i podobnych obszarach potrzebne są po prostu dodatkowe zabezpieczenia.

Hannah Clark: Tak, myślę, że jest to podobne do wielu różnych procesów tworzenia oprogramowania, w których narzędzia do kodowania intuicyjnego nadal nie zastępują personelu.

Są raczej dodatkiem przyspieszającym cykl tworzenia. Jednak dobry, rygorystyczny proces przeglądu kodu jest prawdopodobnie ważniejszy niż kiedykolwiek, teraz gdy część tej pracy zlecamy na zewnątrz. Porozmawiajmy trochę o przypadkach użycia. Ciekawie będzie przeanalizować kilka różnych sposobów, w jakie ludzie skutecznie wykorzystują obecnie kodowanie intuicyjne.

Katie poprowadzi tę część programu i omówi kilka naprawdę interesujących przypadków użycia.

Katie Sanders: Wiele z nich znalazłam na Reddicie, kiedy kodowanie intuicyjne dopiero zaczęło zyskiwać popularność. Chciałam zobaczyć rzeczywiste przykłady. Wszyscy o tym mówili, ale nie potrafiłam znaleźć niczego, co odniosło sukces.

Napisałam więc o tym artykuł. Jedna z opisanych osób zbudowała coś w rodzaju organizatora niszowych meczów piłkarskich, właściwie jako osobiste hobby. Nie była programistą, ale rozumiała, jak działają aplikacje z pełnym stosem technologicznym, i zawsze musiała zatrudniać programistów, aby urzeczywistniali jej pomysły.

Kiedy jednak zaczęła eksperymentować z Lovable, Cursorem i wszystkimi innymi narzędziami, stworzyła aplikację do organizowania niszowych meczów piłkarskich. Pomagała jej organizować cotygodniowe mecze. Ostatecznie wdrożyła ją i, jak sądzę, z powodzeniem. W ciągu kilku tygodni uruchomiła aplikację wygenerowaną przez sztuczną inteligencję, składającą się ze stu linii kodu, i zaczęła na niej zarabiać. Chyba przynosiła około 700 dolarów tygodniowo, czy coś w tym rodzaju. Michael?

Czy to było około 700 dolarów tygodniowo? Innym przykładem, który znaleźliśmy, była aplikacja o nazwie Workaid — grywalizowane zarządzanie zadaniami wspierane przez sztuczną inteligencję. Rewolucjonizuje listę rzeczy do zrobienia, sprawiając, że praca przypomina grę. To były dwa udane przykłady, które znalazłam na Reddicie, i możemy podlinkować wam ten post.

Było jeszcze kilka podobnych przykładów. Myślę, że wiele osób będzie po prostu eksperymentować z tym rozwiązaniem, ale niektórzy odniosą dzięki niemu naprawdę duży sukces, co bardzo ciekawie obserwować.

Hannah Clark: Tak, to bardzo interesujący przykład. Chciałam tylko szybko wtrącić, ponieważ mamy świetne pytanie od Katy.

Katya pyta: „Zastanawiałam się, czy jako menedżerka produktu nadal musiałabym tworzyć makiety i prototypy interfejsu użytkownika? Czy mogłabym po prostu stworzyć je za pomocą kodowania intuicyjnego, a następnie przekazać programistom mój interfejs jako punkt wyjścia do ich pracy?”

Drew Falkman: Tak, w stu procentach. Powiedziałbym nawet, że w przypadku większości tych narzędzi trudniej byłoby użyć kodowania intuicyjnego do odtworzenia istniejącego projektu.

Trudno importować ekrany i robić wszystkie tego typu rzeczy. W rzeczywistości łatwiej jest zdefiniować projekt, a następnie współpracować z generatywną sztuczną inteligencją nad uzyskaniem odpowiedniego wyglądu i charakteru. Potem można przekazać go programistom, którzy upewnią się, że jest zgodny z używanym systemem projektowym i pozostałymi wymaganiami.

Hannah Clark: Dziękuję za odpowiedź, Drew. Przepraszam, Katie, że ci przerwałam. Chcesz wrócić do przypadków użycia? Wiem, że masz jeszcze kilka przykładów.

Katie Sanders: Michael, chcesz opowiedzieć o jednym przypadku użycia z naszej firmy? Ktoś stworzył analizator wpływu zwolnień. Michael, nie wiem, czy chciałeś podzielić się tym jako świetnym przykładem.

Michael Mordak: Oczywiście. To świetny przykład wykorzystania kodowania intuicyjnego przez jednego z naszych współpracowników. Pracuje on dla publikacji poświęconej zasobom ludzkim i chciał zbudować narzędzie, za pomocą którego można analizować wpływ planowanych zwolnień.

Zakodował je w taki sposób, a właściwie bot je zakodował, że osoby chcące z niego skorzystać muszą wcześniej wypełnić ankietę. Dzięki temu zbiera dane o użytkownikach, co było mu potrzebne do własnych celów. Po wypełnieniu ankiety aplikacja przenosi użytkownika do kalkulatora.

Wbudował w nią kilka przykładów. Jeśli pracujecie w firmie produkcyjnej i planujecie zwolnić 200 pracowników, możecie wybrać ten przykład, aby zobaczyć, jak działa narzędzie.

Wprowadzacie różne szczegóły i odpowiadacie na pytania: jaką wiedzę mają te osoby, ile czasu zajęłoby przeszkolenie kogoś do pełnienia tej funkcji? Następnie możecie obliczyć wpływ zwolnień, a narzędzie powie wam dokładnie, jaki będą miały skutek.

Byłoby to świetne narzędzie dla osób pracujących w HR, które planują zwolnienia. Udostępnił je za darmo osobom chcącym się nim pobawić i przekazać mu informacje zwrotne. To jeden przykład pochodzący od kogoś z naszego zespołu. Drugi przykład, o którym mogę opowiedzieć, to narzędzie do głosowania, którego właśnie używaliśmy. Zakodowałem je sam.

Nie mam doświadczenia w kodowaniu, a jeśli już, to bardzo ograniczone. Zbudowałem więc tę aplikację do głosowania, abyśmy mogli zbierać głosy publiczności na żywo i wyświetlać wyniki, zamiast płacić za narzędzie, które to robi. Często aplikacje mają taką funkcję, ale trzeba za nią zapłacić i płaci się również za wszystkie inne funkcje, których właściwie się nie używa.

Mnie interesuje tylko głosowanie, więc zbudowałem własne narzędzie. Mogę nadać mu dowolną nazwę, dodać dowolną liczbę opcji, wyświetlić podgląd przed publikacją, a następnie uruchamiać głosowania, wyłączać je, usuwać i tak dalej. Tak są wyświetlane na ekranie.

Głosujecie więc w aplikacji, którą stworzyłem. Nie zbieram od was żadnych danych, nie martwcie się. Wszystko działa lokalnie w tym narzędziu. Tak właśnie uzyskaliśmy tamte wyniki. Przygotowałem to bardzo szybko. Pracowałem nad tym około 30 minut przed rozmową, ale łącznie stworzenie aplikacji i dodanie brandingu, który uznałem za atrakcyjny, zajęło mi prawdopodobnie od jednej do dwóch godzin.

Nie jestem jednak projektantem, więc nie traktujcie tego jako źródła wskazówek.

Katie Sanders: Tak, rozmawialiśmy o zaletach. Oczywiście są osoby, które eksperymentują z tym rozwiązaniem i sądzą, że nigdy więcej nie będą potrzebować nikogo technicznego. Jest jednak przykład Leo Juniora.

Jego post stał się viralem na X. Jest założycielem Enrich Lead, narzędzia, które zbiera adresy IP i wykorzystuje model językowy do generowania potencjalnych klientów sprzedażowych. Zbudował całą aplikację za pomocą Cursora i z dumą stwierdził: „Zero ręcznie napisanego kodu, sztuczna inteligencja jest budowniczym. Możecie narzekać albo zacząć budować”. Dużo brawury i żadnej pokory.

Internet oczywiście zareagował gwałtownie. W ciągu 48 godzin hakerzy przejęli system, obejście subskrypcji spowodowało gwałtowny wzrost kosztów, a model językowy zaczął tworzyć dane potencjalnych klientów z powietrza. Leo musiał opublikować na Twitterze wiadomość SOS: „Hej, jestem atakowany. Dzieją się przypadkowe rzeczy”.

Nie znał się na technice, więc zrozumienie sytuacji zajęło mu więcej czasu niż zwykle. W ten sposób zaczął uczyć się programowania na trudnej drodze. Lekcja jest więc taka, że zawsze potrzebujecie człowieka w pętli. Jako osoba nietechniczna możecie świetnie się tym bawić, ale kod zawsze powinien zostać sprawdzony przez osobę techniczną.

Hannah Clark: Michael, czy możesz krótko opowiedzieć, jak wyglądała krzywa uczenia się, kiedy po raz pierwszy zacząłeś eksperymentować z tymi narzędziami?

Michael Mordak: Jasne. Jak mówiłem, moja wiedza na temat kodowania jest bardzo ograniczona. Czasami widzę, jak ludzie mówią: „Jestem osobą od pomysłów”. Nigdy wcześniej niczego nie zbudowali i dokładnie do tej grupy należę, ponieważ często zastanawiam się nad różnymi sposobami ograniczenia wewnętrznych procesów albo wykonania czegoś bez płacenia za aplikacje firm trzecich, ale samo zbudowanie tego jest trudne.

W odpowiedzi na pytanie Granda o to, jaka jest krzywa uczenia się w praktyce: narzędzie, którego dziś użyjemy, Lovable, działa podobnie jak inne dostępne aplikacje. Krzywa uczenia się jest naprawdę łagodna. Jest niewielka, ponieważ — jak widzicie — wszystko opiera się na poleceniach tekstowych.

Opisujecie dokładnie, co chcecie zobaczyć, jaki jest cel budowania aplikacji i jakie rezultaty chcecie osiągnąć. Narzędzie wygeneruje przykłady tego, co mogłoby dla was zbudować. Możecie również podać dodatkowe szczegóły. Jeśli macie punkt odniesienia, możecie powiedzieć na przykład: „Chcę, żeby wyglądało to podobnie do slido.com”. Jeśli znacie Slido, wiecie, że jest to aplikacja do głosowania.

Narzędzie może więc korzystać z przykładów z rzeczywistego świata, a wy możecie wprowadzić własny branding i inne wymagania dotyczące działania aplikacji. Po stworzeniu pierwszej wersji to jeszcze nie koniec. Możecie nadal z nim rozmawiać.

Dostępny jest tryb rozmowy, w którym możecie zadawać pytania, zanim narzędzie zmieni kod lub cokolwiek zbuduje. Odkryłem również, że gdy coś wykraczało poza moją wiedzę, kopiowałem informacje przekazane mi przez Lovable, wklejałem je do ChatGPT i pisałem: „Wyjaśnij mi to tak, jakbym miał pięć lat”.

Dzięki temu narzędzie upraszczało wszystko dla osoby takiej jak ja, która nie rozumie wszystkich szczegółów technicznych, i dokładnie wyjaśniało zagadnienie. Proces był więc bardzo płynny i łatwo było spróbować zbudować coś takiego.

Hannah Clark: To naprawdę świetne. Mam nadzieję, że jest to zachęcające dla tych z nas, w tym dla mnie, którzy zaczynają zupełnie od zera.

Chciałam poruszyć pytanie od Tala. Skierujemy je do Drew. Tal pyta: „Jaki byłby dobry sposób pracy dla istniejących firm produktowych? Jestem menedżerem produktu w startupie. Mamy system projektowy i działający produkt z użytkownikami. Jak sądzisz, czy mogę wykorzystać kodowanie intuicyjne do konkretnych funkcji lub pomysłów?”

„Kiedy projekt wróci do projektanta, a kiedy pominąć projektowanie i przejść od razu do programisty?”

Drew Falkman: Myślę, że cały ten sposób pracy jest obecnie w fazie rozwoju. Nie ma jeszcze najlepszych praktyk. To nadal Dziki Zachód, jeśli chodzi o łączenie wszystkich tych elementów. Gdybym pracował w firmie, pominąłbym projektowanie, ale skoordynowałbym działania z projektantem.

Przygotowałbym coś — pokażę wam mój dokument wymagań produktu do kodowania intuicyjnego — co opisywałoby ekrany i elementy. Trzeba jednak uzyskać akceptację projektantów. Mogą oni również współpracować przy tym projekcie. Pamiętajcie, że nie jest to coś, co musimy robić w izolacji. Wszyscy możemy patrzeć na ten sam projekt i wspólnie nad nim pracować.

Następnie stworzyłbym rozwiązanie. Przynajmniej nie znam żadnego magicznego sposobu na zintegrowanie systemów projektowych z Lovable. Niektóre inne narzędzia, takie jak Cursor, oferują w tym zakresie niższy poziom abstrakcji, ponieważ można podłączyć rozmowy i wszystko inne, ale faktycznie pracuje się w kodzie.

W zintegrowanym środowisku programistycznym często wymaga to również uruchamiania poleceń w wierszu poleceń. Jest to więc nieco bardziej techniczne dla osób całkowicie nietechnicznych, ale pozwala na większą integrację i interakcję z kodem. W tym przypadku mogłoby to być lepsze narzędzie. Gdybym jednak robił to tutaj, narzędzie wykonałoby dwukierunkową synchronizację z GitHubem, co spróbuję dziś pokazać, jeśli będziemy mieli czas.

Można więc utworzyć wersję ekranu, opublikować ją na GitHubie, a następnie programiści mogą ją pobrać. Mogą zastosować wszystkie swoje komponenty i systemy projektowe, a potem przesłać zmiany z powrotem. Kiedy wrócicie do projektu, powinniście zobaczyć wszystkie te elementy i, miejmy nadzieję, wszystko będzie działać świetnie.

Hannah Clark: Świetnie. To pytanie od Donalda do Drew. Jakie masz doświadczenie z kodowaniem intuicyjnym czegoś bardziej podobnego do istniejącego rozwiązania, na przykład kolejnego menedżera zadań, w porównaniu z czymś bardziej unikalnym, takim jak sonifikacja danych Google Trends? Innymi słowy, chodzi o kodowanie intuicyjne czegoś, co jest kolejną wersją rozwiązania istniejącego w wielu odmianach, w porównaniu z pomysłem całkowicie nowym i wcześniej niespotykanym.

Drew Falkman: To świetne pytanie. Z mojego ogólnego doświadczenia z narzędziami do prototypowania i kodowania intuicyjnego wynika, że wszystko, co już istnieje, jest dość proste. Narzędzia rozumieją takie rozwiązania. Naszym domyślnym przykładem jest dziś aplikacja turystyczna. Potrafią tworzyć aplikacje turystyczne przez cały dzień. Kiedy jednak przechodzicie do czegoś takiego jak sonifikacja danych Google Trends, zaczyna się większa walka.

Dodałbym, że jeśli wchodzicie w obszar wymagający bardzo niestandardowych narzędzi wizualizacyjnych, innych niż standardowe elementy interfejsu, takie jak listy rozwijane, przyciski i podobne komponenty, będziecie mieć trudności z tego typu narzędziami — przynajmniej z Lovable i na obecnym etapie ich rozwoju.

Być może istnieją inne narzędzia, które ułatwią takie zadania, ale obecnie w przypadku rzeczy nietypowych i naprawdę wykraczających poza standard będziecie musieli pobierać dodatkowe elementy i nad nimi pracować.

Hannah Clark: Dobrze. To prowadzi nas do końca. Chcę bardzo podziękować Katie za udział, a także Drew za to, że był tak wspaniałym źródłem wiedzy i poświęcił swój czas oraz doświadczenie.

Dziękuję za wysłuchanie. Aby poznać więcej świetnych spostrzeżeń, poradników i recenzji narzędzi, zasubskrybujcie nasz newsletter pod adresem theproductmanager.com/subscribe. Więcej podobnych rozmów znajdziecie, subskrybując Klub CPO w miejscu, w którym słuchacie swoich podcastów.