Michał Wilk: Pamiętam historię z jednego VC, gdzie partner tego VC opowiadał, że studentka wpadła na świetny pomysł aplikacji do wypożyczania sobie chyba ciuchów. No i on zapytał: “Ale czy ludzie tego chcą?” No ona nie wie, ale ma świetny pomysł. No on mówi: “Dobra, przyklej sobie kartkę na drzwi swojego akademika z pytaniem, czy ktoś chce pożyczyć ciuch”. No okazało się, że nikt nie chciał i dzięki temu zaoszczędziła tonę czasu na wdrożenie tej aplikacji. I to są praktyki ze startupów, które wielkie organizacje tak jakby wyparły.

Bartek Śliwa: Cześć, z tej strony Bartek Śliwa. Witam was w kolejnym odcinku podcastu Euvic Talks, w którym łączymy biznes i technologię. I dziś odczarujemy słowo roku 2025, czyli vibe coding. Moim i waszym gościem jest AI Solutions Lead Michał Wilk. Cześć.

Michał Wilk: Cześć.

Bartek Śliwa: Przede wszystkim zanim będziemy odczarowywać vibe coding, odczaruj czym zajmuje się AI Solutions Lead.

Michał Wilk: Okej. Zajmuje się tworzeniem rozwiązań, które wykorzystują AI w zasadzie na każdym etapie, czyli zarówno rozwiązań wykorzystujących AI podczas programowania, podczas prototypowania, ale też samych rozwiązań AI. Tytuł fajny wymyśliła koleżanka z marketingu na potrzeby LinkedIna.

Bartek Śliwa: Okej. A jak wyglądała twoja droga do tego momentu, w którym teraz jesteś? Jak stałeś się właśnie tym AI Solutions Leadem?

Michał Wilk: Wiesz co, no od programisty przez lidera do bycia cały czas na bieżąco z rozwiązaniami, myślę, że to tak w dużym skrócie można opisać, czyli od osoby, która od zawsze interesowała się programowaniem, tworzeniem produktów przez osobę, która prowadziła zespoły. No aż teraz gdzie współtworzę te produkty z klientami i staram się wspomagać ich w etapie wytwarzania, oprogramowania, w znajdowaniu pomysłów, walidacji tych pomysłów, to tak w dużym skrócie chyba można by opisać.

Bartek Śliwa: Okej. Skromny gość się trafił. Czym jest ten mityczny vibe coding? No bo teraz bardzo często słyszymy o tym, istnieje takie przeświadczenie, mam nadzieję, że szybko obalimy, albo i nie, że w zasadzie napiszesz czego potrzebujesz i w kilkanaście, kilkadziesiąt minut będziesz mieć gotową aplikację i generalnie możesz zwojować świat. Więc jak to jest naprawdę?

Michał Wilk: Mhm. Termin coding to taki ukuty przez Andreja Karpatiego. Termin, który został słowem roku, jak powiedziałeś. Andrej jest byłym szefem AI w Tesli, też współzałożycielem Open AI i obecnie pracownikiem Antropic. I on w poście na na Twitterze, jak się nie mylę, opisał to w ten sposób, że no definicja jest prosta, czyli piszesz naturalnym językiem, otrzymujesz działającą aplikację i nie sprawdzasz kodu, nie weryfikujesz go linijka po linijce, tylko sprawdzasz, czy robi to, co chciałeś. Pure vibes. Stąd właśnie Vibe coding. Ogólnie uważam, że to co powiedziałeś, czyli stworzenie aplikacji w kilkanaście minut, w kilka godzin jest możliwe. Tylko…

Bartek Śliwa: to jest ten moment, w którym deweloperzy pakują plecaki?

Michał Wilk: Nie, to jest moment, w którym oni mają jeszcze więcej roboty. Hmm, bo musimy sobie ograniczyć budowanie aplikacji na na ten kod taki zły, którego nie da się reużyć, który vibe coding jest świetny w dostarczaniu tego i inżynierii oprogramowania. Na LinkedInie ostatnio widzę bardzo dużo takich skrajnych komentarzy, że vibe coding jest najlepszy, on rozwiązuje wszystko, nie? To są też artykuły w różnych portalach branżowych, które mówią, że nie będzie kodu, nie będzie programistów, nie. Ale jest drugie spektrum ludzi, który mówi, że vibe coding jest bez sensu i on jest niebezpieczny, nie da się go skalować i tak dalej. Natomiast ja stoję gdzieś pomiędzy, bo uważam, że Vibe coding da się wykorzystać do czegoś fajnego i da się w te kilkanaście minut czy w kilka godzin stworzyć coś, co potwierdza hipotezę. A inżynieria oprogramowania nadal pozostaje skomplikowana i im bardziej komplikujemy ten rynek właśnie tworząc agentów, skalując, im więcej rozwiązań wpływa na bezpieczeństwo, tym bardziej ta inżynieria jest potrzebna. Natomiast Vibe Coding jest super do tego, żeby dostarczyć coś szybko, coś z czym użytkownik może się zapoznać. To w ogóle nie są nowe koncepty. To jest coś, co lata temu było testowane w praktyce, tylko bez takich narzędzi. Teraz mamy narzędzia, które potrafią dostarczyć coś takiego szybciej.

Bartek Śliwa: Okej, czyli mówimy o budowaniu jakiegoś proof of concept, jakiegoś nawet może MVP, tak? Po to, żeby finalnie, jak to się ładnie teraz mówi, zaorać to, co zvibekodowaliśmy i zbudować to od podstaw z należytą starannością, z zachowaniem i jakości, i też zasad bezpieczeństwa.

Michał Wilk: Tak, to jest takie podejście, które mi jest najbardziej bliskie, czyli wykorzystujemy vibe coding podczas discovery. W ramach warsztatów, czy w trakcie, czy jako zwieńczenie tworzymy coś interaktywnego. Nie tworzymy gigantycznego spisu wymagań, makiet w figmie. Nie tworzymy samych domysłów, tylko tworzymy jeszcze coś, co da się klikać, co da się dać użytkownikowi i potwierdzić naszą hipotezę. Nawet można ten proces nieco odwrócić, zacząć od tego, dopiero później stworzyć wymagania. A sam prototyp można wykorzystać jako wkład dla zespołu, który będzie dostarczał to docelowe rozwiązanie i dbał o bezpieczeństwo, skalowalność SLA, audyty, RODO i wszystkie inne aspekty, które podczas tworzenia oprogramowania i w całej inżynierii oprogramowania są niesamowicie ważne.

Bartek Śliwa: Okej. Jaka jest różnica w vibe codingu, a takim klasycznym podejściu do budowania proof of concept?

Michał Wilk: Że używamy w dużej mierze języka naturalnego. Nie musimy znać, nie musimy się skupiać na najlepszych praktykach, nie musimy pamiętać o testowaniu, nie musimy rozwiązywać wszystkich standardowych problemów na tym, który właśnie uporządkowany kod dbający o architekturę, o bezpieczeństwo, który o to by dbał, wystarczy, że promptujemy i to jest taka główna różnica, bo to pozwala nam dostarczać szybciej, Nie, nie lepiej, ale szybciej działające rzeczy z cały czas mając w głowie ten podział, tak? Czyli że Vibe coding jednak służy do Discovery i jego celem jest wyrzucenie do kosza. On on ma wylądować w koszu docelowo i im więcej do tego kosza prototypów wpadnie, tym lepiej, bo bo tak budujemy oszczędności wbrew pozorom, bo coś co potwierdza naszą hipotezę albo ją deprecjonuje możemy możemy zwalidować bardzo szybko.

Bartek Śliwa: Myślę, że to jest kluczowy wniosek, który decydenci powinni ze sobą wziąć, czyli ta możliwość nie przywiązania się do swojego pomysłu, a wręcz… No i tak możemy mieć tych pomysłów nieskończenie wiele. Może nieskończenie wiele, to by to akurat zakrawałoby o bankructwo, ale jednak dużo z założeniem, że są to pomysły, testujemy, a potem część z nich trafi do kosza. A część być może pewnie jakaś mniejsza trafi do jakiegoś wdrażenia produkcyjnego i to są praktyki praktycznie każdego venture capital każdego startupu.

Michał Wilk: Jest jedno zdanie. Pomysły są tanie, nie? To to jesteśmy w stanie wygenerować może i nieskończoną liczbę pomysłów, ale jak sprawdzić, czy one faktycznie przynoszą nam wartość? No zrobić to jak najtaniej, jak najszybciej. Pamiętam historię z jednego VC, gdzie gdzie partner tego VC opowiadał, że studentka wpadła na świetny pomysł aplikacji do wypożyczania sobie chyba ciuchów. No i on zapytał: “Ale czy ludzie tego chcą?” No ona nie wie, ale ma świetny pomysł. No mówi: “dobra to wyś przyklej sobie na kartkę swojego kartkę na drzwi swojego akademika z pytaniem, czy ktoś chce pożyczyć ciuch.” No okazało się, że nikt nie chciał i dzięki temu zaoszczędziła tonę czasu na wdrożenie tej aplikacji. I to są praktyki ze startupów, które wielkie organizacje tak jakby wyparły, po prostu zapomniały o tych praktykach i…

Bartek Śliwa: albo nigdy się ich nie nauczyły.

Michał Wilk: Albo i nigdy się ich nie nauczyły. Natomiast jest to coś, co zdecydowanie warto praktykować właśnie po to, żeby po prostu oszczędzać te długie miesiące analizy i jeszcze dłuższe miesiące wdrożeń. Tylko po to, żeby się okazało, że użytkownicy na przykład nie korzystają z docelowego rozwiązania.

Bartek Śliwa: Kiedy był ten moment, ten pierwszy moment, w którym stwierdziłeś: “Kurde, ten vibe coding działa?” No napisałem gościowi taką instrukcję, co bym chciał otrzymać i w zasadzie to otrzymałem. pewnie jako purysta, programista, lider techniczny, stwierdziłeś od razu, nie, ten kod jest beznadziejny, no ale zakładam, że przespałeś się tym i stwierdziłeś: “No ale to działa, można coś coś z tego zrobić”.

Michał Wilk: Tak było. No to tak jakbyś czytał mi w myślach z tym, bo…

Bartek Śliwa: Ja to znam też prawda.

Michał Wilk: Ja lubię czysty kod i lubię jak są zachowane najlepsze praktyki. Wszystko jest reużywalne i i pięknie zbudowane. Natomiast od pewnego czasu w dużej mierze, no już nie siedzę w kodzie już nie tworzę rozwiązań stricte jako programista i bardziej jestem zaangażowany na etapie discovery właśnie i zauważyłem że pewne rzeczy które do tej pory rozwiązywaliśmy właśnie taką analizą, zbiorem wymagań, gdzie tworzyliśmy interaktywne prototypy w Figmie to to nadal jest pomocne. Ale jak modele stały się lepsze, szczególnie tam Sonet, wszedł Opus i sprawdziłem kilka rozwiązań, zrobiłem sobie kilka prób, no te efekty były naprawdę fajne. Wtedy tak mówię, kurczę, to dałoby się naprawdę zrobić dużo w tym, na tym etapie Discovery, po prostu przetestować, spróbować. Tym bardziej, że nie kosztuje nas to więcej niż jedną miesięczną licencję za 20$ i kilka promptów. Oczywiście te efekty nie są idealne, chociaż znowu są głosy, które które mówią, że są w stanie ten vibe coding doprowadzić na produkcję. No ale dla mnie to to był ten moment, w którym po prostu miałem jakiś pomysł i chciałem zobaczyć, jak by to mogło wyglądać. Nie jestem designerem, więc też nie miałem świetnego pomysłu na UX, ale jeden prompt i wszelkie moje wątpliwości zostały rozwiane. Oczywiście było tam dużo niedociągnięć, ale właśnie jak się nie mylę to Opus bardzo mocno bardzo mocno wpłynął na ten proces.

Bartek Śliwa: Okej. Z każdą nową technologią jest tak, że osoby ze świata technologii podchodzą do niej jak do jeża. A teraz zróbmy krok wstecz i wyobraźmy sobie, że jesteśmy osobą, która nie jest ze świata technologii. Jestem pracownikiem biznesowym, back office’owym. A czy vibe coding jest dla mnie?

Michał Wilk: Ja myślę, że każdy kto potrafi pisać w Wordzie jest w stanie vibe kodować. Mamy narzędzia, które zostały stworzone w jednym celu, czyli żeby właśnie jak najbardziej odseparować użytkownika od tego kodu i tylko dostarczać interfejs. Oczywiście to jest nadal techniczne w jakimś stopniu, ale Lovable, Base 44 czy jeszcze inne narzędzia, one naprawdę skupiają się na tym, żeby całą tą otoczkę inżynierii oprogramowania, która jest niezwykle ważna, uprościć do minimum i pozwolić użytkownikom tworzyć, nawet użytkownikom nietechnicznym, rozwiązania. Jeszcze jest ten aspekt, że no żyjemy w czasach, w którym ta technologia jest wszędzie. Nie da się jej uniknąć.

Bartek Śliwa: Znam takich.

Michał Wilk: Okej, no to się da uniknąć. Natomiast przetestować można i nie kosztuje to nic, bo większość tych rozwiązań ma po prostu darmowe plany, w których można spróbować puścić jednego prompta i zobaczyć co wyjdzie. Jeśli w kimś to otworzy chęć rozwijania się w tym obszarze, no to tym lepiej. Natomiast spróbować zawsze warto. To ja bym to tak..

Bartek Śliwa: okej. No i właśnie pociągnijmy ten wątek. Wątek testowania pomysłów, jak ten proces powinien wyglądać, a może właśnie nie potrzebujemy jakiegoś specjalnego procesu, żeby będąc pracownikiem nie technologicznym, nie technicznym, ale mającym jakiś pomysł na zasadzie okej, przydałoby mi się takie i takie narzędzie, chcę spróbować to zvibe kodować, a potem przedstawić tą moją inicjatywę gdzieś wyżej, żeby dostać już budżet na wdrożenie tego.

Michał Wilk: Okej, to ja pierwsze pytanie, jakie bym sobie zadał i to nie będzie nic odkrywczego. To jest standardowe pytanie z obszaru startupów. Jaki problem rozwiązujemy, jaką hipotezę walidujemy, co my chcemy tak naprawdę rozwiązać, jaka jest bolączka.

Bartek Śliwa: Czyli to jest to, o czym mówiłeś. Odsiewamy pomysły od faktycznych hipotez, czyli gdzie chcemy zobaczyć ten ten uzysk.

Michał Wilk: Tak, bo znowu pomysły są tanie, ale faktyczne rozwiązania problemów to jest to, czego szukamy. Co chcemy zoptymalizować, gdzie jest ta wartość. Szukamy wartości. To jest taka pierwsza rzecz. Druga sprawa to jest sama walidacja i myślę, że to jest najważniejsze pytanie, czyli kto i kiedy zobaczy taki prototyp, bo świetnie, że zarząd da budżet, tylko że to nadal będą domysły. Nawet jeśli zbudujemy sobie coś, zvibe kodujemy fajną aplikację i będzie super piękna będzie miała animację. Ekstra. Tylko co z tego, jeśli użytkownicy, gdy to dostaną stwierdzą, że nie potrzebują tego, nie? No i najprościej wyznaczyć sobie użytkowników i iść do nich z tym, przetestować. Jasne, to nie będzie pełne rozwiązanie, to będzie wydmuszka można powiedzieć, ale to już jest coś. A taka trzecia sprawa, no to kiedy to zobaczą? Bo jeśli mamy to odwlekać, szczególnie to ważne jest w organizacjach, nie? Gdy odkładamy coś na kiedyś, tak to się często staje, nigdy. Więc najlepiej iść z tym prototypem, dopytać o feedback i albo pivotować, albo szukać innego pomysłu. Na pewno nie bać się wyrzucić tego pomysłu do kosza, bo prawdopodobnie czas, który nad tym spędziliśmy będzie relatywnie mały w stosunku do tego, gdybyśmy poszli za tym pomysłem i próbowali go wdrożyć i później się okazało, że ci użytkownicy nie chcą z tego korzystać.

Bartek Śliwa: No właśnie. Ile czasu spędziliśmy na stworzeniu naszej pierwszej aplikacji vibe kodowej? Wracamy do case’u, gdzie jestem pracownikiem nietchnologicznym, nietechnicznym. Mam pomysł i bardzo często nas jako ludzi przytłacza jakiś nowy koncept. Tak, chcemy czegoś spróbować, ale nauczeni doświadczeniem wiemy, że po hiszpańsku dogadamy się jak będziemy co najmniej pół roku siedzieć na Duolingo, nie? I jak to wygląda z tym vibe codingiem? Czy powinniśmy zarezerwować sobie siedem weekendów, żeby się tego nauczyć, czy możemy podejść do tego z marszu?

Michał Wilk: To jest dobre pytanie, bo w Dolinie Krzemowej ostatnio słyszałem, że wykuł się nowy termin AI vampire. Są te osoby, które tak bardzo pochłonęło vibe kodowanie i orkiestracja agentów, że nie śpią, tylko się skupiają nad tym, żeby odpowiedni prompt puścić w odpowiednim czasie, dać odpowiednie uprawnienia i tak dalej. Więc nie zachęcam do tego zdecydowanie. Uważam, że to jest bardzo zależne od osoby i tego ile ma czasu, żeby poświęcić na na taki proces. Natomiast fajnie sobie dać sztywne RAM, na przykład stwierdzić, że do końca tygodnia chcę mieć działający prototyp mojego pomysłu. To wszystko będzie zależało od pomysłu, ale my osiągaliśmy efekty tak szybko jak w kilka godzin. W kilka godzin byliśmy w stanie na przykład, nie wiem, dostarczyć działający chatbot spięty z lokalnym modelem LLM i kilkudziesięcioma funkcjami, które pobierały dane i to zajęło trzy godziny na przykład, nie? Natomiast są rozwiązania, które po prostu potrzebują więcej czasu i w zależności od stopnia zaawansowania danej osoby to zajmie trochę więcej, ale my to jesteśmy w stanie robić w ciągu tygodnia, więc ten termin, ten deadline no nie powinien raczej być dłuższy na przetestowanie jednego pomysłu. Chcemy to zrobić szybko.

Bartek Śliwa: Okej. A czy jest jakiś typ, kategoria pomysłów, które do tego vibe codingu nadają się lepiej niż inne?

Michał Wilk: Na pewno wszystkie aplikacje z interfejsami, w sensie aplikacje webowe mobilne, gdzie mamy dużo elementów graficznych, to jest to jest na pewno taka klasa, którą możemy świetnie sprawdzić. Aplikacje backofficeowe, interfejsy użytkownika, no to jest to jest ta klasa, która w którym llmy sobie świetnie radzą, ale nie tylko. Proste rozwiązania backendowe, gdzie nie mamy bardzo dużo integracji, chociaż integrację również jesteśmy w stanie w ten sposób tworzyć, ale tu już wchodzimy w ten aspekt techniczny. Więc jeśli podzielimy sobie to na osoby biznesowe i niet techniczne i na osoby techniczne, to raczej myślę, że w stronę interfejsów użytkownika te te biznesowe pójdą. Natomiast programiści i osoby techniczne też znajdą przy vibe codingu coś dla siebie i na pewno będą w stanie przynajmniej jakieś pomysły na poprawę swojego kodu czy dodanie jakiejś funkcjonalności przetestować w ten sposób. I tu też mamy mamy kilka ciekawych przykładów, gdzie gdzie właśnie pomysł kwartałami wisiał w backlogu, bo był zbyt trudny do wdrożenia technicznie. Rok wisiał w backlogu. Dokładnie w ciągu dwóch godzin deweloper sobie zvibe codował rozwiązanie. Miało tam trochę interfejsu graficznego, natomiast też było mocno backendowe. I potem właśnie zakończyli ten etap Discovery, stwierdzili, dobra, dzisiaj to się da zrobić. Więc skupili się na tym, żeby ten kod stworzyć tak, jak się powinno, zgodnie ze sztuką inżynierii i oprogramowania. I to rozwiązanie jest już na produkcji, mimo że rok wisiało w backlogu, nie? To taki ciekawy przykład, gdzie właśnie ten aspekt i biznesowy i techniczny jest po potwierdzeniu z użytkownikiem, ta funkcjonalność w końcu została zaopiekowana.

Bartek Śliwa: Szkoda, że do Sejmu nie da się wprowadzić vibe codingu, żeby z tej sejmowej zamrażarki trochę pomysłów wyciągnąć. Taka dygresja, może nasi decydenci coś zrobią w tej sprawie. Zainspirowany tym, co powiedziałeś zakładam, że część product ownerów czy właścicielów biznesowych jest w stanie właśnie zerknąć na ten spód swojego backlogu. Rzeczy, które fajnie byłoby zrobić, ale nigdy nie było na to przestrzeni czasu, bądź też właśnie wydawało nam się, że coś jest za duże, a dzisiaj z tymi narzędziami, które są dostępne, być może nie jest to już tak ciężkie, nie jest to tak kosztowne i możemy spróbować do tego podejść.

Michał Wilk: Zdecydowanie to właśnie, nawet bym powiedział, że głównie analitycy biznesowi, product ownerzy, designerzy to są świetne narzędzia do przetestowania przez nich i każdy ma swój warsztat, każdy ma swoją specjalizację i każdy jest też w stanie wnieść coś istotnego do takiego prototypu. Designer się bardziej skupi na UX, analityk bardziej na danych, deweloper nad tym, jak najszybciej to potem wdrożyć i jak najwygodniej. Natomiast myślę, że to są narzędzia właśnie zdecydowanie dla nich i bardzo pomagają w pokazywaniu tego, co ma się w głowie, a nie pracy na domysłach.

Bartek Śliwa: Okej. Czy twoim zdaniem C-level powinien rozumieć vibe coding?

Michał Wilk: Zdecydowanie tak.

Bartek Śliwa: Dlaczego?

Michał Wilk: Zdecydowanie tak, bo to jest coś, co też mogą przetestować sami. Wiem, że prawdopodobnie nie mają czasu na na tworzenie pełnych rozwiązań. Natomiast znowu to jest, widziałem projekty czy zespoły, w których to się stało językiem komunikacji, gdzie po prostu rozmawialiśmy na spotkaniu, zmieniając prototyp zgodnie z życzeniem użytkownika. Więc wszędzie gdzie C-level jest zaangażowany w ogóle w produkt w jakimś stopniu, uważam, że Vibe coding powinien rozumieć, powinien rozumieć gdzie jest ta granica przede wszystkim. Także że to nie jest tak, że my w kilka godzin stworzymy teraz zwipe kodowaną aplikację i jutro jesteśmy w stanie ją wydać na produkcję, bo to nie zabezpiecza nas, to nie pozwala nam się skalować, to nie dba o podstawowe zasady w stylu RODO i tak dalej. To vibe coding zostaje po stronie Discovery. Już wspomniałem o tym chyba ze trzy razy, ale myślę, że to warto podkreślić, żeby C-level po prostu rozumiał, że to nie są gotowe rozwiązania. Przynajmniej mówiąc o takich średnio dużych aplikacjach. To to na pewno nie są gotowe rozwiązania.

Bartek Śliwa: Pociągnij ten wątek. Jak można użyć weapodingu jako narzędzia do komunikacji między biznesem a IT?

Michał Wilk: Mhm. Jasne. To przykład z projektu, gdzie współpracowaliśmy z klientem. Klient.. może inaczej, product owner w tym zespole zaczął używać lovable konkretnie tego rozwiązania do tego, żeby i analizować i projektować finalne rozwiązania z użytkownikami. Czyli użytkownicy nie do końca wiedzieli jakie mają możliwości. Chcieli tam zrobić akurat jeden system backofficeowy i chcieli usprawnić pracę, ale nie za bardzo wiedzieli właśnie jakie mają możliwości, jak mogą to zrobić. No więc na spotkaniu godzinnym Product Owner przygotował kilka prototypów, pokazał im opcję, oni sobie to przetestowali na oczywiście sztucznych danych, ale w tym przypadku nie miało to znaczenia i wybrali drogę. To trafiło do zespołu. Zespół też zgłosił swoje uwagi. Poprawili prototyp i stworzyliśmy pętlę feedbacku, w której użytkownik jest włączony od samego początku. Czyli to nie jest tak, że budujemy rozwiązanie przez miesiąc, dajemy to użytkownikowi, on mówi: “A to nie jest to, co chcieliśmy, tylko są zaangażowani wcześniej”. Dodatkowo nawet od samego początku. I dodatkowo możemy w tym procesie włączyć innych stakeholderów. Możemy w to włączyć C-level. Przykład z Klarny, tam CEO jest nietechniczny i tworzy takie rozwiązania i waliduje je z użytkownikami, nie? To jest takie bardzo rynkowe pokazanie, że da się ten proces wykorzystać również w C-level.

Bartek Śliwa: Okej. A gdzie jest ta granica, bo wspomniałeś o niej, gdzie no niestety już ten vibe coding przestaje być wystarczający i trzeba zadzwonić po autobus deweloperów?

Michał Wilk: Ja bym powiedział, że bardzo proste rzeczy, które też szczególnie IT tu będzie na pewno oponowało, jeśli chodzi o coś, co dotyka naszej infrastruktury, nie? to tam na pewno nie chcemy wrzucać niesprawdzonego kodu, nieprzetestowanego kodu. Natomiast my z powodzeniem właśnie w tym projekcie, o którym wspomniałem przed chwilą, wrzucaliśmy statyczne formularze, takie marketingowe formularze na stronę, których nie musieliśmy budować za pomocą żadnego CMS-a i tak dalej, tylko prosty formularz 5 minut jest gotowy, nawet bardziej skomplikowany. No ale to jest taki aspekt prostych aplikacji, nie? Coś, co już jest średnio i i bardziej rozbudowane. No tutaj bym nie ryzykował i pod żadnym pozorem nie wrzucał tego bezpośrednio na produkcję. Chyba, że zespół Delivery zdecyduje, że ten kod jest odpowiedni, że zweryfikuje wszystko. Natomiast znowu my chcemy użyć vibe kodowania do potwierdzania hipotez, potem dać to zespołowi, który stwierdzi co dalej zrobić, bo jeśli to jest małe rozwiązanie, może nawet wykorzystają część kodu. Jeśli to jest bardziej rozbudowane rozwiązanie, to być może będą chcieli to przepisać. Przy czym nadal istotny jest aspekt tego, że używamy AI w zasadzie w każdym etapie wytwarzania oprogramowania, więc po stronie Delivery to też jest wspierane AIem i tam też tylko w trochę inny sposób. Budujemy skille, tworzymy agentów, którzy nam pomagają dowodzić ten kod, ale ze zdecydowanie większą kontrolą człowieka w przeciwieństwie do vibe codingu, nie? Gdzie tej kontroli nad samym kodem nie ma, gdzie tam po prostu budujemy w oparciu o ten język naturalny.

Bartek Śliwa: Okej. A czy przychodzą ci na myśl jakieś pułapki, w które można wpaść zatracając się w świecie vibe codingu?

Michał Wilk: No można, bo to jest uzależniające trochę, nie? Jest w końcu coś, co było taką hermetyczną puszką, do której nikt nie której nikt nie mógł otwierać, czyli całe oprogramowanie, nie? Część biznesowa nigdy tam nie miała wstępu, nie rozumiała co się tam dzieje. No teraz jest w stanie tworzyć coś namacalnego. Ważne jest to zrozumienie, czyli znowu ta druga strona medalu, czyli że to nie jest gotowe rozwiązanie. Czyli przestrzegałbym przed tym zachłyśnięciem się tą technologią, tą możliwością, którą daje teraz AI, że stworzymy aplikację i to już jest gotowe. Tak, czyli najgorsza najgorszy możliwy scenariusz jest taki, gdzie CEO przyjdzie z aplikacją i powie: “Jutro to chcę widzieć na produkcji”, nie? To to tak nie działa, to się nie zeskaluje, to nie będzie bezpieczne. Natomiast nadal pozwoli to coś zweryfikować, tak? Pozwoli to zwalidować hipotezę. Więc jeden aspekt to jest to, że to jest uzależniające i przyjemne i to tworzenie, ten proces kreacji czegoś no jest po prostu przyjemny dla nas. No ale z drugiej strony jest to, żeby mieć na uwadze, że to nie są rozwiązania takie production ready, które możemy wdrożyć przynajmniej od pewnego tam stopnia skomplikowania.

Bartek Śliwa: Czy jest jakaś taka uniwersalna rada, którą mógłbyś dać naszym widzom i słuchaczom, gdyby stwierdzili, że w najbliższy weekend może pogoda nie dopisze, deszcz będzie padał i chcą spróbować sobie vibe codingu?

Michał Wilk: Okej, to wyciągnąć z szafy listę swoich pomysłów.

Bartek Śliwa: Myślałem, że powiesz wyciągnąć z szafy stary komputer z komunii.

Michał Wilk: No w sumie można by, można by, ale wziąć jakiś pomysł, spróbować go opisać, pod kątem tego, jakie ma mieć funkcjonalności, jaki jest cel tej aplikacji. Im więcej, tym lepiej tutaj nadać tego kontekstu, tak? Czyli nie pisać, że zbuduj mi aplikację produkcyjną, bezpieczną i i gotową do wdrożenia, tylko opisać funkcjonalności, stworzyć ten dokument, ten zbiór wymagań i wybrać dowolne narzędzie, dowolne narzędzie pierwsze, które wpiszemy vibe coding na przykład i które wyskoczy w stylu lovable, base 44, Claude, tego jest naprawdę naprawdę mnóstwo. Zalogować się i puścić tego prompta puścić, wkleić po prostu ten zbiór wymagań i spróbować. Więcej nie potrzeba. Próg wejścia jest naprawdę zerowy. Myślę, że ze wszystkich tych narzędzi to osobiście właśnie base 44, Lovable mogę polecić do takiego szybkiego eksperymentowania. Jest po prostu świetna i nastawione właśnie na to, żeby dawać fajne rezultaty wizualnie i też działające aplikacje.

Bartek Śliwa: Na koniec pytanie charakterystyczne d naszego programu. Co cię ostatnio zainspirowało?

Michał Wilk: Tak, najbardziej ostatnio takim najświeższym wydarzeniem to myślę, że to jest nasza AI decision room, który poprowadziliśmy w środę i…

Bartek Śliwa: trzeba cię było za uszy wytargać.

Michał Wilk: To to było dopiero inspirujące, nie? Natomiast rozmowy, które tam odbyłem, bardzo, bardzo fajna sprawa, gdzie mogliśmy się spotkać właśnie z C -levelem i nie tylko i podyskutować o tym, w którą stronę zmierzamy. I też bardzo dużo poruszaliśmy tego vibe codingu i jak to wykorzystać w praktyce, jak duże organizacje, naprawdę duże organizacje mogą zastosować to i też o tym jak szkolić pracowników w wykorzystaniu tych narzędzi AI, bo to nie jest takie oczywiste. Myślę, że to było całkiem inspirujące z tego powodu, że też zobaczyłem właśnie z bliska, że ten problem jest namacalny, nie? Nie, że to to nie jest coś, co ja tylko gdzieś spotykam się z tym.

Bartek Śliwa: Tak, tak, mimo że właśnie spotykam się z tym na co dzień, to faktycznie dotarło i widać było, że jest potrzeba tego tego zrozumienia, vibe codowania i i prototypowania. Myślę, że to sam ten event był był bardzo ciekawy i inspirujący.

Michał Wilk: Super. Bardzo ci dziękuję.

Bartek Śliwa: Wam dziękuję za słuchanie i oglądanie i widzimy się w kolejnym odcinku podcastu Euvic Talks.