Buduj z AI - dla siebie i w firmie | Gość: Mateusz Wróbel
Słuchaj też na
Transkrypcja odcinka
Tekst wygenerowany automatycznie - może zawierać drobne błędy i literówki.
Wróć do odtwarzacza ↑Staram się sprowadzić wszystko do tego, żeby to było głupio proste. Sprowadzając się do ciągłego myślenia o każdym aspekcie, wyzbywasz się tej mocy kognitywnej. Czego potrzebuje osoba, która właśnie myśli o tym home labie? Jaki jest taki pierwszy, istotny krok? Twoim zdaniem, może pogadajmy też o jakichś błędach, które ty popełniłeś, tworząc takie, a nie inne środowisko. Jak to teraz u ciebie wygląda? To nie jest kwestia tego, że AI nas zastąpi. My robimy narzędzia, które mogą nas zastąpić i to jest bardziej kwestia tego, jaką my decyzję podejmiemy, gdzie my się widzimy w tym całym procesie. Dotykasz tego konceptu human in the loop. Czy powinniśmy jednak dążyć do tego, żeby ten człowiek się z tej pętli wycofywał?
Wiesz, jest też cała ta dyskusja o fabrykach oprogramowania. Dla ciebie to jest jeden z kierunków tego, w którym idziemy, czy to jest jedyny kierunek, w którym idziemy tak naprawdę? Jak do tego podchodzisz? Są aspekty w programowaniu, których nie chcemy robić, nigdy nie chcieliśmy robić i teraz możemy te aspekty po prostu wyrzucić całkowicie do kosza. Jak ty już się pozbędziesz tego, o czym to programowanie było, to tam już nie ma nic dla nas, nie? Wchodzi jakiś tam specjalista marketingu, wchodzi w ogóle boss. Czym tu się ogólnie zajmować w tej robocie tak na co dzień? Cześć wszystkim, witajcie serdecznie. To jest kolejny odcinek podcastu Opanuj AI. Dzisiaj kolejne spotkanie z gościem. Porozmawiamy z Mateuszem Wróblem, senior software engineer z Trivago.
Cześć Mateusz. Cześć. Mateusza możecie śledzić m.in. na LinkedInie, w mediach społecznościowych, ogólnie też w internecie, gdzie dzieli się wiedzą o tym, jak wygląda jego środowisko pracy z agentami. Można powiedzieć, że jest takim gościem, który to pojęcie AI native software engineeringu tak naprawdę rozumie od podszewki, rozumie go z wielu różnych stron. Jest też ogromnym zajawkowiczem, buduje swój home lab, zainwestował, chyba się zgadzimy Mateusz, kupę kasy w to, żeby to lokalne AI działało, żeby dało się robić rzeczy po prostu w skali, która jest gdzieś tam, można powiedzieć produkcyjna, radykalnie różna od localhosta, radykalnie różna od jakichś tam demek na własny użytek. I dzisiaj o tym porozmawiamy.
Mateusz w zawodzie jest od lat ponad już 16, zaczynał jako junior full stack z PHP, z jQuery, przechodził przez frontend, dotykał różnych języków. Myślę, że sztuczna inteligencja tam taką wielojęzyczność tylko wspomogła. Od 2023 roku zajmuje się rozwiązaniami opartymi właśnie o AI, o LLM. Buduje zarówno aplikacje, gdzie ten LLM, gdzie to AI jest w środku takiego systemu, ale też korzysta z tych technologii, żeby wspomagać swoją własną produktywność. I dzisiaj pod różnymi kątami o tym AI pogadamy. Natomiast chciałbym Cię zapytać o dzisiejszą formę nieprzypadkowo, bo jak tutaj rozpoczynaliśmy na ofie, to wspomniałeś, że całkiem intensywny dzień za Tobą. Więc pytanie, jak tam ta praca z agentami dzisiaj u Ciebie wygląda?
Ile roboty wykonali dla Ciebie agenci? Co tam pozostało po Twojej stronie dzisiaj do zrobienia? Rozmawialiśmy, że całkiem intensywny dzień za Tobą. Tak, akurat teraz mamy w ramach naszego projektu dosyć fajny eksperyment, który prowadzę obecnie sam, bo niestety kolega też jest zajęty innymi rzeczami w innych sferach. Także robimy toola, który ma analizować nam logi z różnych źródeł i na podstawie tego potem będziemy mogli zobaczyć, co się dzieje w aplikacji, co sfejlowało i dlaczego np. ktoś nas ocenia tak, a nie inaczej i co było powodem właśnie tej oceny. Czy to był błąd aplikacji front-endowej, back-endowej czy coś innego. No i tutaj jest zaprzęgnięty właśnie Cursor do tego, Cloud Agents i klepie wszystko sam.
Tutaj większość pracy z mojej strony to jest design i przypilnowanie tego, żeby relacje między modułami, też zaprojektowanie bazy danych, żeby tutaj to wszystko było spójne i miało sens, ale już nie wchodzę tak bardzo głęboko w język, jak to zostało zaimplementowane, jak to zostało wszystko przez AI skonstruowane. Robimy code review, bo musimy, tylko też nie skupiamy się na tym tak bardzo, żeby wytykać jakieś bardzo małe problemy. Tutaj liczy się prędkość, bo jest to POC, chcemy mieć dowód na to, że to wszystko będzie działać, więc ciśniemy, ale też musimy mieć to przygotowane pod tą skalę produkcyjną, już jak już zaczniemy faktycznie używać tego codziennie i będziemy dostawać po kilkaset raportów dziennie, które będą musiały zostać potem przemielone, potem scrollowane wszystkie logi z Elasticsearch, których mogą być dziesiątki per jeden request, więc tutaj nam się robią tysiące rekordów do przemielenia, zapamiętania i potem przemielenia przez AI w celu uzyskania jakiejś rzeczy.
Także praca tutaj głównie jest na tym, żeby to utrzymać w ryzach i żeby faktycznie sprawdzać, czy AI idzie dobrą drogą i czy robi to, co chcemy, żeby robił. A kod jest produkowany w bardzo dużych ilościach, także mamy już prawie tydzień, a wszystko już będzie niedługo skończone pod taki pierwszy POC. Dzisiaj jeszcze frontend leci, żeby można było sobie coś tam przyklikać, także prawdopodobnie jeszcze jeden, dwa dni i będzie cały POC skończony na danych rzeczywistych, co robiliśmy wcześniej. Wcześniej mieliśmy taki bardzo wstępny POC, który robiliśmy ręcznie, żeby sprawdzić, czy faktycznie coś AI jest w stanie zrobić i był w stanie. W sensie znaleźliśmy sobie jakiś błąd po stronie Sentry, tylko daliśmy mu linka do Sentry, puk, wszystko zrobione, w sensie Jira założona, przeanalizowane testy integracyjne do tego błędu zrobione, bo został zreprodukowany, robiąc testy integracyjne.
To są naprawione, pull request wystawione, my tylko sprawdziliśmy, ok, dziękuję, do widzenia, problem z głowy. Także od tej strony wiemy, że się da, a teraz musimy pójść w drugą stronę, od raportu, który dostajemy od kogoś z jakiejś tam innej platformy, przejść, sprawdzić wszystkie logi i dopiero wrócić się do tego naprawienia błędu. Ja też jak Cię słyszą, to widzę tutaj jakąś taką linię podziału pomiędzy właśnie Tobą, jako specjalistą, człowiekiem z doświadczeniem, senior software engineerem, a właśnie tym wirtualnym współpracownikiem, który robi rzeczy i tak do końca, nie chcesz robić takiego micromanagementu właśnie tego Twojego wirtualnego pracownika w postaci jednego czy wielu agentów. Chciałem sobie o tym pracowniku zaraz pogadać, ale specjalnie jeszcze na chwilę ten temat zostawię na boku, bo chciałem zapytać, jakim Ty w ogóle byłeś programistą i w ogóle jakiego rodzaju pasjonatem technologii przed tą epoką AI?
Jak Ty podchodziłeś do pracy, gdzie trzeba było kontrybuować do wielu różnych technologii, gdzie trzeba było się uczyć wielu różnych technologii? Bo to da nam też taki pełniejszy obraz tego, dlaczego na przykład akurat u Ciebie ta adopcja AI wydaje mi się tak wiele pozytywów tutaj daje nam w całej tej historii. Więc zanim to AI się pojawiło, zanim to AI wywróciło do góry nogami różne strony robienia rzeczy, że tak powiem, to jak Ty w ogóle do tego świata programowania podchodziłeś, co było najważniejsze dla Ciebie albo co Cię jarało tak naprawdę? Rozwiązywanie problemów, czyli dostać jakiś problem, wziąć go, rozłożyć na czynniki pierwsze i jakoś sobie z tym poradzić. I schodziło się na bardzo niskie poziomy czasami.
Także to, czego już nie chcę robić w tej chwili, czyli właśnie nie uczyć się każdej metody z osobna. Kiedyś trzeba było tak. Jeszcze rok temu właśnie, jak też robiliśmy w ramach firmy agenta do supportu, to tam jeszcze uczyłem się .NETa, czyli właśnie jak zrobić wątki, jak zrobić asynchroniczność itd. Czyli uczyłem się tych niskopoziomowych metod, żeby wiedzieć jak to działa. Wiedziałem, że to można zrobić z racji tego, że język na to pozwala. Gdzieś to mi się wszystko obijało o uszy. Także wiedziałem, co chcę osiągnąć. Musiałem się tego nauczyć. Teraz nie muszę się uczyć tych szczegółów, tylko mogę podejść do ejaja. Chcę mieć to w taki sposób zrobione. I chcę mieć dowód na to, że to zostało w ten sposób zrobione.
I to był też problem w przeszłości. Czyli chciałem być dokładny. Przez bardzo długi czas byłem perfekcjonistą, ale udało się to tak trochę wyrugać, bo było to bardzo przeszkadzające jednak przy produktowym podejściu. Nie można być tak do końca perfekcjonistą, zrobić wszystko, żeby było na cacy, trzeba czasami zostawić to coś na później. Ale do tego się wraca, czyli teraz mogę to zrobić, bo nie kosztuje to tyle czasu, co wcześniej. Także gdzieś te rzeczy ze sobą się poprzeplatały. I jedna rzecz, taka najważniejsza, która mnie najbardziej bolała w przeszłości, którą chciałem jakoś tam osiągnąć, a zawsze było ciężko, to były testy. Bo gdzieś tam zawsze próbowało się zrobić, żeby pisać te testy, żeby wprowadzić test driven development czy behavior driven development.
Żeby zacząć od tych testów, bo to pomagało. Jak gdzieś tam robiłem swoje eksperymenty w ramach prywatnych projektów, to to działało. Tylko jak już chodziło na projekty komercyjne, to się okazywało, że tutaj mamy tyle czasu, tutaj mamy tyle czasu, nie da się tego pogodzić siłą rzeczy. Chociaż niby w long termie te testy pomogą, to nie było tego long termu, bo nie pracowaliśmy na produktach. Pracowaliśmy na projektach, które miały na przykład deadline czerwiec przyszłego roku, koniec, nie możemy tego przekroczyć. Więc nie możemy powiedzieć sobie, ok, napiszemy teraz testy, no to potem będzie nam łatwiej. Nie będzie tego potem, po prostu. Miałeś jakiś taki punkt przełomowy, gdzie właściwie skumałeś czym się różnią te projekty od produktów.
Też mówisz o tym perfekcjonizmie, o tym, że musiałeś to w pewnym momencie porzucić, żeby znowu do tego wrócić z wykorzystaniem agentów. Ale to była bardziej taka stopniowa transformacja u ciebie, czy bardziej może wpływ czynników zewnętrznych? Może dołączyłeś do firmy, gdzie zaskoczyło cię to, jak się robi rzeczy, na co się stawia nacisk, czy wszystkiego po trochu? Wiesz co, w tej chwili nawet nie jestem w stanie powiedzieć. To raczej było takie progresywne, kawałek po kawałku i gdzieś z roku na rok to zanikało. Także myślę, że akurat w moim przypadku to nie było takie, ok, teraz żeby tak, albo próbuję robić tak. Tylko zawsze gdzieś był jakiś element, który wpływał na mnie, na mój rozwój i to szło tak kawałek po kawałku.
I nie wiem, czy da się tego tak nauczyć. Kiedyś jak szkoliłem juniorów, czy swoich współpracowników midów, to każdy musiał najpierw się potknąć tak naprawdę. Zobaczyć, że nie da się inaczej zrobić, trzeba do tego podejść inaczej. Także myślę, że takie nastawienie, że będzie taki okres, że nagle zmienisz swoje podejście, nie istnieje. Coś takiego nie istnieje, bo jest blokada w głowie, że chcesz robić po swojemu i nie możesz tej blokady po prostu przełamać z dnia na dzień. Tak mi się wydaje. Z mojego punktu widzenia to wygląda, że to jest proces, który może trwać w niektórych przypadkach kilka tygodni, kilka miesięcy. W moim przypadku w większości rzeczy trwa lata, także tak to widzę, że ja na przykład potrzebuję po prostu więcej czasu na wszystko i u mnie się to rozciąga.
Jest też taka hipoteza, którą teraz się rzuca na stół a propos prognozowania przyszłości mówiąca o tym, że teraz to w grze zostaną jedynie ci, którzy tak naprawdę kumają ten biznes w całym IT i zwracają uwagę o co biznesowi chodzi. Są właśnie product engineerami. Jaka była Twoja relacja z tym szeroko rozumianym biznesem? Czy to jakoś specjalnie podchodziłeś do tej relacji? Czy zdarzyło Ci się kiedyś żyć w takim trybie my kontra oni, my techniczni kontra oni, nie kumaci? Czy raczej miałeś to szczęście, że trafiałeś do firmy, gdzie tak naprawdę nie dało się aż takich barier odczuwać i robota szła w jednym kierunku? Na pewno były konflikty. W różnych projektach było, że my wiemy lepiej niż ktoś inny.
Także to wszystko zależy od sytuacji, zależy od podejścia, od tego jaki jest projekt prowadzony, kto na tym projekcie ma zyskać i czy nie wplątuje się tam jakaś polityka dodatkowa wewnątrzkorporacyjna czy firmowa, czy jeszcze jakaś w ogóle polityczna. Także tutaj ciężko na to odpowiedzieć, bo każde środowisko jest inne, a tych środowisk przechodziłem kilka. Jak myślisz sobie o tej Twojej ścieżce i o tym, co na przykład dzisiaj robisz z AI-em, to gdzie pojawia się taka myśl, że kurczę, ale byłoby ekstra gdybym ja to miał 10 lat temu w ręce albo na moim desktopie. 10 lat temu czy 5 lat temu, jakie bym rzeczy na przykład mógł robić, których wtedy nie mogłem robić. Mówiłeś o tych testach, mówiłeś o tej jakości, to przede wszystkim to?
Przede wszystkim to, a też z perspektywy czasu może inaczej wyglądałyby moje prywatne projekty, bo ja zaczynałem właśnie, jak wspomniałeś, zaczynałem od PHP i JavaScriptu. Nawet na początku ja pisałem własny framework, analizowałem Zenda, analizowałem, co tam jeszcze było w Zendzie 1C. Jakieś Cake’i i tak dalej? Był Yii, bardzo fajny framework. Także analizowałem frameworki, jak oni to robią, czytałem książki o wzorcach projektowych bandy czworga i próbowałem to wszystko jakoś tam zrobić. Był framework, był własny CMS, były jakieś gry własne przeglądarkowe, tylko to wszystko zżerało masakrycznie dużą ilość czasu. I jeśli można byłoby gdzieś uciąć część z tych rzeczy, gdzie nie muszę klikać literka po literce wszystkiego, a część rzeczy po prostu jest w głowie, jakbyś mógł po prostu z głowy wypluć wszystko w plik i od razu to przetestować, sprawdzić czy działa. To jest ta różnica z pracy z AI-em, że masz pomysł, rzucasz, dostajesz go za 5 minut, a nie spędzasz 6 czy 8 godzin klepania w klawiaturę.
Bo to jest ta różnica, że wiesz co chcesz zrobić i chcesz to zrobić. Z AI-em ta przestrzeń chcenia się zmniejsza, po prostu chcesz i masz. Tak, ta sprawczość jest błyskawiczna, co rodzi konsekwencje tak naprawdę na wielu różnych kierunkach. Tak, a w przypadku mojej osoby, gdzie ja mam milion pomysłów na sekundę, chcę coś zrobić, to bardzo pomaga. Bo nawet samo to, że mogę usiąść do komputera i pomysł, który mi nagle wpadł, po prostu przetestować i następnego dnia zwalidować czy to mi się podoba czy nie, to samo to pozwala mi uwolnić głowę. Bo w przeciwnym wypadku w przeszłości, ja bym siedział tydzień czy miesiąc na tym, żeby to wszystko zrobić i dopiero wtedy to wypada z głowy, bo okej, albo mogę nad tym pracować, albo mi się znudziło, albo coś innego.
Także w przypadku AI, to taki proces czyszczenia głowy jest bardzo fajny, czyli pozwala, przynajmniej w moim przypadku, utrzymać higienę umysłową. Także pod tym kątem też jest to bardzo fajne narzędzie. Przewijmy teraz ten timeline do czasów współczesnych. Jesteś w Trivago w firmie, która spełnia definicję takiej firmy, przynajmniej z zewnątrz, nie pracując tam, gdzieś tam bazując na tym, co się o Trivago pisze, co pracownicy, co szefów z Trivago mówi, spełnia tą definicję takiej firmy AI Native, albo przynajmniej z aspiracjami do bycia AI Native, gdzie ta sztuczna inteligencja jest, ma się ją wykorzystywać, ona ma pomagać skalować zarówno pracowników, jak i produkty, usługi, które realizujecie.
No ale oczywiście tych typów projektów jest cała masa. Gdybyśmy mieli scharakteryzować takie dwa na takim największym kontraście, takie zupełnie poce, czy nawet te pomysły, które ty masz w prywatnym backlogu i właśnie takie projekty w dużej skali, to gdzie byłyby takie kluczowe różnice, jeśli chodzi o wykorzystanie sztucznej inteligencji i cały twój workflow? Zacznijmy właśnie od tych projektów prywatnych, o których ty mówisz, gdzie czasami chcesz coś wyrzucić z głowy i zakładam, że tutaj są radykalnie różne praktyki od tego, co robisz na co dzień w Trivago, więc jak to wygląda? A może wcale nie, może to jest ten sam workflow i jak to wygląda? Właśnie jest inny troszeczkę, bo w Trivago wciąż mamy w procesie code review. Wciąż mamy, co najważniejsze, legacy code, który nie do końca spełnia wymagania.
Akurat dzisiaj poszedł merge ostatniego refaktoru, który usunął bardzo newralgiczne rzeczy, także jesteśmy już tak w 90% praktycznie na nowym codebase. I tutaj też AI powiem. Gratulacje. Tak, w piątek zeszły, chyba, tak, puściłem agenta, żeby tam poczyścił ze cztery katalogi, tylko oczywiście źle napisałem prompta i zamiast przeczyścić cztery to przeczyścił ich piętnaście, także dzisiaj poszedł pull request na ponad siedemset plików. Ale tego się spodziewaliśmy, na szczęście to były tylko poprawki w importach, ale tak. To jest ta różnica, tak, że właśnie możemy takie rzeczy zrobić i to tutaj AI się bardzo przydaje, że mieliśmy dług technologiczny i go nagle nie mamy i tutaj kładłbym nacisk na to także przy projektach, które właśnie mają jakiś ten dług technologiczny i to co robimy teraz w niektórych projektach Trivago, to żeby być przygotowanym na puszczanie agentów, żeby móc pracować z agentami, musimy spłacić ten dług technologiczny, przynajmniej w jakiejś części.
Jeśli nie, to musimy zdecydować, czy go spłacamy, czy po prostu przepisujemy rzeczy, a dług się potem odetnie i wyrzuci, bo też część tak rzeczy próbujemy robić, bo nie da się wszystkiego po prostu zrefaktorować, przepisać, czasami po prostu trzeba napisać coś od nowa, zacząć tworzyć coś równolegle od nowa. A w przypadku moich projektów, ja tutaj mam czystą kartę, ja robię wszystko od zera, każdy projekt jest przygotowany od napisania testów. Taki fajny przykład z początku tego roku, przymierzałem się do pomysłu zrobienia własnej klawiatury na Androida, która by wspierała tylko i wyłącznie mikrofon, żeby potem przerobić na aplikację po prostu w asystenta głosowego, żeby nie musieć robić różnych haków na tym, co jest w software’ze, czy też kombinować jak w moją aplikację, czy w przeglądarkę wrzucić jakiegoś asystenta.
Tylko po prostu mieć to w klawiaturze i żeby ta klawiatura obsługiwała wszystko, co chce, ewentualnie połączyć też z aplikacjami na Androidzie, bo wtedy też już można. Jeżeli robimy klawiaturę natywną na Androida, to wtedy możemy mieć dostęp do wszystkiego i sobie zarządzać całym Androidem praktycznie. To pierwsze, co zostało zrobione, to zestaw kontenerów, które miały w sobie Android Studio, tworzenie emulacji itd. Pierwsze commity to był właśnie cały ten setup razem z akcjami do Gita, żeby to też się odpalało w CI/CD, żeby te obrazy od razu szły do repozytorium kontenerów, obrazów pod kontenery, żeby potem można było to tylko pobierać w ramach workflow. I taki pierwszy funkcjonalny commit już odpalał aplikację, przeklikiwał się przez nią i testował ją end to end z customowej klawiatury zainstalowanej na Androidzie do jakiegoś mojego API, które strzelało do modelu voice to text będącego na mojej maszynie.
To jest też taka fajna intuicja, która wychodzi z doświadczenia, że te problemy i wyzwania nie są tam, gdzie początkujący myśli, że są. Jak ty masz pomysł zbudowania klawiatury, to ja to rozumiem tak, że ty wiesz, że to się da zrobić, odkładasz sobie to troszkę w czasie, ale potrzebujesz wielu rzeczy naokoło, gdzie prawdopodobnie ta kropelka potu z czoła może spłynąć. I chyba tak to w przypadku tego projektu właśnie jest, tak? Tak, dokładnie. Wszystkie projekty, które robię prywatnie zaczynają się od testów. Czyli najpierw muszę mieć przygotowane, zwalidowane to, co chcę, żeby było zrobione. I przygotowane pełne środowisko po to, żeby można było tą aplikację, serwis, cokolwiek odpalić i przetestować.
Przede wszystkim, żebym ja to mógł sobie lokalnie odpalić. Jeśli agent coś skończy, powie, że jest zrobione, pokaże mi screenshoty czy coś innego, nawet filmik, bo też można to zrobić. Okej, zrobiłeś, no to ja teraz to sobie poużywam. Sprawdzę, czy to wszystko działa, czy działa tak jak chcę. Sprawdzę od strony użytkownika końcowego. Ja już jestem wtedy użytkownikiem końcowym, bo ja to chciałem, ja to zarequestowałem i teraz będę tego używał. No i po to to jest. Nie muszę tego deployować od razu do Android Stora, mogę to zrobić później. Ale muszę mieć możliwość, żeby nawet sobie na komputerze zbudować APK, ściągnąć na telefon, zainstalować, sprawdzić, czy działa. I tak samo z całą resztą rzeczy. Po prostu jeśli buduję serwis, to on ma działać lokalnie, żebym mógł sobie go odpalić, przyklikać.
Ale czy to właśnie kompatybilność z agentami to jest taka nowa warstwa zgodności, której też oczekujesz? No bo zakładam, że jak się wprowadza np. testy jednostkowe i one działają dla Ciebie, to dla dzisiejszego agenta, takiego agenta z półki średnio wyższej też zadziałają. No ale np. ze screenshotami to wcale nie jest takie oczywiste. Albo z jakimiś tam właśnie kontenerami, albo z tym, żeby te integracje z wielu różnych klocków poskładać i testować. Więc jak rozumiem, ta przejrzystość dla agenta to też jest taka kolejna bramka dla Ciebie, tak? Już dopóki agent mi tego nie potrafi udowodnić, to też jeszcze nie jestem usatysfakcjonowany z tego środowiska testowego, tak? Znaczy środowisko testowe jest po to, żeby dać agentowi narzędzia do tego, żeby udowodnił, że robota jest zrobiona.
Bo jeśli jest środowisko testowe zrobione, to sam wynik testów może być jednym artefaktem. Ale dodatkowo, jeśli mamy już to środowisko testowe, to możemy użyć innych narzędzi do tego, żeby to środowisko testowe zostało użyte do wygenerowania innych artefaktów. Czyli właśnie np. screenshotów, czy wideo, czy czegokolwiek innego. Masz jakiś taki przykład w locie? Nie wiem, czy to możemy wymyślić, wiesz, tak z palca, tak ad hoc, że tak powiem. Ale masz jakiś taki przykład, gdzie właśnie np. jeden artefakt uruchomił jakiś taki ciekawy łańcuszek i Ty się nawet nie spodziewałeś, że to zagra tak fajnie ze sobą? Samo przeklikiwanie po aplikacjach przez AI potrafi pokazać mu, że coś jednak nie działa i to poprawić.
Albo, że czegoś brakuje, bo czegoś nie dało się kliknąć. Miał być przycisk, nie ma tego przycisku, no to trzeba to poprawić. Sporo takich rzeczy powychodziło, tylko teraz to już jest tak duża ilość różnych rzeczy, że ciężko mi będzie sobie przypomnieć. Ale większość to jest właśnie coś takiego, czyli agent próbował udowodnić, że coś działa, to nie działało, więc to zaczął poprawiać. Czasami też robię taką czystą eksplorację, czyli tu masz aplikację, sprawdź czy wszystkie ścieżki użytkownika, które powinny być, czyli jak jest totalne zero, to czy ja wszystko mogę stworzyć? Czy ja mogę zainicjować sobie wszystko, co jest potrzebne do pracy? I w takich przypadkach czasami wychodzi jakaś luka, bo ja o czymś nie pomyślałem, bo model o czymś nie pomyślał.
To nie jest problem też modelu, że model czegoś nie zrobi. Ja mogę o czymś nie pomyśleć. Przy samej dyskusji z modelami bardzo często wychodzi, że niektóre scenariusze nie zostały przeze mnie nawet przemyślane, bo nie wpadło to do głowy. I podczas takiej konwersacji potrafi dosyć sporo rzeczy wyjść, a potem przy implementacji mogą być kolejne. I to jest naturalny proces, bo dokładnie to samo powstaje przy normalnej ludzkiej pracy. Robisz coś i nagle okazuje się, że coś nie działa, coś powinno być inaczej, albo ten przycisk powinien być w innym miejscu, albo powinniśmy zrobić osobnego pejdża, bo jest za dużo rzeczy na ekranie. I tego nie widzisz, dopóki tego nie zrobisz. Różnica jest taka, że tymi łapkami to potem trzeba wyklepać i trwa to długo, a z AI trwa to jednak zdecydowanie krócej.
I ta pętla zwrotna sprawdzenia, czy to wszystko jest tak jak powinno być, jest o wiele krótsza i można o wiele więcej rzeczy zrobić. Chciałbym tutaj jeszcze nawiązać do tematu, który na całe szczęście już trochę gdzieś tam wygaszamy w tym całym światku AI, ale do tematu właśnie vibecodingu. Coraz więcej osób rozumie, że ten vibecoding i takie wesołe promptowanie to nie jest może droga do budowania produkcyjnych systemów. Ale paradoksalnie tutaj może być taki efekt, że po tej Twojej inwestycji w to środowisko testowe, w to całe instrumentarium, znowu się pojawia okazja na vibecoding w rozumieniu takiego troszkę może bardziej niechlujnego promptowania, takiego niestarannego, takiego może lżejszego, że tak powiem, że nie musisz mieć tej całej orkiestracji, tego machinarium, żeby rzeczy się działy.
Widzisz właśnie taki efekt, że jak zainwestujesz w tą infra, to same te prompty, te końcowe polecenia są właśnie tak głupio proste. Aż czy to jednak nie schodzi do takiego poziomu u Ciebie? Staram się sprowadzić wszystko do tego, żeby to było głupio proste. Właśnie z tego względu, że tempo jest tak duże, że sprowadzając się do ciągłego myślenia o każdym aspekcie, sprawiasz, że wyzbywasz się tej mocy kognitywnej, bo musisz wszystko przemyśleć. Ale Ty nie musisz tak naprawdę przemyśliwać wszystkiego, bo nie wszystko jest ważne. Z perspektywy aplikacji, produktu, czy nawet architektury. Część rzeczy nie jest, moim zdaniem, ważna na tyle, żeby poświęcać jej czas przy obecnym stanie modeli. Co na przykład nie jest właśnie tak ważne, Twoim zdaniem, przez to, że modele się rozwijają?
Nie trzeba dokładnie opisywać tego, co chcesz, żeby zostało zrobione. Tylko możesz być bardziej vague, bardziej po prostu podać ideę. Oczywiście potem możesz wejść w temat, jeśli jest coś bardziej interesującego, wyjdzie z tej konwersacji coś bardziej interesującego, to wejść w to głębiej, ale reszta już nie musi być. W sensie reszta zostanie rozpracowana w jakiś tam sposób. Potem możesz wrócić do tego w postaci artefaktu z rozmowy. Czyli i tak musi zostać przygotowany jakiś workplan, bo dla AI jakiś tam zestaw tasków, które będzie miał do zrobienia, musi powstać w ten czy inny sposób, bo nie możesz z jednego zdania po prostu puścić modelu, nawet samego siebie nie możesz puścić na napisanie aplikacji.
Więc zawsze musi być jakiś zestaw zadań do zrobienia i to jest taki moment na przerwę. Czyli skupiłeś się na rzeczach najważniejszych, przedyskutowałeś rzeczy najważniejsze, które cię interesowały. Wydaje ci się, że jest wszystko ok. Czyli na przykład nie zszedłeś na poziom designu bazy danych. Załóżmy, czyli nie projektowałeś tabel, nie projektowałeś relacji między tymi tabelami i nie projektowałeś, jak te dane w tych tabelach będą wyglądały. Ale już w ramach jakiegoś planu, który ma być zaimplementowany, dostałeś zestaw zachowań, jakie mają być zaimplementowane, kontraktów między serwisami i projekt bazy danych. No i to jest ten moment, w którym możesz spędzić czas i jakąś tam energię kognitywną na to, żeby przeanalizować to wszystko i zobaczyć, czy to ma sens.
Jeśli nie ma sensu, to wtedy dopiero zużywasz tą energię. Wcześniej mogło to nie mieć sensu, bo modele są wystarczająco teraz dobre, żeby ogarnąć takie rzeczy. Tylko też znowu trzeba określić modelom, co chcemy osiągnąć, bo ja mam wrażenie, że Opus w przeszłości szedł bardzo na skróty, czyli budował absolutne minimum i wtedy to prowadziło do bardzo dużych problemów, bo model stwierdzał, że czegoś nie zrobi teraz, bo jest to zbyt skomplikowane, zajmie to za dużo czasu. I to był argument, że to zajmie za dużo czasu. Tylko to nie jest argument dla modelu, to nie jest argument dla mnie, bo ten czas, ta estymacja, która została wykonana przez model jest kompletnie bez sensu i jest oderwana od rzeczywistości.
Także w pewnym momencie kiedyś tam przestaliśmy… Jasne, pisaliśmy w AGENTS.md, nie rób żadnych estymat. Tak, był ten efekt bardzo namacalny. Nie zakładaj, że to jest aplikacja, która ma wyjść jutro. Nie przekładaj tego na te realia poprzedniego świata, tak? Tak, nie chcemy MVP, mnie nie interesuje MVP. Ja chcę mieć zrobione dobrze. I jak przez to się przeszło, to faktycznie ten poziom, gdzie trzeba było schodzić, zniknął. Ten niski poziom, gdzie trzeba było w ramach konwersacji faktycznie pilnować wszystkiego krok po kroku, czy zostało dobrze zaprojektowane. Teraz można puścić model, poczekać na wynik, sprawdzić, co zostało zaprojektowane i dopiero wtedy ewentualnie wejść gdzieś albo nie. Można też pójść całkowicie po najniższej linii oporu, tylko do tego trzeba mieć narzędzia znowu.
Czyli dać modelowi zadanie, poczekać na wynik i dostać artefakty. I wtedy w ramach artefaktów dostajesz aplikację, która jakoś tam działa, bo agent udowodnił, że może się przeklikać, że dane są w bazie, bo jak zrobił reloada, to się odtworzyły. Więc udowodnił, że wszystko działa i wtedy możemy sprawdzić za pomocą dodatkowych artefaktów, jak wygląda architektura, jak wyglądają relacje między modułami, jak wygląda baza danych, bo możemy sobie przecież, nie musimy wchodzić do bazy danych, możemy sobie zrobić zrzutkę relacji, diagram, cokolwiek. Te narzędzia są stare jak świat. Tak że możemy zobaczyć na wynik końcowy i na przykład przez dwa dni nic nie dotykać w kodzie i dostać aplikację. I po tych dwóch dniach sprawdzamy, ok, wypadałoby zrobić refaktor, można byłoby zrobić tutaj redesign bazy danych, podzielić tabelkę na dwa albo dodać jakieś tam wiersze, coś innego.
Wchodzimy do agenta, spisujemy to wszystko, następnego dnia mamy wszystko gotowe. Refaktor zrobiony, kod poprawiony, architektura jest ok, baza jest ok. Kosztowało to nas dodatkowy dzień roboty, a cały Cognitive Load zniknął. Tak że tutaj wiadomo, jest to kwestia tego, jakie aplikacje budujemy i gdzie chcemy sobie pozwolić na to, żeby AI mógł to zrobić, a my tylko sprawdzić, czy wszystko jest ok. Spróbowali delikatnie skonkretyzować a propos tego, kiedy agent robi to, co on ma robić. Co u Ciebie się sprawdza właśnie najlepiej? Czy to są właśnie AGENTS.md jakieś zagnieżdżone? Czy to jest bazowanie też na pamięci agenta, którą sobie buduje wraz z tym, jak po prostu pracujesz w projekcie? Czy to jest też jakaś warstwa skilli, które te artefakty mają odkładać?
Bo wiesz, mówisz o tym stanie końcowym oczekiwanym, mówimy o promptach, ale myślę, że dla wielu osób to, co jest pomiędzy, to jest też jeszcze takie trochę black box, takie pudełko, gdzie nie wiadomo, co tam wrzucić troszkę. Tak, właśnie ja zauważyłem, że nie potrzeba tego dużo w środku, bo wcześniej pracowałem z Claude’em, też przez Claude CLI, Copilotem też przez CLI, teraz Claude Code i Cursor. Na projektach mamy zdefiniowane ze 4-5 subagentów, które są dedykowane do konkretnych zadań i garstka skilli. Naprawdę tych skilli nie jest bardzo dużo. W ramach projektu Trivago dla Reacta, łącznie z takimi, które są share’owane między innymi projektami, jak tam tworzenie workplanów, przygotowywanie tego wszystkiego, czy egzekucja workflowu TDD, BDD, to mamy łącznie może z 15 skilli, czy coś takiego.
Myślałem, że powiesz 3, ale to 15 to jednak jest jakaś liczba, która wymaga wysiłku. Tak, tworzyliśmy to zawsze w momencie, kiedy agent robił coś głupiego. Czyli wiemy, że chcemy mieć w Storybookach, Storybooka chcemy mieć w konkretnym miejscu, więc zaczynaliśmy od skilla, tu masz Storybooka, Storybooka używamy pod takie rzeczy i masz go odpalać wtedy i wtedy. Oczywiście też miał informację w workflow TDD, że dowodem na zmiany na UI, jeśli zmieniałeś komponent, jest screenshot albo test wizualny i odwołanie do skilla, który służy do uruchamiania Storybooka. Czyli takie bardzo generyczne opisy narzędzi, czasami specyficzne dla projektu, czyli że to mamy tu, to mamy tam. Na swoich projektach prywatnych już tego nie robię, bo staram się wszystko standaryzować, czyli każdy projekt wygląda tak samo i to samo staramy się robić w ramach projektów wspólnych trivagowych, przy których pracuję, czyli workplany są tworzone zawsze w tym samym miejscu we wszystkich projektach, czy to .NET, czy to frontend, czy to takie czy siaki.
Jakieś tam inne rzeczy też dokładnie mają spełniać tą samą strukturę. Workplany, czyli powiedzmy jakaś forma artefaktu tekstowego, gdzie po prostu rozpisujesz zadania dla agenta, tak? Tak, agent stworzy sam dla siebie. I wcześniej te plany, workplany przy modelach wcześniejszych, jakieś pół roku temu, troszeczkę wcześniej, jeszcze miały jakieś elementy szczegółu implementacyjnego, czyli jakie pliki ruszyć, jakie klasy napisać. Teraz wyzbyliśmy się tego całkowicie. Wszystkie te rzeczy są absolutnie agnostyczne. Nieważne jaki język, jaki framework, wrzucamy i to będzie działać. Bo z poziomu modeli nie interesuje nas, co on sobie planuje w ramach pracy wstępnej. On ma zaplanować, co ma zostać zrobione.
A to jak zostanie zaimplementowane, to już jest inna kwestia. Dlatego te kwestie implementacyjne całkowicie wycięliśmy ze wszystkiego, co się da i zrzucamy to po prostu na sam workflow TDD, gdzie on ma sobie sam wszystko przygotować. Nawet po prostu nie przygotować. Zaimplementować, zrobić review, zrefaktorować. Bo po co mamy sprawdzać kod, zanim jeszcze on został napisany i dowieziony. Kompletnie mija się z celem. Tutaj jest też przeogromna bariera dla programistów, którzy są nadal przywiązani do tego, jak kod wygląda. No bo agent może zrobić rzecz dobrze. To jest też taka dyskusja, którą czasami widzę a propos tego braku determinizmu. Nawet całkiem niedawno to widziałem. Takie stwierdzenia, że nie przewidzisz, co model zrobi.
Ale wiesz, ja zawsze zadaję pytanie, czy ty mówisz o wymiarze funkcjonalnym. Bo moim zdaniem w wymiarze funkcjonalnym już dzisiaj dużo możesz przewidzieć. Jeśli chodzi o taki end goal i end result. Czy o wymiarze techniczno-kodowym, że tak powiem. I tutaj faktycznie te linijki kodu będą wyglądać za każdym razem troszkę inaczej. To nie jest tak, że model z pamięci ci naklepie jakąś formułkę. Ale to są dwa niesamowicie różne wymiary tej pracy z agentem. Dzisiaj naprawdę można modelowi 10 razy wydać polecenie na poziomie wymagań funkcjonalnych. I 10 razy ta rzecz się wydarzy. Jasne, ona będzie zaimplementowana pod spodem dziesięciokrotnie inaczej, że tak powiem. Ale to już chyba nie jest ta warstwa, w której powinniśmy dużo czasu spędzać.
Przynajmniej taka jest moja intuicja. Tak i do części tych rzeczy mamy narzędzia. Czyli właśnie tak jak wspomniałem wcześniej, do architektury. Całą architekturę możemy sobie zabezpieczyć. To nie jest absolutnie żaden problem w tym momencie. Nigdy nie był problem. Tylko nie zawsze był na to czas, nie zawsze był na to pomysł. Dla projektów javascriptowych już od wielu lat korzystałem z ESLinta, który miał plugin do importów. Gdzie można było sobie pilnować jakie importy, gdzie, skąd. Coś, czym jest połączone. Tak, dokładnie. I też w ogóle jak mają się one nazywać. Jakie mają mieć entry pointy. I tak dalej, i tak dalej. Także można było sobie zdefiniować, że jak masz mieć moduł, to ma mieć on tylko i wyłącznie index.ts, .js jako entry point.
I tylko w nim mogą być rzeczy, które są publiczne. Cała reszta nie może być nawet importowana przez inne pliki. Prosta rzecz. Tylko trzeba o tym wiedzieć, że coś takiego można zrobić. Trzeba wiedzieć, że są do tego narzędzia. A jak nie ma narzędzi, to po prostu sobie je napisać w tej chwili. Wygenerować. Tak jak ja właśnie tworzę w tej chwili ArchSpec, czyli narzędzie do tego, aby pilnować architektury. Dla różnych języków. Żeby właśnie nie musieć pamiętać, tu mam takie narzędzie, tu mam takie narzędzie, tutaj ono działa tak, tutaj działa tak. Wiem, co chcę osiągnąć. Nie obchodzi mnie, jaki tam język jest pod spodem. Architektura ma być konkretna. I ma być sprawdzalna. Mam mieć możliwość wygenerowania grafu na podstawie tego, co jest w kodzie.
Nie to, co model mi wypluje. Nie to, co ja sobie w jakimś tam YAML-u wyklepię. Ja muszę mieć możliwość porównania mojej definicji YAML-owej z tym, co jest w kodzie. Jeśli to się wszystko zgadza, to bajka. Czy to jest jakiś projekt, który można już gdzieś podejrzeć? Rozwijasz go open source’owo, czy na razie jeszcze forma zamknięta? Tak, akurat ArchSpec jest dostępny na moim GitHubie. Na obecną chwilę obsługuje Rusta, .NET-a i C#-a i Go. Planuję też dodać Reacta, ale React ma bardzo fajnego Dependency Cruisera. Także zastąpienie Dependency Cruisera będzie troszeczkę ciężkie. Ale taki jest cel, żeby to też zastąpić. My też w 10xDevs dużą wagę na to stawiamy, że nie wszystko musisz robić AI-em. Nie wszystko kończy się na tym braku determinizmu.
Bo jest cała masa narzędzi deterministycznych w tym klasycznym ekosystemie programistycznym, które można po prostu pożenić z agentami. I tutaj jest ten największy win. To zwycięstwo z tych obu światów, gdzie z jednej strony masz coś przewidywalnego, z drugiej strony masz tą elastyczność agenta. W takich warunkach rzeczy się dzieją. Zakładam, że u Ciebie to też jest takie czerpanie z dwóch źródeł. Tak, determinizm to jest podstawa w przypadku budowania aplikacji. Musisz wiedzieć, że to działa. Musisz mieć udowodnione, że to działa. Zawsze tak było. Tylko w większości projektów używaliśmy do tego testerów. Co trochę mija się z celem. Jeśli produkujesz software zgodnie ze sztuką, czyli piszesz te testy, załóżmy, że używasz TDD, BDD, czyli masz testy integracyjne, testy end-to-end, pisane przez deweloperów, to tester jako rola nie powinien istnieć.
Bo on dubluje całą pracę, którą wykonał deweloper. Powinien istnieć quality assurance. Czyli człowiek od jakości. Nie pamiętam, jak to się na polski tłumaczy jako rolę. To jest jakiś specjalista od jakości. Specjalista jakości, tak. Czyli ten specjalista jakości powinien wejść na aplikację i on nie powinien sprawdzać, czy przycisk działa. Czyli klikacz, taki klasyczny klikacz. On nie powinien sprawdzać, czy coś się zapisało do bazy, czy może przejść jakiś workflow. On powinien sprawdzić, czy od strony użytkownika ten cały flow użytkownika jest poprawnie zaimplementowany. Czy są jakieś rzeczy, które można byłoby poprawić, żeby sprawić, żeby ta aplikacja działała lepiej. Albo, że coś działa wolno, bo na przykład nie przetestowaliśmy tego w dużej skali i zaczynamy zauważać, że na przeglądarce, która ma bardzo dużo pluginów, strona zaczyna lagować.
No i pytanie, czy chcemy to obsługiwać, czy nie. Ale to jest rola właśnie takiej osoby od jakości, żeby zobaczyć, czy my zrobiliśmy dobrą aplikację, a nie, czy zrobiliśmy działającą aplikację. Jako deweloperzy zawsze powinniśmy dostarczyć działającą aplikację. Z definicji jesteśmy deweloperami. Jak deweloper buduje dom, to ten dom ma stać i ma mieć okna, ma mieć drzwi, ma wszystko działać poprawnie. A to, czy tam jest jakaś dziurka, czy coś jest niedopracowane, no to jest już kwestia jakości, jak to zostało zrobione. I tutaj powinna być ta różnica. Tutaj powinniśmy postawić tę granicę, że nawet jeśli robimy coś z agentami, to agent powinien dostarczyć coś działającego. Nie musi to być nie wiadomo o jakiej jakości, bo tę jakość zawsze możemy poprawić.
Ale musi być to udowodnione, działające i sprawne po prostu. Dotykasz tego konceptu słynnego human in the loop. Zastanawiam się, czy masz jakąś mocną opinię a propos tego, jaki jest taki oczekiwany zysk produktywności dopóki człowiek jest w tej pętli i czy powinniśmy jednak dążyć do tego, żeby ten człowiek się z tej pętli wycofywał. Jest też cała ta dyskusja o fabrykach oprogramowania, gdzie rzeczy się mają dziać. Czy dla ciebie to jest jeden z kierunków tego, w którym idziemy, czy to jest jedyny kierunek, w którym idziemy tak naprawdę? Jak do tego podchodzisz? Ja sam buduję sobie narzędzie, które ma mnie odciążyć. To jest raczej odpowiedź na to pytanie. Ja chcę się przerzucić część z tych rzeczy, które mnie nie interesują na AI.
Chcę otrzymywać efekty i ewentualnie zgłębiać się w rzeczach, które mnie interesują albo które sprawią, że ja mogę faktycznie nad tym przysiąść i pomyśleć, nauczyć się czegoś. Zwykłe to, co zawsze żeśmy walczyli od strony front-endowej, od czasów jQuery, implementacja na wielu przeglądarkach, implementacja na czymś tam, to nie są wyzwania, które jako deweloperzy powinniśmy zająć. z którymi powinniśmy walczyć. To nie jest tak naprawdę coś na czym powinieneś spędzać czas. Ok, z mnożenia kalkulatora, tak? Jakby inżynier, który zajmuje się projektowaniem mostów, no jakby to nie jest jego robota, żeby jedno przez drugie przemnożyć, nie? Dokładnie. Także są aspekty w programowaniu, których nie chcemy robić, nigdy nie chcieliśmy robić i które nas zawsze wkurzały. I teraz możemy te aspekty po prostu wyrzucić całkowicie do kosza.
No ale wiesz, bo tutaj też lekko tak zagram taką lekko podkręconą, myślę, że też są takie gdzieś tam sentymenty w niektórych rejonach branży, że jak ty już się pozbędziesz tego o czym to programowanie było, to tam już nie ma nic dla nas, nie? Tam wiesz, wchodzi PM, wchodzi jakiś tam specjalista marketingu, wchodzi w ogóle boss, bo zawsze ma setki tysięcy pomysłów. No to kurczę, nie? Czym to się ogólnie zajmować w tej robocie na co dzień? Nie wiem. To jest pytanie, na którym będziemy spędzać pewnie jeszcze czas przez następne parę lat. Ciężko określić, w którym kierunku to pójdzie. Wygląda na to, że jest jakaś szansa na to, że większość programowania, jaką rozumiemy jako programowanie, nam zniknie.
W którą stronę to dokładnie pójdzie? Czy faktycznie modele, czy systemy agentowe będą na tyle sprawne, żebym ja mógł, tak jak przed chwilą sobie rozmawialiśmy, puścić prompta, dostać aplikację i ta aplikacja będzie idealna. W sensie, nie będziesz musiał, tak jak teraz sobie rozmawiamy, że musimy sprawdzić artefakty, musimy coś tam zobaczyć od strony jakości itd. Jest całkiem możliwe, że sporo z tych rzeczy będzie rozwiązywalna na poziomie modeli. Na poziomie, może nie tyle modeli, co na poziomie całych systemów agentowych. Tylko tutaj jest kwestia skali i jak będą się rozwijały, w jaką stronę kosztową będzie to szło? Jakie będą to koszta na dłuższej przestrzeni? Bo wciąż tego nie wiemy, tak naprawdę.
Jesteśmy na początku. Ile to trwa? Trzy lata? To nie jest okres, na podstawie którego możemy wieszczyć, co będzie za rok, za dwa, za trzy lata. Dlatego wszystko, o czym tutaj rozmawiamy, za pół roku może być kompletnie nieaktualne. Ale widzę ten trend, że faktycznie, jeśli byśmy chcieli pójść od… Może też rozgraniczmy część rzeczy. Mamy aplikacje, mamy produkty, a mamy też systemy korporacyjne typu bankowość, typu obsługa państwa, czyli załóżmy e-urząd, czy tam KSeFy, nie KSeFy, inne rzeczy. Aplikacje krytyczne. Aplikacje krytyczne, dokładnie. Tam może to trwać dłużej. Tam może to w ogóle nie być bezobsługowe. Nigdy. W sensie ustawiamy sobie granice, że systemy krytyczne muszą być za bramką ludzką. I może to być nasze wymaganie, że tam chcemy mieć tą jakość, gdzie faktycznie nie będziemy mieli, tak jak teraz mamy, 100 ludzi, będziemy mieli tych ludzi 20, ale oni będą na straży tego, żeby to miało jakąś odpowiednią jakość.
I znowu, ja mówię jakość, bo nie wiadomo co będzie. Czy faktycznie ci ludzie będą musieli sprawdzać kod, sprawdzać architekturę, budować to wszystko, budować całą infrastrukturę dla samego software’u, czy po prostu będą to ludzie, którzy będą sprawdzać wyniki i testować, czy to wszystko działa na środowiskach testowych, a potem tylko kliknąć deploy na produkcję. Czyli jakiś taki nawet zespół można powiedzieć pentesterów, którzy wyposażeni w sztuczną inteligencję robią taki ciągły refinement tych aplikacji, które tam w tych fabrykach powstają, ale ten kierunek tego refinementu to jeszcze człowiek nada przez jakiś czas, tak? Może tak być. A może być tak, że faktycznie zobaczymy, że jest pewna ściana i nie jesteśmy w stanie jej przeskoczyć przez dłuższy czas i faktycznie będziemy musieli siedzieć i będziemy siedzieć w tych diagramach i analizować różne rzeczy i jak będzie trzeba to zejść niżej do kodu i siedzieć w tym kodzie.
Dwa scenariusze, oba realne, ale na pewno nie widzę tutaj scenariusza, gdzie klepiemy linijka po linijce, literka po literce całe aplikacje. To raczej się skończyło i do tego nie wrócimy. Ten świat się już prawdopodobnie skończył, tak? Tak, bo właśnie nie wiem co by musiało się stać, abyśmy wrócili do tego, bo nawet odcięcie, nawet gdyby w tej chwili Anthropic OpenAI padły jako firmy i nie dostarczały usług, to już w tej chwili jest na tyle duża infrastruktura wokół AI, że zawsze ta luka się już wypełni i będziemy mieli dostęp do jakichś modeli, a teraz te jakieś modele, które są dostępne, są wystarczająco dobre, aby spełniać swoją rolę przy produkcji software’u. Tak, to jest w ogóle świetny pomost do tematu, na którym moglibyśmy spędzić jeszcze dłuższe godziny niż ta nasza dzisiejsza rozmowa, czyli do tematu właśnie i modeli lokalnych i twojego home laba, który budujesz, żeby w pewnym sensie uniezależnić się od infrastruktury.
Może nie wchodzimy w liczby, może nie wchodzimy w tabelki w Excela, tak dzisiaj na start, bo możemy sobie zrobić follow up, ale pogadajmy jeszcze tak koncepcyjnie o tym, dlaczego ty inwestujesz wcale niemałe pieniądze w to, żeby jednak uniezależniać się od tego, jak dzisiaj wygląda model subskrypcyjny tej czy innej firmy, jak wygląda pricing page tej czy innej firmy i co ci to daje. Właśnie LinkedIn Mateusza, który jest właśnie aktualizowany na bieżąco, dzieli się tym, jak wygląda właśnie twój home lab, jak go rozbudowujesz, co tam się pojawia, co znika, ale na takim najważniejszym strategicznym poziomie, czemu ty wkładasz kasę w ten hardware, który gdzieś tam wokół ciebie jest, który ci ten dom podgrzewa, który generuje te rachunki za prąd, jak przecież wiąże się tutaj podobno pod subskrypcję OpenAI i robota idzie do przodu.
Tak. Takim punktem zwrotnym było przejście Copilota na model pay-per-token i już wtedy wcześniej miałem już jakiś sprzęt, żeby sobie puścić jakiś mały lokalny model, żeby móc coś zrobić, żeby się uczyć, żeby poznać, jak to działa. Czyste zainteresowanie, czyste hobby. A od tamtego momentu stwierdziłem ok, to to nie jest stabilne, nie podoba mi się, jak to działa. Dodatkowo w tamtym momencie też Anthropic zaczął robić różne dziwne rzeczy wokół Claude’a, czyli coś ogłosili, potem to odwołali, potem znowu coś ogłosili, potem znowu to odwołali. Sam software z ich strony działał niestabilnie. Te same prompty, te same modele i jednego dnia działało to dobrze, a drugiego dnia działało to tak, że chciało się rzucić czymś w monitor.
Było to strasznie niestabilne. W tej chwili dokładnie to samo widzę po stronie Cursor. Strasznie niestabilne zachowanie agentów chmurowych. Domyślam się, że jest to spowodowane ilością zmian, ale nie jest to odpowiednio, mam wrażenie, dawkowane, żeby to zrobić dobrze, żeby to działało odpowiednio. Mam wrażenie, że oni sami tego nie używali czasami i jest to bardzo frustrujące. W jakim takim aspekcie teraz właśnie myślisz, który jest trochę kamieniem w bucie, gdzie nie ma tej dbałości o detale? Dbałości o detale? Czyli taka prozaiczna rzecz, chcę puścić sobie subagenta na konkretnym modelu, który jest w całym zestawie i nagle się okazuje, że ten model nie jest dostępny. Takie proste rzeczy, które działały przez bardzo długi czas i nagle na jednym projekcie Cloud Agents zamiast robić klona na najnowszym mainie jest jeden albo dwa komity wstecz i implementuje coś co zostało już zamontowane, zmergeowane, bo musi zrobić następną rzecz na podstawie tego, co już było zrobione.
I nagle okazuje się, że zmarnowałeś mnóstwo czasu, mnóstwo tokenów, tylko dlatego, że agent źle się zespawnował. Problem został rozwiązany przeze mnie w ten sposób, że do komentarza w Jirze pisze zsynchronizuj się z mainem najpierw. I to działa. Nie jest to na tyle niestabilne, że zawsze to nie działa, tylko raz działa, raz nie działa. I to już się wystarczy do tego, żeby jakiś tam alarm się wzbudził, że tak powiem. Jakiś taki sygnał, a co gdyby to było jeszcze w większej skali problematyczne. Tak, albo prosta sprawa z routingiem, czyli puszczamy sobie agenta cloudowego z Jiry, podajemy mu domyślne repozytorium, on to domyślne repozytorium powinien sobie sam pobrać, a nagle się okazuje, że pod spodem jest routing na podstawie modelu i ten model dobiera sobie na podstawie treści zadania, jakie repozytorium ma użyć. I nawet jak ma dobrze podane repozytorium, wybierze sobie inne repozytorium z jakiegoś powodu.
Gdzie to jest bardzo prosta rzecz. Wiem jakie repozytoria są, mamy konkretny string, pracujmy na tym, a nie klasyfikujmy to, bo to jest kompletnie bez sensu. Tak ja mam wrażenie, że tak to działa pod spodem. Tutaj pozwolę, że cię przerwę, jeszcze jedna taka anegdotka właśnie z naszego ostatniego spotkania 10xDevs właśnie z Piotrem Migdałem, on opowiada, że testował sobie Qwena, wtedy jeszcze chyba 3.6 lokalnie, na benchmarku MMLU. I pierwszy miał ogromne szczęście, bo udało mu się odtworzyć praktycznie do jednego miejsca, do dwóch miejsc po przecinku ten sam wynik w MMLU, co firma, która za Qwenem stoi. Więc okazało się, że on ma ten model, który realnie w tym press release był omawiany, ale raz jeszcze tego MMLU sobie puścił na tym samym Qwenie u prowajdera chmurowego i wyniki były zupełnie różne.
Tak jakby model był tak samo nazwany, ale pod spodem to nie był ten model. Nie wiem czy kwantyzacja, on sam nie wie co było tego powodem, ale mówi, że tak naprawdę różnica pomiędzy prowajderami, pomiędzy tym, co Ci hosting daje, nawet jak ten sam model jest gdzieś tam w etykiecie, to jest kosmos. To jest coś, czego wielu ludzi w ogóle sobie nie kalkuluje przy precyzji. To jest problem np. OpenRoutera. Właśnie jak rozmawialiśmy ostatnio, ktoś tam wspomniał dlaczego nie OpenRouter, dlaczego nie używam OpenRoutera, dlaczego używam lokalnych modelów. Właśnie z tego powodu, że na OpenRouterze musisz przejść przez każdego prowajdera, sprawdzić co on serwuje, w jakiej kwantyzacji, czy chcesz tego modelu używać, czy nie chcesz tego modelu używać.
Dodatkowo, czy dany prowajder ma retencję danych, czy nie ma retencji danych. Także automatycznie sprawdza się to do tego, że niby używasz narzędzia, które powinno Cię odciążyć, ale dodaje Ci roboty i jeszcze za to płacisz. Więc ja spędziłem weekend, wygenerowałem sobie własny gateway, który leci do Ollamy, leci do OpenCode’a i leci do DeepSeeka. I ja wiem, co używam. To nie jest problem, żeby to zrobić. Kolejne dni failovery, żeby na przykład sobie, jak mój lokalny model padnie, to żeby używał tego samego modelu z OpenCode’a. Bo akurat używamy tego samego modelu, podobna kwantyzacja, bo widzę, że jakość jest bardzo podobna, nie widzę różnicy za bardzo, więc mogę sobie zrobić ten failover. Także moje padnie, to tam działa.
Jak tam używam sobie DeepSeeka Flasha i załóżmy, że był taki okres, że był peak-off-peak, to mogłem sobie wybrać, że OpenCode nie ma off-peaka w ogóle, a Ollama miała. Czyli najpierw mogłem sobie z Ollamy skorzystać, jak się skończył, jak wchodziło w okres off-peaku, czyli droższy, to się automatycznie przerzucał na OpenCode’a. Także własny software, naprawdę niedużo czasu to kosztowało, niedużo pieniędzy, jeśliby to nawet przemnożyć na zużyte tokeny, a mamy absolutną wolność, a i tak musielibyśmy to zrobić. No to dobra, no to znam te wszystkie bolączki tych prowiderów chmurowych, o których teraz pogadaliśmy, no to wchodzę sobie tam na Amazona czy na jakieś inne Allegro, nakupuję sobie tych RTX-ów i te Qweny u mnie lecą.
RTX-ów już nie kupisz. RTX-ów już nie kupię, dobra, no to urealnijmy teraz cały ten plan, pogadajmy teraz o tym, jak to w rzeczywistości wygląda, może pogadajmy o tym, co tam u Ciebie śmiga. Przy czym właśnie nie trzymajmy się aż tak bardzo cyferek i tam, wiesz, nazw modeli, oczywiście tam, gdzie jest istotne, to o tym gadajmy, ale bardziej tak koncepcyjnie, czego potrzebuje osoba, która właśnie myśli o tym homelabie, jaki jest taki pierwszy istotny krok, Twoim zdaniem, może pogadajmy też o jakichś błędach, które Ty popełniłeś, tworząc takie, a nie inne środowisko, jak to teraz u Ciebie wygląda? Znaczy, o cyferkach musiałem mówić, bo ich nie ma dużo, w sensie jeśli mówimy o modelach kart graficznych, bo tak jak mówisz, mamy RTX-y, za bardzo dużo wyboru nie ma, albo bierzemy 3090 stary, który w przeciągu ostatnich miesięcy podrożał dosyć znacznie, mamy 24 giga RAM-u i wystarczająco, żeby puścić sobie właśnie Qwen-3-8-72B.
Jest to model, który jest w stanie zrobić naprawdę bardzo dużo, w całkiem przyzwoitej prędkości, więc jak mamy jakiś jeden projekcik, to na takiej jednej karcie graficznej jesteśmy w stanie sobie coś tam podziałać, albo jak musimy się wesprzeć, to jest to model wystarczający i takie GPU spokojnie wystarcza. Mam Strix Halo, czyli GMKtec EVO-X2, coś takiego, to jest 128 giga RAM-u z unifikowaniem pamięci, jeszcze kupowałem, jak było tanio, teraz nie wiem, czy bym polecał, bo ceny są straszne. Wszystko zależy od tego, co chcemy robić i do czego używać. Jeśli mówimy o programowaniu, to w tej chwili nie wiem, czy bym polecał, bo jedyny sensowny model, który możemy na tym puścić, to jest właśnie Qwen-3-8 Flash.
Będziemy mieli wystarczająco pamięci na to, żeby prowadzić jedną konwersację naraz, 40 tokenów na sekundę, więc to jest całkiem spoko prędkość. I to jest model, który ogarnia dużo i ma też Vision, więc możemy sobie spokojnie zrobić pełen workflow z testami wizualnymi, żeby model mógł sobie zrobić screenshota, sprawdzić tego screenshota, co na nim jest i zrobić poprawki, jeśli są potrzebne. Jakaś taka jednowątkowa minifabryka, można powiedzieć, tak? Tak, dokładnie i nic więcej od tej już nie puścimy, nawet żadnego dodatkowego modelu na to nie wniesiemy, bo po prostu Qwen-3-8 Flash jest duży. Potrzebujemy te 128 giga RAMu. Co dalej? Także jeśli ktoś myśli, że Spark od NVIDIA będzie lepszy w tej kwestii, to nie, nie będzie lepszy.
One są porównywalne w prędkości. Wiadomo, część rzeczy może być lepiej zoptymalizowana pod Sparka, z tego względu, że to jest NVIDIA, ale wciąż przepustowość pamięci jest praktycznie ta sama, oba mają po 240-260 GB na sekundę, więc tutaj jest limit. Może też zrobię krok wstecz. Jeśli mówimy o właściwościach modeli i chcemy jakoś dobrać model i hardware, to musimy wiedzieć, że mamy na ten moment dwa rodzaje, czyli modele mixture of experts, które ładują tylko część ekspertów do obliczeń, żeby przemielić token i potem go wygenerować, i mamy dense modele, czyli właśnie 27B jest dense modelem, czyli token musi przejść przez wszystkie warstwy, jakie tam są. Dlatego te modele są cięższe w obsłudze.
I na przykład tam, gdzie mamy słaby compute, czyli małą moc obliczeniowej, małą przepustowość, to te gęste modele będą zawsze wolne i tam nie możemy nic zrobić, aby to przyspieszyć, nie możemy zrobić żadnych sztuczek, po prostu będzie zawsze wolno. Także jeśli mówimy o hardware ze zunifikowaną pamięcią, czyli Maki, Strix Halo i Spark, to jeśli chcemy programować, to mówimy tylko i wyłącznie o modelach mixture of experts, czyli stary Qwen 3.6 35B. albo właśnie ten nowy 3.8 Flash, to są właśnie mixture of experts, możemy jeszcze oczywiście pójść w GM4, też ponoć jest całkiem spoko i sobie radzi z niektórymi zadaniami. I pod to musielibyśmy mierzyć, czyli jeśli chcemy używać modelu gęstego, to raczej GPU, a nie zunifikowana pamięć.
Czyli jeśli chcemy używać Qwen 3.8 27B, no to musimy mieć GPU. Jeśli GPU, to albo RTX 24 giga RAM-u, można zejść niżej, schodzimy wtedy z kwantyzacją i tracimy troszeczkę na jakości. Alternatywą jest AMD, ma kilka kart 24-gigowych, które są całkiem spoko, i ma jedną kartę 32-gigową, którą akurat ja kupiłem. Nie są one tak samo szybkie jak RTX-y, bo mówimy tutaj o różnicy prędkości typu 640 GB przepustowości pamięci w przypadku Radeon AI PRO R9700 do np. starego RTX-a 3090, który przepustowość ma na poziomie 1 TB, także prawie dwukrotność. Czyli jeśli chcemy model gęstego, z dobrą prędkością, to raczej RTX, ale AMD też będzie spoko. Będzie działać wolniej, ale będzie działać. I będzie działać szybciej niż na 128-gigowym Sparku, Strix Halo czy Macu.
A propos Sparka, nie wiem czy widziałeś, szybka dygresja, tutaj wyszaruję ekran, skleimy sobie to w montażu. Za co Nvidia dostała po tyłku, że tak powiem. Dosłownie 4 dni temu pojawiła się informacja o tym, że wypuszczają Sparka 64-gigowego, żeby dać deweloperom jeszcze więcej szans na budowanie i skalę. Turbo krytyka gdzieś tam się na nich wylała, ludzie piszą, że nie dość, że wolno to jeszcze mało, bo już tych 128-gigowych konfiguracji nie są w stanie oferować. Ale ten trend tych braków sprzętowych jest niesamowity, czy ta obserwacja dotycząca braków sprzętowych. My też z Marcinem rozmawialiśmy o tym, Maki Studio, mamy tam jakieś szalone delivery daty na koniec tego roku albo na początek przyszłego, zobaczymy co się stanie.
No tutaj widać, ja myślałem, że będzie DGX-2, nie, to jest DGX-1 z biedniejszą konfiguracją, niesamowite. Jeśli ktoś chce, to trzeba atakować teraz, nie wiadomo oczywiście co się stanie za 2-3 lata, może to wszystko polecieć na szyję i te ceny mogą spaść drastycznie. Takie głupie przykłady teraz. W czerwcu przymierzałem się do zakupu tego peceta, jakiegoś peceta, po prostu myślałem o czymś, żeby zbudować sobie tego Homelab’a na jakimś mocniejszym GPU. No to wtedy takim naprawdę bardzo fajnym rozwiązaniem był RTX 6000 Pro, 96 GB RAM-u, bardzo fajna przepustowość, kosztował 40-45 tysięcy. Jak już zdecydowałem, że go kupię w weekend, przemyślałem sobie, tak, pójdę w to, w razie czego kupię sobie drugiego kiedyś, będę miał na dwa, bo nie będę musiał kupować nic więcej, tak, kupię tylko kartę graficzną, nie muszę nic zmieniać w swoim sprzęcie.
W poniedziałek wsiadam do kompa, 60 tysięcy. No ja mam teraz 69 mam przed sobą, 69, 83 koła, 71, 73. No to powiem Ci, 60 tysięcy to najniższą ofertę jaką mam to jest 69 teraz, latają po 70+, do 94 jak widzę na jednym sklepie nawet. Tak, ceny są kosmiczne. Ja myślałem, że DGX za 12 koła to jest drogo, nie, i też go nie kupiłem, a myślę, że za 12 koła to bym sobie teraz miał zabawkę w domu, nie. No właśnie ja tego swojego Strix Halo kupiłem w grudniu zeszłego roku, tak z rzutem na taśmę, stwierdziłem, kupię, będę robił rzeczy, kupię, to wykorzystam. Zapłaciłem wtedy 10 tysięcy złotych, teraz ile kosztuje, 16, jakbym sprzedawał dużo złotego to bym jeszcze zarobił. Tak, tak, tak. Ale tak, wracając do tych przykładów, no to w czerwiec, lipiec kupowałem sprzęt, to R9700 kupowałem jeszcze po 6400, teraz już są po 9.
Tak, tak to wygląda. Matematyka, jeśli chodzi o liczenie kosztów, czy budować sobie lokalne studio jakieś, lokalny serwer, czy używać API, to wszystko zależy od tego co robimy i w jakiej skali robimy. Ale to też chyba dobrze, nie wiem czy Cię dobrze rozumiem, właśnie po tej ostatniej rozmowie, w pewnym sensie Ty też stawiasz taki bet na to co się stanie w przyszłości, nie? Że to jest po prostu Twoja forma gdzieś tam postawienia żetonów, tego uzależnienia się od tych rynkowych zmian i troszkę mówisz, jakby zobaczmy co się stanie, ale Ty masz ten setup już zabezpieczony, tak? Ja to tak czytam troszkę. Sprzęt już mam, on w tej chwili drożeje, także gdybym musiał go sprzedać to nie straciłem nic.
RAM-ów, jakbyś chciał teraz kupić moje RAM-y, to nie kupisz, nie wiem czy tam, jak posprawdzasz po sklepach to może kupisz ze dwie, trzy sztuki po 27 tysięcy za 128 giga. Ja płaciłem chyba 21, także powodzenia. Budowanie teraz maszyny na serwerowych komponentach, nie takich domowych wysokiej jakości, tylko serwerowych już jest praktycznie niemożliwe, bo serwerowy RAM praktycznie nie istnieje. A jeszcze kupić do tego płytę główną kupiłem bez problemu, ale teraz tą płytę główną trzeba obsłużyć właśnie RAM-em. Jak nie masz RAM-u to nie masz płyty głównej, po co ci płyta główna jak nie masz czym obsłużyć. A procesory Threadrippery obsługują tylko i wyłącznie RAM serwerowy, nie możesz sobie wrzucić byle jakichś DDR5 i liczyć, że to zadziała.
To przeciwko czemu ty te twoje żetony stawiasz? Przeciwko dostępności i subskrypcji w cenach, które są opłacalne? Przeciwko temu, to jest jedna rzecz, a druga to jeden jeszcze aspekt, o którym wspomniałem wcześniej, no to Claude i Copilot, czyli te limity pięciogodzinne, tygodniowe, to mnie strasznie denerwowało, strasznie mnie to ograniczało, bo ja byłem w stanie przepalić w dwie godziny limit pięciogodzinny, robiąc kilka projektów jednocześnie. Teraz po prostu puszczam i się nie przejmuję. Zrobi się w dzień, zrobi się w dwa dni, ale się zrobi. I nie będę się patrzył na to, czy agent przerwał tylko dlatego, że nagle limit się wyczerpał. I też buduj potem software dookoła tego, żeby ten agent wstał ponownie z tego punktu, na którym skończył i dokończył robotę.
Bo to też jest problem. Mamy historię ludzi, którzy mają po trzy, cztery subskrypcje Copilota, już nie Copilota, czyli Claude’a, to teraz musi mieć jeszcze dodatkowy software do tego, żeby rotował Ci klucze, żeby rotował Ci wszystko, jeszcze do tego, żeby faktycznie to wszystko działało. Tylko znowu musimy pamiętać o tym, że jak mamy rotację kluczy, to przerzucamy sobie kontekst z sesji na sesję i znowu płacimy za cold start, czyli mieliśmy na jednym kluczu 500 tokenów w cache’u i nagle 500 tysięcy tokenów w cache’u, a teraz będziemy za te 500 tysięcy tokenów płacić, no bo leci to na nowy klucz. Także to też nie jest do końca dobre rozwiązanie. Jeśli oczywiście używasz do tego do zarabiania i zarabia Ci to pieniądze, no to raczej jest to no brainer. Ale jeśli jesteś programistą, który chce zrobić sobie coś po godzinach, poeksperymentować, to dla mnie jest to deal breaker. Tak się nie da pracować po prostu.
Zwłaszcza jeśli masz czas po godzinach pracy i masz te 4 godziny, no bo kiedyś trzeba spać też, więc jeszcze mieć życie. Mówiłeś o tych sesjach właśnie 24-godzinnych, 48-godzinnych, o tym, że agent sobie może pracować dobę lub dwie. Jak to właśnie wygląda w przypadku tych modeli lokalnych? No bo tutaj nie mówimy wyłącznie o tym, powiedzmy, czy jakaś tam wentla agentowa działa, ale w zasadzie co wcale. Czy modele odkładają sobie jakieś artefakty, czy potrafią kompaktować kontekst, spawnować sobie tych subagentów? Jakiego poziomu złożoności workflow ty możesz teraz utrzymać na tym swoim lokalnym setupie? Pełen workflow ostatnio ponad 70 godzin od jednego prompta do końca. Slash goal czy po prostu lista zadań?
Lista zadań, wszystko przygotowane. Czyli przygotowujemy workplan na ileś tam zachowań, potem jest to dekomponowane na zestaw subzadań, więc on potem robi jedno zadanie, potem drugie zadanie, trzecie zadanie, czwarte zadanie. Czasami robi dwa, trzy, cztery na raz, odpala sobie kilka subagentów jednocześnie. Claude Code sobie bardzo świetnie z tym radzi. Trzeba odpowiednio sobie zrobić główny wątek jako orkiestratora, żeby on faktycznie działał jako orkiestrator i wtedy może działać w ramach jednej sesji przez bardzo długi czas, bez żadnego problemu. Wtedy też część GPU, są momenty na GPU, gdzie nic się nie dzieje, bo lecą testy. Możemy mieć taki moment, że mamy odpalonych 4 czy 5 subagentów, a GPU jest chłodne, no bo wszyscy odpalili testy i nagle się okazuje, że zaczyna RAM-u brakować, CPU zaczyna brakować, bo lecą testy na iluś tam agentach.
To jest taki przypadek, który pewnie Adam Gospodarczyk może opowiadać w ramach swoich agentów. Ostatnio wrzucał wiadomość, że brakuje mu hardware’u, a nie agentów. Także podejrzewam, że to są problemy tego typu, czyli puszczamy testy i na testy potrzeba dosyć sporo siły obliczeniowej, niestety. I na podstawie środowisk wszystkich. Tak, ja się ostatnio spotkałem z tym, jak trzeba sobie ważyć to wykorzystanie software’u i hardware’u, kiedy chciałem jakiś tutaj nasz framework do benchmarkowania na GitHub Actions akurat zapuścić i też właśnie poczułem, jak bardzo ten model rozliczeń z workerami chmurowym jest niekompatybilny z tym, jak ogólnie agenci działają i te wszystkie idle, które tam są po drodze.
One i tak obciążają Twój budżet i Twoje limity. Z punktu widzenia GitHub Actions to nie jest żadne wytłumaczenie, że czekasz na jakąś porcję tokenów i nic się nie dzieje w tej konwersacji. Zegar leci, wskazówki się przesuwają, no i charge po prostu. Więc możesz paradoksalnie mało osiągnąć w konwersacji z agentem, ale dwie godziny zeszły i dwie godziny z limitu zniknęły. Dokładnie, dlatego też postanowiłem, że jakieś moje dwa stare komputery, które są jeszcze na Intel Core Duo czy jakieś tam inne, mają cztery kory. Nieważne, mają cztery kory, mają po 32 czy 64 giga RAM-u, będą dobre na runnerów lokalnych. Także w tą stronę myślę, że to wszystko będzie szło. Opłacało się nie wyrzucać ani nie sprzedawać sprzętu, bo teraz ta siła obliczeniowa i pamięć może się przydać.
Nawet jak jest mała, to dopuszczenie testów będzie wystarczające. Dla osób, które gdzieś tam mają zahomikowaną jakąś część kasy na swoich kontach i zastanawiają się, czy w to iść, to powiedz jeszcze co nieco o takich realiach spienia na domowego budżetu, no bo ktoś tam ma te 20-30 na ten czy inny kawałek sprzętu, nawet ten sprzęt w tym sklepie się pojawia. No ale jak bardzo mnie wywali teraz rachunki za prąd, jak bardzo Tobie wywaliły te rachunki za prąd i czy tam o 20 stopni cieplej jest w domu, w mieszkaniu z tego powodu, jak to u Ciebie wygląda? Na razie to czekam na rachunek wyrównawczy wiosną, wtedy się okaże ile to będzie kosztowało. Oczywiście mniej więcej sobie to liczę, czyli wiem jaki jest pobór prądu.
Póki co pi razy drzwi, bo wciąż przymierzam się do tego, żeby kupić sobie miernik poboru i podłączyć serwer do tego miernika poboru. Ale wiem ile GPU może wyciągnąć, wiem jaki jest ustawiony limit na nim, bo musiałem oczywiście ustawić kapa i zejść z 300 W na 250 W na kartę, z tego względu, że przy 300 W i pracy pół godziny non stop temperatury zaczynają przekraczać 105 stopni, nie chciałem, żeby to było więcej. Teraz przy 250 W trzyma się 100-101 max, z reguły jest mniej. Ale tak, mamy 4x250 plus procesor załóżmy 100-150, bo musi przemielić część danych z RAM-u, bo model offloaduje część rzeczy do RAM-u. Także liczymy spokojnie 1500 W. Tak średnio 16-20 godzin dziennie, uśredniając tak wszystko.
Licząc z górką, mamy 1,5 kWh przez 20 godzin razy 30 dni, razy cały rok. I coś tam wiemy. Dlatego GPU, są problem, czyli jeśli chcemy puszczać na GPU to tutaj musimy się z tym liczyć. Jeśli pójdziemy w stronę np. RTX-a 5090, który ma 32 GB RAM-u tak samo jak te moje AMD, no to tam już wchodzimy w 600 W na godzinę. Prawdopodobnie dobrze byłoby też ustawić tam kapa, bo wiemy, że przynajmniej widzimy, że albo konektory, albo sam kabel 600 W, który nie wygląda jakby miał te 600 W uciągnąć, ich nie uciąga, to wszystko się topi. Właśnie ostatnio miałem problem z hardware’em, wymiana kabla 600 W. Dla kart, które ciągną 250 niech będzie 300 W. Te kable są strasznie słabe. Także jeśli przerzucimy je na 600 W karty graficzne, może być różnie.
Trochę zgrzytam zębami jak sobie myślę o tym moim kolejnym pytaniu, ale chciałbym trochę właśnie wejść w taki świat, może większej abstrakcji, a może wcale nie, na chwilę przynajmniej, bo mieliśmy tą historię tych agentów, którzy to serwery OpenAI opuszczają i kierują się tam w stronę Hugging Face’a i tam sprawdzają co tam się w tym Hugging Face’ie dzieje, wracają z jakąś porcją danych, rozwiązują sobie benchmark, zupełnie nie tak jak to powinno robić. Myślisz w ogóle o jakichś takich kwestiach dotyczących właśnie sandboxów i bezpieczeństwa tego twojego setupu, że im dłużej cię nie ma przy tych maszynach, im dłużej te sesje trwają, tym oczywiście większe ryzyko, że tam się coś wydarzy niepokojącego?
Jakoś się już dzisiaj przed tym zabezpieczasz? Wszystko skonteneryzowane, bezpośredniego dostępu do serwerów, tam gdzie lecą deploymenty agenty nie mają, czyli przez SSH się nie połączą. Mają dostęp przez Git i już próbowały robić głupie rzeczy wrzucając część rzeczy po prostu w akcję, bo tam jest dostęp SSH, więc jak jest dostęp SSH to możemy robić wszystko. Ale to już jest kwestia uprawnień na poziomie SSH do folderów, do tego co można robić itd. Także tutaj schodzimy na poziom właśnie co kogo interesuje. Jeśli chcesz robić homelaba i puszczać coś lokalnie, ewentualnie robić to na infrastrukturze firmowej, musisz zejść na poziom infry i zabezpieczeń, inaczej się nie da. Czyli realnie jest to rzecz, o której już po prostu myślimy, jest to jedno z standardowych wymagań niefunkcjonalnych?
Polecam o tym myśleć od razu. Za dużo jest historii o tym, że ktoś nie pomyślał, a potem jest płacz, że baza danych została wyczyszczona, że dysk został wyczyszczony. To są bardzo proste rzeczy, przez które można się zabezpieczyć jedną linijką kodu, albo po prostu poprawnym uprawnieniem dostępowym. Koniec. To nie jest coś trudnego, nad czym trzeba się zastanawiać. To po prostu trzeba zrobić i tyle. Szczególnie, że jest tam taką klamrą spinając ten wirtualny pracownik, któremu można delegować te rzeczy, o ile tylko mamy na poziomie koncepcyjnym. To nie jest tak, że możesz zapromptować, zabezpiecz mi ten setup, ale możesz to zapromptować odwrotnie, gdzie są luki, gdzie są dziury, co tu jest nie tak.
Zrób sobie jakieś przeczesywanie eksploracyjne, gdzie się możesz wbić. Możesz zacząć od tego, zabezpiecz mi to, a potem puścić drugiego obok, tutaj sobie zabezpieczyłem, to teraz mi to sprawdź, włam mi się tam, dlatego polecam też tą drogę, bo bardzo dużo widzimy takich argumentów przeciwko kodowaniu z AI, czy robieniu czegokolwiek z softwarem za pomocą AI, że AI nie rozumie, popsuje, trzeba to wszystko pilnować, testować, ale jeśli możemy użyć AI do popsucia czegoś, czyli włamania się gdzieś, to dlaczego nie możemy powiedzieć jednemu agentowi zrób coś, a drugiemu powiedzieć popsuj to coś a potem niech wynik pójdzie do tego, który to robił, który był odpowiedzialny za dostarczenie tego dobrze, niech to poprawi, także ten feedback, sprowadzamy się tutaj do testów i testy nie muszą być tutaj testami zaprogramowanymi, czyli test end to end, performance, czy puścić sobie jakąś statyczną analizę kodu, statyczną analizę bezpieczeństwa testem może być też po prostu agent, który będzie nam próbował się włamać na nasz serwer, czy popsuć naszą aplikację w jakiś tam sposób, zrobić exploratory testy i zrobić z nich raport, to jest wszystko droga, którą możemy użyć bez żadnego problemu i to nie kosztuje nas specjalnie dużo effortu, bo po prostu można sobie odpalić byle którego klienta jajowego i powiedzieć tu masz linka, rób coś i to będzie robić Myślę, że my też już jesteśmy troszkę można powiedzieć po drugiej stronie rzeki i dla nas to jest jakby oczywiste, bo ty powiedziałeś właśnie, że bez żadnego problemu, natomiast mi się wydaje, że nadal jest tu jakaś taka bariera mentalna do przejścia i trzeba się przygotować na zmianę sposobu pracy z agentem i myślę, że to mi zostanie jakąś taką luźną rozmowę w kuluarach jednej z konferencji jeszcze jakiś czas temu, gdzie grupka się zebrała i trochę się naśmiewaliśmy z agentów, którzy robią code review innym agentom Myślę, że to też będzie totalnie obvious za jakiś czas, to już jest totalnie obvious w tych firmach AI-native To u nas leci To jest standard, ale wiesz, jeśli nie przebijesz tej bariery, to nadal masz ten model, gdzie agent coś może zrobić, a potem my ludzie siadamy i skazujemy palcami, ok, tu zepsułeś, tu zepsułeś, tu jest niefajne, tu jest niefajne i to jest ta nasza praca Tak, dlatego jak rozmawialiśmy wcześniej, jaka będzie przyszłość, nie wiadomo, bo już teraz mamy taką perspektywę, że bardzo dużo rzeczy możemy przerzucić na agentów, tylko jest kwestia po prostu tego, jak tych agentów sobie zaprojektujemy i od tego to dużo zależy Gdzie sobie zostawimy tą lukę na to, żeby tam być przy tych agentach, żeby móc coś z nimi współpracować, czy żeby po prostu puszczać je i czekać na gotowe zadanie Także to nie jest kwestia tego, że AI nas zastąpi, tylko my robimy narzędzia, które są dla nas, które mogą nas zastąpić i to jest bardziej kwestia tego, jaką my decyzję podejmiemy, gdzie my się widzimy w tym całym procesie Ja widzę się gdzieś w tym procesie jeszcze jakoś, ale staram się po prostu wyrzucić się z niektórych części tego procesu No dobra, ale zapytam tak zupełnie szczerze i zupełnie prywatnie, czy to też wynika z jakiegoś takiego komfortu finansowego, już dla Ciebie to jest łatwa taka dyskusja do prowadzenia?
Może ona wcale nie jest łatwa, ale taka, że w ogóle ją możesz unosić, że po prostu masz jakąś taką poduszkę i sobie mówisz, ok, no co się stanie, to się stanie, ale ja tam się wymyślę i nie liczę sobie tutaj do pierwszego, żeby przeżyć Czy realnie jesteś takim gościem, który po prostu ma takie nastawienie do życia, że ok, jedna ścieżka się zamyka, a to pięć innych się otwiera? Ja właśnie przed AI-em, czyli 3 lata temu, miałem taki drobny kryzys egzystencjalny i zastanawiałem się, czy ja chcę dalej w IT coś robić, także AI mnie uratował trochę, zostałem w IT Ale co, za dużo rzeczy widziałeś? Za dużo tych nużących zadań cały czas jeszcze się mogło robić? Za dużo ciągle tego samego, w sensie jak się siedzi na frontendzie i chce się przejść, chciało się przejść wtedy w jakieś inne aspekty, to trzeba było trafić do dobrej firmy, do której czasami było ciężko trafić, żeby ktoś pozwolił Ci na to, żebyś mógł pójść w inny obszar, którego nigdy nie dotykałeś, nie znasz języka, nie znasz niczego i chcesz się uczyć Takich środowisk, gdzie możesz takie rzeczy robić jest naprawdę niewiele i w moim przypadku ja zostałem przy frontendzie i muszę pracować przy Reakcie, którego nie lubię, muszę pracować przy Angularze, który jest jaki jest, ale w sumie robi robotę A pojawił się AI, nagle mogę uczyć Pythona, idzie mi to całkiem sprawnie, rozpocząłem współpracę z Sembotem, tam robiliśmy trochę eksperymentów, tam pozwoliłem sobie zejść z mojej normalnej stawki, była to wciąż spoko kwota na tamte czasy Ale mogłem robić rzeczy, eksperymentować i z Bartkiem robić dosyć ciekawe rzeczy. Bartek poszedł dalej w to, nasze drogi się rozeszły, no i trafiła się firma, która teraz pracuje. Były perspektywy na pracę w .NET, było pozwolenie na to, spoko, lecimy A teraz się okazuje, że ja mogę w sumie robić wszystko, mogę robić w każdym aspekcie, tylko znowu, jeśli teraz chciałbym zmienić pracę, to rozbijamy się o to, że większość firm dalej pyta o szczegóły takie implementacyjne, gdzie to przestaje mieć sens Ja już dawno zapomniałem o niektórych rzeczach, bo automatycznie, jeśli nie używasz, jeśli nie piszesz tego kodu, no to gdzieś to umyka. Fakt, że tam w Javascript pewnie mogę w nocy usiąść do klawiatury i coś poklepać, ale wciąż część rzeczy umyka Ja na przykład teraz chcę wracać do podstaw architektury, zacząć sobie wszystko przypominać od początku, bo widzę, że gdzieś to mi umyka i chciałbym się z modelem lepiej komunikować, a na projekcie tego też czasami nie ma.
Gdzieś na projekcie nie rozmawiasz o wzorcach, nie używasz języka technicznego bardzo zaawansowanego, bo nie ma takiej potrzeby czasami. To jest też bardzo ciekawa asymetria, o której powiedziałeś, że to nie jest tak, że po drugiej stronie masz braki, raczej są braki na poziomie querowania, jak ty nie masz tej wiedzy i doświadczenia, w sensie ta wiedza tam czeka, tylko musi to query polecieć w odpowiedni sposób. Tak, tak też. Wiem co chcę, wiem jak to jest, a czasami nie wiem co model do mnie mówi, bo ustawiony jest taki tryb, żeby mówił do mnie technicznie, a jeszcze czasami mówi żargonem z angielska, no to też nie wszystkie słowa po angielsku kojarzę i trzeba się tego uczyć. Więc gdzieś widzę te aspekty, że niby jest się te naście lat, uczyło się ludzi, ale przez to, że się nie używało, nie używa, teraz się przestaje używać część rzeczy, to jakoś to umyka.
Są takie dwa pytania za 12 tysięcy miliardów dolarów, które tutaj rozwiązują większość problemów w tej naszej branży. Pozwolę Ci wybrać tutaj jedno pytanie, na które odpowiesz, bo to są dwa cholernie trudne pytania, już tak zmierzając do brzegu tej naszej dzisiejszej rozmowy. Mianowicie jedno pytanie dotyczy oczywiście junior developerów i programistów, którzy dopiero rozpoczynają, gdzieś tam widzą siebie w tym zawodzie. Może masz takie osoby, ja mam takie osoby, które piszą w DM-ach, słuchaj Przemek, słuchaj Mateusz, no ja bym chciał bardzo zostać tym programistą, bo tam widzę co robisz, fajne rzeczy robisz, no to co zrobić, żeby tym programistą zostać? Natomiast drugie pytanie, no to z kolei o tych osobach doświadczonych w kryzysie, być może takim, o którym Ty wspominałeś, znaczy co zrobić w ten najbliższy poniedziałek, żeby z tego kryzysu może wyjść, żeby patrzeć na to programowanie w epoce AI troszkę inaczej, żeby odzyskać w ogóle tej zajawy?
Tutaj to ostateczne pytanie do Ciebie, czy bardziej czujesz tę perspektywę juniorów i masz jakieś intuicje a propos tego, co oni mogą robić, do czego mogą być potrzebni, czy raczej chciałbyś tutaj jakoś, wiesz, z apelem do doświadczonej wyjści, nie tracćcie nadziei, drodzy Państwo. Znaczy apel do obu myślę i to będzie ten sam, który się powtarza od lat, chcesz coś zrobić to po prostu to rób. Wiem, że to klisza straszna, ale… to się wszystko to rozbija. Programistą zostaje się dlatego, że chce się coś stworzyć. Że chciało się coś zrobić. Ja zaczynałem od tego, że chciałem robić gry. Coś tam po drodze wyszło, nie wyszło. Więcej nie wyszło, niż wyszło. Ale to był taki motywator. I to wciąż jest motywator dla mnie. W sensie próbuję gdzieś tam eksperymentować z AI-em, robić gry.
2-3 lata temu z kolegą poszliśmy na Game Jam’a. Właśnie wtedy w okolicach tego mojego kryzysu. Nie znając C#‘a zrobiliśmy grę w Godot’cie. Akurat kolega znał C#‘a, a ja nie znałem C#‘a. No to co? Wtedy jeszcze AI w powijakach. Ale dało się coś zrobić. Dokumentacja do C#‘a, dokumentacja do Godot’a, auto uzupełnianie AI’em. Teraz już nie trzeba auto uzupełniania. Teraz to już się po prostu samo pisze. Next line prediction. Najgorętszy temat ostatniego dwulecia. I po prostu robić rzeczy. Junior zawsze potrzebował tego pociągu do robienia czegoś. Bo jeśli ktoś chciał pójść do IT tylko po to, żeby usiąść przed komputerem, poklepać klawiaturę i zarobić wtedy 15k, to szybko się wypalał. Albo teraz się wypala.
Chyba jeszcze bardziej. Ta branża będzie wypluwać ludzi. Tak, to właśnie teraz branża będzie wypluwać tych ludzi i oni będą sami się tak naprawdę wykluczać. No bo to będzie walka w głowie. Przez tyle lat pracowałem, pracowałem na to, żeby być tym programistą, uczyć się tego programowania, dostać się do branży, udało się utrzymać, nawet gdzieś tam awansować, a nagle gdzieś te wszystkie skill’e, wszystkie te umiejętności nie są potrzebne. Zmarnowane 5, 10, 15 lat i po co to? Widziałem już takie komentarze, też zacząłem się w pewnym momencie zastanawiać, po co mi było moje ostatnie 16 lat, skoro ja teraz mogę po prostu wypluwać ten kod, nie patrzeć na niego, nie czytać go nawet i robić te wszystkie rzeczy.
Tylko tak z perspektywy czasu, no to częściej robiłem to, co chciałem, niż nie chciałem. W sensie… Po prostu, nie? Po prostu trzymaj za kierownicę. Coś w życiu trzeba robić, robić rzeczy, które lubi się robić. Nie zawsze można robić rzeczy, które się lubi, wiadomo, ale trzeba starać się w tą stronę dążyć. Mamy kolejny etap do tego, że mogę robić rzeczy, które chcę robić i dlatego jeszcze coś tutaj, w ogóle tutaj rozmawiamy. Bo cała ta frajda ostatnich trzech lat to myślę, że obudziła mnie trochę. Myślę, że to jest piękna puenta tej rozmowy. Nie będziemy iść w stronę żadnych prognoz i tego, co tam się wydarzy w tym 2027 roku. Możemy sobie zrobić kolejne spotkanie na ten temat, ale nie trzeba o tym myśleć aż tak bardzo, żeby dzisiaj już mieć właśnie zajawkę zrobienia rzeczy.
Mateusz, wielkie dzięki za tę dzisiejszą rozmowę. Oczywiście jak widać nasz plan, żeby w godzinkę spędzić całą dyskusję, idealnie się udało zrealizować, ale była to mega ciekawa rozmowa, tak samo jak nasze poprzednie spotkanie w 10xDevs. Także wielkie dzięki za to, że wpadłeś. Ja tutaj do wszystkich słuchaczy apeluję, żeby zostawiać właśnie komentarze, pytania, jak macie jakieś kwestie, które chcielibyście, żeby albo Mateusz zaadresował gdzieś tam na swoich social mediach, albo przy kolejnym spotkaniu to też koniecznie dawajcie znać. No i podawajcie dalej ten odcinek, oznaczajcie nas na Spotify, na innych platformach streamingowych, gdzie tam słuchacie tego podcastu, dawajcie 5 gwiazdek. 5200 osób nas teraz słucha na Spotify, tylu mamy followersów, bardzo nas to cieszy, bo to taki podcast, o który sobie dbamy od kilku lat i Mateusz świetnym gościem byłeś, świetna ta rozmowa, także naprawdę wielkie dzięki za to, że wpadłeś.
Mateusz, ja Ci w każdym razie życzę, żeby za te kolejne pół roku, jak będziemy rozmawiać jednak była tutaj zachowana jakaś ciągłość w tym, co robiłeś do tej pory, żeby nie trzeba było znowu robić pivotu o 180 stopni, nie wiem czy Tobie to jest do czegoś potrzebne, ale patrząc na tę branżę to jest to możliwe, także jak się spotkamy kolejny raz to pogadamy jak ten świat się zmienił. No i cóż, do następnego. Dzięki za rozmowę, miło było. Cześć.