Szymon Warda: Howdy-ho, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub gdzieś na dole, wierzymy w Was. A Szymon szuka nowego intro, tylko jeszcze znaleźć nie może.

Szymon Warda: Nie, po prostu szukam kto jeszcze kojarzy z czego to jest. Dobrze, Łukaszu, parafialki.

Łukasz Kałużny: Tak. Szkolenia. Niedługo Observability od Szymona, gdzie poznacie jak robić open source’owy nowoczesny stos monitoringu, bez full-text searcha.

Szymon Warda: Tak, ale dość wydajny kosztowo i całkiem przyjemny w wykorzystaniu.

Łukasz Kałużny: Dobra i trochę już też drugie kultowe szkolenie, czyli Architektura 101, czyli jak myśleć i projektować systemy w sposób merytokratyczny czy też minimalistyczny i spełniający swoje rzeczy, a nie będący kolejnym opus magnum.

Szymon Warda: Tak, dobra. Mamy podejście dzisiaj do tematu, który mi trochę pachnie tematem, który skończył się na trzech nieopublikowanych odcinkach, więc dzisiaj będzie o vibe codingu. Łukasz, czym jest vibe coding?

Łukasz Kałużny: Dobra, wymyślił tą definicję Andrej Karpathy. Andrzej Karpaty, który był cofounderem OpenAI, a potem AI liderem w Tesli. Wymyślił to parę miesięcy temu, w lutym 2025. Pewnie ten odcinek nazwiemy też z datą 2025 Q1, jeżeli wyjdzie, bo będzie się często to zmieniało i może kiedyś jeszcze do tego wrócimy. I vibe coding z założenia to jest po prostu, tak jak kiedyś mówimy: idziemy, idę na kawę, bo się kompiluje albo idę, bo się wdraża na chmurze, to w tym momencie idę na kawę, bo agent AI mi koduje. Czyli założenie jest takie, że sobie tak luźno klepiemy co chcemy w aplikacji i to powstaje. Ja bym tutaj powiedział, że są tego dwie bardzo duże perspektywy i o dziwo, ja dzisiaj mówię o tej firmowej bardziej, wykorzystaniu tego profesjonalnie, a Szymon bardziej poza częścią zawodową.

Szymon Warda: Ja będę podkopywał to. Moje podejście do tego jest podobnie jak do low code’u. Tak, ale i to “ale” jest dość dużo.

Łukasz Kałużny: Zróbmy teraz taki disclaimer rzucił mi się pewien artykuł, którego już nie będę wam promował, tudzież hejt post na LinkedIn’ie, z którym się świetnie zgadzam i jesteśmy raczej w grupie tej hejterskiej, więc nie jesteśmy kolejnymi szamanami AI jak jakiś Kurasiński, Burnejko czy inni z LinkedIna, który: możesz nakodować stronę, możesz zrobić aplikację w 3 minuty i będzie ona na produkcji.

Szymon Warda: Możesz i strony i aplikacje. Strona będzie tą stroną lądującą a aplikacja będzie kalkulatorem.

Łukasz Kałużny: Da radę. I wiecie i teraz jak popatrzymy na to “ale”, to trochę odniesienie do Thoughtworksa. Bożesz, odnoszę się do Technology Radaru z Thoughtworksa, ale w poprzednim odcinku rzucaliśmy na temat, że właśnie nie jest to w firmowym kontekście, że AI nie jest dla kolejnego Shadow IT.

Szymon Warda: Wyjaśniając, bo mogą nas słuchać, czym jest Shadow IT tak naprawdę w tej sytuacji?

Łukasz Kałużny: Czyli Shadow IT, to powstało za czasów początków SaaS-ów i chmury, że biznes poszedł kupować rozwiązania płacąc kartą kredytową i kupował systemy olewając IT zupełnie. Robiąc to zupełnie poza radarem i potem np. nagle na ruchu na proxy czy wyciekach okazywało się, że firma korzysta z narzędzi, z których nie miała korzystać i nikt o nim nie wiedział w IT.

Szymon Warda: Tak, to SaaS-y, przed SaaS-ami też się takie rzeczy działy.

Łukasz Kałużny: Tutaj teraz chodzi o to, że AI ma pomóc stworzyć narzędzia, wspierać procesy bez IT. O, tak więc tutaj w ten sposób. I druga część tego procesu, którą trzeba powiedzieć, to jest fajnie ujęte jako samozadowolenie z wygenerowanego kodu przez AI, że to jest super. I tutaj to jest chyba najsłuszniejsza obawa, że nie zwalnia nas ten vibe coding i cały ten prompting, nie zwalnia nas z krytycznego myślenia.

Szymon Warda: A się dorzucę, że to krytyczne myślenie zaczyna, trzeba dość wcześnie w to wszystko włączyć. Bo ten kod często wygląda bardzo ładnie i niewiele robi, albo nie robi to, co powinien robić.

Łukasz Kałużny: Albo jest takim spaghetti… Inaczej, albo przypomina projekt studenta.

Szymon Warda: Tak, który właśnie dowiedział się o design patternach.

Łukasz Kałużny: Tak, dokładnie. Więc słuchajcie teraz, jak popatrzymy na to krytyczne myślenie, to trzeba wypracować swój flow w ogóle pracy z tymi narzędziami. To jest w ogóle, o narzędziach jeszcze wspomnimy, co z naszej strony rekomendujemy, ale bez takiego flow i zrozumienia nie ma sensu do tego podchodzić, jeżeli sobie… Inaczej, należy sobie wypracować taki swój mechanical sympathy, żeby rozumieć jak to działa. Wypracować.

Szymon Warda: Jaki jest Twój…

Łukasz Kałużny: I mój flow jest następujący: AI ssie jak musi zrobić dużo naraz. To jest w ogóle…

Szymon Warda: Doszczegółowię, jak musi zrobić niekoniecznie dużo czynności, ale też nawet bardzo dużych dokumentach.

Łukasz Kałużny: Tak, albo ma duży kontekst do ogarnięcia rozproszony.

Szymon Warda: Tu się zgodzimy. Zaczyna to szybko być, gubić rzeczy, usuwać, nie robić tego, co się miało robić, nie odnosi się do poprzednich rzeczy. Ok, dobra, zgadzamy się.

Łukasz Kałużny: Dobra. I tutaj wygląda to tak, że w zależności co robię, tutaj będzie bardzo to różnie wyglądało, ale powiedzmy, że robimy research. I to jest zrzucenie linków, które przerobię sobie potem na markdowna jako wsady np., ustalę wersję biblioteki, jakie potrzebuję patterny użyć, czyli zrobię sobie oględnie, tak jakbym dał szablon, taki zestaw dokumentacji, którą muszę wrzucić do ambitnego juniora. Czyli wskażę, która biblioteka, które mniej więcej chcę rozwiązanie. Ewentualnie wykorzystam sobie jakiegoś LLM-a, żeby z nim poczatować i poodbijać piłkę i poszukać kierunku.

Szymon Warda: O właśnie, i to teraz wracamy do tego. Ja będę dziś trochę konkrety przyciskał, bo pewne rzeczy mi działają, pewne rzeczy mi nie działają. Czy research też LLM-em?

Łukasz Kałużny: Wiesz co? To zależy od części. Jeżeli chodzi o szukanie źródeł online, Perplexity ssie pałę nawet w deeply searchu i mocno halucynuje. Chiński DeepSeek używam do publicznych rzeczy, żeby znaleźć sobie publiczne rzeczy. Robi to ciutkę lepiej, znajduje źródła. Ale nadal taki research, jeżeli chodzi o materiały, to jest moje szukanie. Ewentualnie używam go, żeby odbić sobie piłeczkę, że np. szukam podobnego narzędzia do.., albo chcę zrobić koncepcję, weź mi podsuń, to zwykle Chata GPT z web searchem wykorzystuję do tego, że weź mi poszukaj czegoś, co spełnia taką koncepcję np. I wtedy sobie idę i przeglądam. Czyli to jest takie pierwsze, żeby zacząć, wiem, co mniej więcej chcę osiągnąć, weź mi pokaż kierunki, które są.

Szymon Warda: Ok, z tym się zgodzę. Faktycznie wykorzystanie do czegoś takiego, sam też to korzystam, że mam jakiś temat, pokaż mi w ogóle jacy są gracze na rynku, na jakie to się grupy dzieli i w ogóle w jakich kontekstach na ten problem patrzeć. Tak, to do tego się zgadza. Jeśli idzie o aktualność linków, ja bym powiedział, że średnio.

Łukasz Kałużny: Dlatego powiedziałem DeepSeeka z web searchem. DeepSeeka, Perplexity tak sobie, jestem zawiedziony coraz bardziej tym deep searchem w Perplexity. Web search w Chacie GPT nawet nawet tym darmowym działa.

Szymon Warda: Ja bym powiedział, że jest ok. On dla wielu jest okej. Okej, czyli zgadzamy się. Czyli inicjalne obeznanie tematu jak najbardziej, ale potem manualna robota.

Łukasz Kałużny: Tak. I z drugiej strony też jak mam jakiś pomysł, to pingpongowanie: weź mi skrytykuj. Czyli jak nie mam jak do Ciebie zadzwonić albo do Marka, to idę, żeby zimne wiadro poleciało ze strony właśnie… Tutaj wykorzystuję Claude teraz tym thinking modem, żeby komentował mi moje pomysły. Tak zupełnie wrogo.

Szymon Warda: Dobra, kolejny krok.

Łukasz Kałużny: No i to jest teraz mój dump z mózgu. Czyli mam te wszystkie materiały, mam te wszystkie materiały, mam moją sieczkę, którą Szymon wie jak wygląda. I potem próbuję to ustrukturyzować w jakieś punkty, wymagania. Właśnie za pomocą… Najczęściej ja korzystam z tego Claude do tego, żeby w artefakcie mi zrobił do tego zestaw np. wymagań, rzeczy, które chcę osiągnąć, żeby to w jakiś już bardziej czytelny sposób opisał co potrzebuję.

Szymon Warda: OK, czyli tak naprawdę pierwsze to robisz research, potem te materiały czytasz, przeglądasz, zrzucasz, do tego dorzucasz jakieś tam przemyślenia i mówisz w tym momencie mu, że okej, to weź mi tu ustrukturyzuj.

Łukasz Kałużny: Tak, narzucając mu jeszcze co chcę zrobić i potem pewnie 10, 15 takich iteracji na tym artefakcie, żeby go tak, żebym był zadowolony.

Szymon Warda: O to właśnie chodzi. Czyli za każdym razem, bo właśnie to też jest coś, z czym ja się spotykam, że ten inicjalny wynik, który on wypluje z dokumentów, jest taki często dość naiwny, często dość powierzchowny, ma tendencję, żeby pewne rzeczy omijać. I to jednak jest ta wiedza konieczna, ten research przedwczesny dlatego właśnie, żeby upewnić się, że on niczego nie ominął.

Łukasz Kałużny: Tak. I słuchaj i teraz, bo powiesz: co dalej?

Szymon Warda: No właśnie.

Łukasz Kałużny: Tak, co dalej? I teraz przechodzimy sobie do Copilotów, Cursorów. I tutaj mam zrobiony ten artefakt w Markdownie. Mam jakiś tam np. codebase inicjalny albo to, czym będę wprowadzał zmianę, dorzucał nową funkcjonalność. I tu pojawia się coś takiego, że ja stosuję, Ty zresztą widziałeś ten prompt do analizy. Czyli stosuję prompt do przygotowania planu. I słuchajcie i to jest dla mnie kluczowe. Nie piszę mu, żeby w ogóle zrobił cokolwiek, tylko ja wrzucam takiego Cursora i każę mu dokonać analizy. I analiza leci tak, że ma podejść, jest to właśnie taki, jak polecę, te prompty Wam wrzucę na giście, żebyście zobaczyli, bo to nie jest żadna wiedza tajemna. I jedna rzecz, która jest tutaj istotna w tym, to jest problem solving approach, w którym opisuję w jaki sposób ma to przeanalizować sobie. Drugą rzecz to jest taki project workflow requirements i on się składa z tego, że ma na początek, korzystając z toolców, zaplanować dokumenty. To jest dokument do planów i do tasków z timestampem, żeby była odpowiednio z datą, ma timestampować automatycznie i następnie ma zaplanować, w jaki sposób ma zaimplementować to. Czyli żeby ten agent AI-owy wziął sobie codebase, wziął mój input i przygotował plan implementacji oraz rozbił to na malutkie taski w osobnym dokumencie jako taką TO-DO listę.

Szymon Warda: Ok, ja pokażę jedną rzecz, która jest bardzo, bardzo, bardzo dobra. Wyrzucanie tego do różnych dokumentów i posiadanie stopniowalności, co on ma zrobić, to się faktycznie sprawdza, bo pracowanie cały czas na bieżącym dokumencie okazuje się, że Ctrl+Z nie działa najlepiej. I tak, jak najbardziej, to jest dobra rzecz faktycznie, to się sprawdza. Nie próbujcie robić, ewentualnie miejcie nawet lokalny raport gitowy i róbcie commity pomiędzy kolejnymi iteracjami.

Łukasz Kałużny: Tak.

Szymon Warda: Bo potrafi zgubić, a przy większym [niesłyszalne 00:12:41] pogubicie się: co on właściwie przed chwilą zmienił?

Łukasz Kałużny: Tak i teraz co jest ważne z tego, co powiedziałeś? Jedno to jest critical review. Do tego sobie jeszcze podejdziemy przy tych principalach, które ja mam wrzucone jako ważne i dlaczego, to potem jeszcze to poruszymy. Ale ostatnim punktem mojego planning and documentation jest Request user review. After completing the plan and task list request the users review and approval before proceeding with any code generation. Czyli Ty chcesz zaplanować pracę, a nie generować kodu. Bo jak popatrzymy np. Sonet od Anthropika chce rozwiązywać od razu problem i generować kod. Nie, musimy go jak juniora zmusić do myślenia i zaplanowania pracy.

Szymon Warda: Tak. Myślę, że jak się go puści samopas, w sensie, że od razu działaj, tam się dzieją dziwne rzeczy. Często faktycznie potrafi zgubić to, co miał zrobić, albo załóżmy np. iteracyjnie: okej, teraz wprowadź taką zmianę, np. nagle wycofuje poprzednie rzeczy.

Łukasz Kałużny: Leci nie wiadomo gdzie w ogóle. Dobra, i jak zrobimy sobie taki plan, będziecie mieli z tego dwa markdowny. I potem przechodzimy do prompta, otwieram sobie już zupełnie nowy czat, nowy kontekst, w którym mówię, że tu masz implementation instructions. I to jest: start implementing according to the task list in i nazwa tego dokumentu, mark task as done upon the completion of each task. Complete one task at time before moving to the next one. Important, remember: focus on one task at the time and mark it as completed when done. I to jest clue potem odpalenia, żeby pójść na kawę.

Szymon Warda: Tak, okej, to się generuje długo. To teraz moje pytanie. Właśnie, bo teraz wchodzimy do tego, że super, masz plan, ale to w tym momencie włączasz. On tam będzie chodził sobie jakiś czas, że sobie kawę spokojnie zrobisz i wypijesz. No ale problem jest taki, że potrafi się pogubić.

Łukasz Kałużny: Wiesz co, tak.

Szymon Warda: Lepiej w tej sytuacji jest powiedzieć, już teraz tak robię, że daję mu task, patrzę co on zrobił, task, patrzę, task, patrzę. Bo jak dałaś mu taką listę dłuższą to potrafi odpłynąć.

Łukasz Kałużny: Wiesz co? Tak właśnie to jest. I powiem Ci to będzie niestety ten, to zależy od poziomu skomplikowania i wielkości kontekstu, który robisz.

Szymon Warda: Od wielkości tego nad czym pracujesz. Bym się z tym zgodził jak najbardziej.

Łukasz Kałużny: Tak, że jak masz mały np… Inaczej, jak mu puszczałem do wygenerowania skrypt czy jakieś tam review i inne rzeczy, w sensie, że był to zamknięty kontekst, tak i nie był, nie walił po kilkunastu plikach i innych takich rzeczach, że był taki mały kontekst, mała funkcjonalność, to puszczałem tą listę, szedłem, wracałem z kawą, klikałem resume, bo na przykład Cursor po 15 albo 25 akcjach prosi Cię, żeby kontynuować, potwierdzić, że ma kontynuować, więc puszczałem i szedłem sobie dalej. Czyli jak miałem zamknięte rzeczy, to w ten sposób. A druga rzecz, kiedy widzę, że to jest cięższy kontekst, to wtedy faktycznie jeden task na raz i potwierdzanie po nim.

Szymon Warda: Okej, okej, okej, powoli będziemy dochodzili do tego, gdzie jest moje największe takie “ale” do całego podejścia, bo ono tam gdzieś się mimo wszystko kryje. Dobra, to teraz przejdźmy dalej. Idziemy konkretnie. Narzędzia.

Łukasz Kałużny: Czy wiesz co? Narzędzia, powiem tylko trzy rzeczy. I to jest kontekst firmowy. Nie będę poruszał się w kontekście prywatnym w tym miejscu zupełnie. Najbezpieczniejszym wyborem prawdopodobnie w firmie będzie kupienie GitHub Copilot, bo teraz ma już agent moda. I tyle. I to jest… Może inaczej, czy jest najlepszy? Prawdopodobnie Cursor jest lepszy. Czy są jeszcze bardziej intuicyjne rozwiązania? Tak, są, ale jeżeli popatrzymy sobie, przekrój, compliance, cennik, governance ogólnofirmowy i inne takie rzeczy, to jest najlepszy w tym momencie z tych agentowych, w takim przekroju firmowym. I to jest pierwsza rzecz. Drugie podejście to jest Cursor, czyli kupienie Cursora.

Szymon Warda: Okej, to jeszcze rzucę kawałek. A czemu GitHub Copilot w modelu agentowym, a nie Cursor firmowo? Do użytku osobistego moim zdaniem Cursor wygrywa, to w ogóle bez dwóch zdań.

Łukasz Kałużny: Tu i tutaj w ogóle nie ma, wiesz, nie ma w tym. My firmowo też wykorzystujemy. Tylko wiesz co, brakuje mi z takich rzeczy, jak popatrzymy, jak popatrzysz na ceny, to zobacz, że musisz kupić już wersję typowo biznes, żeby wjechać też. I widzisz, teraz jak popatrzysz, tu Cursor musisz wjechać, żeby mieć OIDC, scentralizowany billing i inne takie rzeczy. Wymuszanie też privacy mode’u. Musisz polecieć w tą wersję najdroższą.

Szymon Warda: Ok, lecimy w tym momencie cennikowo albo idziemy wersją tańszą i tracimy pewne rzeczy do zarządzania centralnego.

Łukasz Kałużny: Tak, to zależy. Jak wiesz, w przypadku naszego butiku wygląda to inaczej niż miałbyś teraz naszemu klientowi polecić. Druga sprawa, że wtedy polecisz, jak jesteś w większej skali, to też prawdopodobnie zaczniesz wykorzystywać GitHuba i inne feature’y, które tam się pojawią.

Szymon Warda: Ok, dobra, no to lecimy i masz dalej ostatnie narzędzie, bo to jest też takie…

Łukasz Kałużny: Tak i to jest taka rzecz pod tytułem jak słyszycie: jakiś czat.

Szymon Warda: Ok, teraz właśnie tak Cię trochę schallenguję pod tym względem, bo mówimy sobie, że okej, do dużych zestawów kodu to się nie do końca nadaje. Mówimy też o tym, że mówimy teraz o kontekście firmowym.

Łukasz Kałużny: Tak.

Szymon Warda: To teraz jaki jest zysk tak naprawdę i zysk vibe codingu pomiędzy pracą w Cursor + np. załóżmy Claude, a sam Claude w UI-u. Skoro i tak wiemy, że w wersji dużych baz kodu nie nadaje się za bardzo.

Łukasz Kałużny: Raczej tak, czaty w ogóle wiesz, z dużą sobie nie poradzą. Może powiem Ci tak, dla mnie game changerem nie był jeszcze Copilot i te completion, które jest, czy w Cursorze, tylko realnie ten tryb agentowy zrobił różnicę, że potrafi Ci edytować wiele plików i innych rzeczy. Bo zobacz, że jak wygenerować snippet kodu, generacja snippetu kodu czy kawałku skryptu w takim zwykłym czacie jest good enough. Jak masz sobie zacząć grepować, analizować… Inaczej, to jest to co mówimy, że użyj LLM-a do zrozumienia większego code base. Te rzeczy, które są do automatycznego grepowania kodu np. w takim Cursorze… Zobacz, że Cursor, jednym z takich killer feature’ów jest robienie embeddingów i RAG-a z Twojego codebase również, jak popatrzysz, żeby go lepiej, ten kontekst zaciągnąć.

Szymon Warda: Okej, zgodzę się, tylko znowu, właśnie, bo ja właśnie często dochodzę do takich momentów, że realnie w trybie agentowym i dochodzę dość szybko do ściany, że on po prostu już gubi kontekst albo baza, na której pracuje, jest zbyt duża.

Łukasz Kałużny: Wiesz co, właśnie…

Szymon Warda: I wracam w tym momencie do tego, że jednak te snippety długofalowo się spisują lepiej.

Łukasz Kałużny: Czy wiesz co, dlatego ja podchodzę do rozdrobnienia, stąd ja rzuciłem na przykład mój flow, ja patrzę na to ograniczenie, że te taski muszą być malutkie.

Szymon Warda: Tak, znaczy, to muszą być małe aplikacje. To teraz jak dużo takich małych aplikacji, tych tasków istnieje w kontekście firmowym?

Łukasz Kałużny: Ja może inaczej Szymon. Nie małe aplikacje, tylko małe taski.

Szymon Warda: Tak, ale też pracujemy na małym zbiorze kodu, w sensie… Może inaczej, np. poki? Świetna sprawa. Greenfieldy? Świetnie.

Łukasz Kałużny: Greenfieldy, wiesz co Ci powiem? Tak i to jest jedyna rzecz, w której powiem, że mikroserwisy albo podejście serverlessowe nawet, to jest już chamskie…

Szymon Warda: Serverlessowe.

Łukasz Kałużny: To będzie… Inaczej, na monolicie zginie, na kodzie spaghetti to zginie.

Szymon Warda: Okej, dobra, zgadzamy się.

Łukasz Kałużny: Chociaż teraz to jest ciekawe, bo pozwolę sobie, bo jest to komentarz, może osoba się ujawni w komentarzach, bo nie wolno mi tego powiedzieć, aż muszę wziąć co dokładnie mi napisał. Ale tekst był najwięcej taki, dostałem jakieś: kolega ma kod startupowy w jednym miejscu, taki startupowo-bootcampowy, więc go nie rozumie w ogóle. Trzeba było coś zafiksować i Copilot to zafiksował. On nie rozumie jak, ale jest zafiksowane. Za to wprowadzenie na dobrym codebase poprawek, za każdym razem mu Copilot poległ. Czyli na shitowym codebasie nie było żadnego problemu, mimo że był duży. Na normalnym - gorzej.

Szymon Warda: Bo już niewiele mógł zrobić więcej.

Łukasz Kałużny: Tak.

Szymon Warda: Sorry, tak, proste w skali jednego pliku.

Łukasz Kałużny: Czy wiesz co, powiem Ci tak…

Szymon Warda: Kilku plików, niewielu, może tak, o.

Łukasz Kałużny: Pliku. Wiesz co, jak popatrzymy, biorąc sobie np. .Netem czy… Inaczej, dobrym podejściem, wiesz co, jeżeli ktoś np. by stosował te vertical slice’y. Jak popatrzysz taki vertical slice, gdzie jest kawałek bounded contextu skupiony na funkcjonalności, to może być nawet super. To jest wiesz i teraz trudno mi teraz… To jest na zasadzie, jak z tekstem, jak duży powinien być mikro serwis trochę. To nie jest, nie powiem Ci, wiesz, ile linii kodu np., czy ile ogarnie. Chyba bardziej poziom, greenfield- tak… Może inaczej, PoC-e - tak. Greenfield - tak. Serverless - tak.

Szymon Warda: IaC - tak.

Łukasz Kałużny: To IaC to w ogóle, nawet duży codebase.

Szymon Warda: Znaczący, może tak, nie wiem czy duży, ale będę twierdził, że jednak realny kod biznesowy - nie ma opcji na chwilę obecną jeszcze.

Łukasz Kałużny: Ja tutaj będę adwokatem diabła i powiem: to zależy.

Szymon Warda: Może inaczej, biznesowy w kontekście mówimy firm i korporacji. Tam ta logika będzie zbyt skomplikowana, żeby to jeszcze raz kodować.

Łukasz Kałużny: Dlatego to zależy dokładnie w jaki kontekst, ile, bo wiesz, jaka jest drobnica plików albo ile tak naprawdę linii kodu jest i jak przygotujesz te taski.

Szymon Warda: No tu bym mimo wszystko nawet z super taskami, to jak będzie zbyt duży kontekst do przyjęcia, to on zaczyna się gubić jak patrzę. Dobra, idziemy dalej. Co tam jeszcze jest?

Łukasz Kałużny: Dobra, wiesz co, tylko jeszcze wrócę na chwilę do tematu jakiegoś czata, bo tego nie skończyliśmy. To jakiś czat, czy będzie jakiś tam open sourceowy nakładka i damy klucze do API na firmowym OpenAI z Azure’a, czy… Inaczej, najlepiej weźcie Anthropika z AWS-a, w Bedrocku czy w Google’u, to będzie najlepsze. Ale właśnie dać jakiś czat, żeby takie było coś dostępnego, nad czym mamy kontrolę, bo jest tam zwrot. Jak popatrzysz na te narzędzia, jest zwrot z inwestycji, to jest w mojej opinii przy tej cenie narzędzi. Dobra.

Szymon Warda: No dobra, to lecimy dalej.

Łukasz Kałużny: Dobra. I teraz jest takie clue problemu - prompt bazowy.

Szymon Warda: Po co?

Łukasz Kałużny: Po co? Żeby wysterować te diabelstwo albo inne przekleństwa można byłoby tu użyć, żeby zachowywał się tak, jak sobie tego życzysz. I moja bazówka np., którą Wam wrzucę, jest tutaj pierwsze - śmierdzi prompt engineeringiem niestety. I zaraz wyjaśnię Wam dlaczego tak trzeba zrobić, mimo że mi się to nie podoba. I pierwszym elementem tutaj będzie powiedzenie, że jesteś tutaj doświadczonym inżynierem, który ma strong commitment do pisania czystego, utrzymywalnego, czytelnego kodu. Niestety. I potem ja mam wrzucone tutaj dwie rzeczy, to jest core principles przy generowaniu kodu, czyli takie główne. I u mnie są wrzucone 4 i nie jest to solid. Czyli pierwsze, co jest najważniejsze, KISS: keep it simple stupid, i jest: always prioritize simplicity in your solutions. Complex solutions are harder to understand, maintenant and debug. Czyli pierwsze: nie kombinuj. To jest pierwszy krok. Drugi: nie będziesz tego potrzebować, you aren’t gonna need it, bo w ogóle Sonet na to cierpi. W szczególności ten 3.7 rwie się do generowania abstrakcji tego, co nie potrzeba.

Szymon Warda: Ten kod bardzo ładnie wygląda, niewiele robi, ponownie.

Łukasz Kałużny: Tak, dokładnie. Kolejna rzecz: DRY - do not repeat yourself. I ostatnia, która jest z dużą dozą ostrożności, to jest: SRP - Single Responsibility Principle, bo to jest problem znowu, że próbuje robić za dużo, jak popatrzymy taki prompt. Głównie korzystamy z Soneta, o tak, to też trzeba powiedzieć. I tutaj ten SRP też ma zaznaczone, że ważniejsze jest KISS, YAGNI i DRY, że nie chcemy koniecznie budować kolejnych abstrakcji.

Szymon Warda: Ogólnie kierujesz go w tym kierunku, żeby ten kod był prosty, żeby nie było zbyt dużo, żeby on się za chwilę nie pogubił. Czyli znowu, do tego, żeby ta baza wygenerowana, na której on potem będzie robił kolejne operacje, żeby była nieduża, żeby nie zgłupiał za chwilę.

Łukasz Kałużny: Tak. I dwie rzeczy, które się pojawiają, to jest już bardziej. Jedna to jest preferencja, żeby miał bardziej funkcyjną strukturę, czyli miał takie funkcje INOUT, które zresztą no sorry, tak się powinno też pisać dużo rzeczy i nastawienie na czytelność dla użytkownika, dla odbiorcy. I to jest taka rzecz. I słuchajcie teraz tak, taki prompt trzeba sobie wygenerować. I teraz tak, nie będę Wam mówił, że to jest prompt engineering, musicie teraz przeczytać, kupić kursy i inne rzeczy. Idziecie sobie do takiego Anthropica i wpisujecie: słuchaj, piszę prompt systemowy dla agenta AI, chcę osiągnąć X, Y, Z. Czyli wpisujecie reguły, może styl kodowania i inne takie rzeczy. I mówicie: zrób mi z tego artefakt. Czyli spisujecie to, co chcecie osiągnąć i Sonet naprawdę świetnie przerabia brain dumpa na coś, co będzie używalne.

Szymon Warda: Tak, ładnie obudowuje, to faktycznie jest tego mocna strona, że z badziewia wejściowego potrafi wygenerować coś co w miarę nieźle wygląda.

Łukasz Kałużny: Tak. I to podrzucamy sobie w domyślny prompt w takim Cursorze, w takim GitHub Copilot jako taki domyślny hint do naszego, który jest na stałe już zaszyty jako system prompt. I potem w Cursorze pojawia się coś takiego jak rules, Cursor Rules. Czyli możemy per katalogi, per ścieżki albo typy plików powiedzieć jak ma się dodatkowo zachowywać. I tutaj już są kolekcje typu są super i w ogóle i galerie takich tych, więc warto podejrzeć, co ludzie w nich wpisują. Czyli np. ja tam mam jakieś dla Tailwinda, żeby przypadkiem nie próbował starego generować, w starym, tylko żeby użył jak ma generować w Tailwind 4. Dla Pythona jest ten standard, zawsze zapominam, mam też ten Style Guide for Python Code, tego PEP8 wskazanego. Więc jest ileś takich rzeczy, które wskazujemy sobie jak chcemy, żeby się zachowywał w takich Cursor Rule’ach dla poszczególnych plików.

Szymon Warda: No ok. Dobra, to teraz dochodzimy do kolejnego punktu, który mnie najbardziej interesuje, bo tu się w miarę zgadzamy, powiedzmy mamy tam niewielkie różnice, ja jestem trochę bardzo sceptyczny. Dla kogo to jest?

Łukasz Kałużny: Ty, słuchaj i teraz tak, firmowo uważam, że każdemu w IT, kto… Inaczej, każdemu w IT warto tą licencję wrzucić, czy piszę skrypty, czy koduje, z dwoma uwagami. Pierwsza, jak nie używają, to zabierać od razu licencję.

Szymon Warda: Wiadomo, że każdy będzie niby korzystał.

Łukasz Kałużny: Ale w GitHubie jest to piękne, że sortujesz po Last Access Date i robisz odcięcie.

Szymon Warda: No dobrze, dobrze, dobrze. Czyli każdemu?

Łukasz Kałużny: Tak. I druga rzecz, która jest oprócz zabierania licencji w IT, to jest słowo klucz w IT. Druga rzecz, to żeby zadbać o drobne przeszkolenie, żeby ludzie wiedzieli w ogóle, jak z tym zacząć i jak tego mniej więcej używać.

Szymon Warda: Dobra, to ja mam inne podejście. Realnie tak patrząc na większość developerów aplikacji biznesowych i mówię specjalnie o backendzie, te bazy kodu są z reguły duże i tam zysk z niego… Znaczy nie mówię. Mówię o faktycznie trybie agentowym. Bo generowanie snippetów, przeoranie, tego typu rzeczy, to super działa. Ale np. pracowanie na jakimś brownfieldzie, jest większość użytku, nie widzę wartości do końca. To jest jedna rzecz, tak patrząc. To powiedziałeś, co się zgodziliśmy, dla IaC-a, czyli wszystkich DevOpsów, którzy piszą integracje głównie między systemami, takie proste integracje, jak połączyć A z B i adminów.

Łukasz Kałużny: IaC-e i inne rzeczy. Nie, to wiesz, to jest… Inaczej, w Brownfieldzie powiedziałbym, że jakość tych narzędzi skacze i też za rok to odszczekasz.

Szymon Warda: Nie, nie, ja mówię na chwilę obecną. Na chwilę obecną Q1 2025 i to będzie coraz lepsze, ale na chwilę obecną to jeszcze nie jest ten kawałek zdecydowanie. Ja bym powiedział okej, bo mówimy w kontekście firmowym. Natomiast to jest genialne narzędzie dla kontekstu osobistego. Wszystkie pet projecty, nie rzeczy firmowe, jak najbardziej ludzie z tego powinni korzystać. I nawet powiem tak, nawet ludzie nie tylko IT.

Łukasz Kałużny: I wiesz, i teraz mam koledze np., nie wiem, czy po niezapowiedzianych pentestach, które zrobiłem jego kodowi.

Szymon Warda: Teraz rozróżnijmy dwie rzeczy. Czy ludzie powinni vibe codować aplikacje, które wystawiają jako SaaS-y? No nie.

Łukasz Kałużny: No nie. To jest, podkreślamy to.

Szymon Warda: I realnie rzecz biorąc, to jest wielkie oszustwo, bo nie zrobisz czegoś, co będzie na tyle wartościowe, tylko vibe codując. On po prostu się pogubi zbyt szybko. I tu się zgodzimy.

Łukasz Kałużny: Kurde. I teraz jedna rzecz. Na GitHub Universe, aż mnie teraz natchnąłeś, żeby sprawdzić jedną rzecz. Na GitHub Universe poprzednim, kurde, było coś, z czego się śmialiśmy, aż idę sprawdzić tą platformę do publikacji, do kodowania aplikacji. I Ty wiesz co, jak teraz o tym mówisz…

Szymon Warda: Dla osobistego użytku? Świetne!

Łukasz Kałużny: Tak. I to jest w ogóle w tym, kurde, ja tak wiesz, nie miałem o tym. Teraz jak pomyślę o tym co powiedziałeś, w szczególności, że Google ten, pewnie zaraz usłyszycie o tym… O, GitHub Spark.

Szymon Warda: Tak to się nazywało, dokładnie.

Łukasz Kałużny: GitHub Spark, więc to może być super. A Firebase w ogóle też swoją drogą dostał, jeżeli dobrze kojarzę, dostał teraz AI Studio takie na bazie Firebase’a właśnie.

Szymon Warda: To właśnie też miałem powiedzieć, że brakuje takiego firmowo, po prostu platformy do hostowania tych aplikacji, żeby wiadomo było co jest grane i jak. Bo czy to będzie alternatywa takiego low code’u w firmach, że coś tam sobie business zrobi, nakoduje, itd. Jeżeli do tego byłby taki ładny Spark, ogarnięty jeszcze ładnie, żeby np. było napakowane modułami, które mogą wykorzystywać API, itd., to by mogło działać. Nie będzie z tego low code’u dla nie IT.

Łukasz Kałużny: Tak, ale wiesz teraz tak, pod tytułem IT wytworzy w tym szybko narzędzie i tak dojdzie tak jak… Inaczej, jak z nocodem, low codem bardzo szybko rozbije się do ściany i wróci do tego, że chcemy tworzyć to w tym… Prototyp - super. Ale potem i tak wrócimy do tego, że chcemy to przepisać.

Szymon Warda: Tak. Okej. Takie podsumowanie… Inaczej, wróćmy jeszcze do jednego. Czemu w kontekście organizacji nie? I to nie będzie takim ładnym okresem cały governance, moduły, wystawienie, hostowanie, itd. Ustalmy, napisanie aplikacji jako takiej to jest tylko początek. Potem zaczyna się cała masakra, żeby to faktycznie ładnie działało.

Łukasz Kałużny: Ten Firebase, jak myślę, to jest ciekawa rzecz, to może być ciekawą rzeczą, prototypy, albo narzędzia na chwilę, chociaż na chwilę są najgorsze.

Szymon Warda: One będą żyły dość długo. Dobra, osobistego użytku? Wydaje mi się, że to jest bardzo ładne wejście do nauki programowania dla ludzi, bo będzie taki moment, że będzie musiał coś powiedzieć, zobaczyć i to jest fajne wyjaśnienie, co robi kod. To też jest dobre.

Łukasz Kałużny: Wyjaśnienie, tak i w innych, wiesz, jak komuś wygeneruje potem, tak jak w Sparku tego Reacta.

Szymon Warda: Narzędzie wspomagające naukę, to jest do tego na chwilę obecną.

Łukasz Kałużny: No dobra, powiedziałbym: tu się z Tobą totalnie nie zgadzam. Raczej sądzę, że ogólnie też, a dla niektórych, którzy są na początku swojej drogi, uważam, że ich ogłupi. O tak, to jest…

Szymon Warda: Może, ale też obniży barierę “ja nie wiem co tu się dzieje”.

Łukasz Kałużny: Do wytłumaczenia tak, ja bardziej mówię generowanie, że obniża. Dobra.

Szymon Warda: Kończymy.

Łukasz Kałużny: Kończymy. Trzymajcie się, na razie.

Szymon Warda: Pa pa.