Buduj z AI - dla siebie i w firmie | Gość: Mateusz Wróbel | Opanuj.AI

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 to 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 Engineering z Trivago. Cześć Mateusz. Cześć.

Mateusza możecie śledzić między innymi 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 Engineering tak naprawdę rozumie od podszewki, rozumie go z wielu różnych stron. Jest też ogromnym zajawkowiczem, buduje swój home lab, zainwestował, chyba się zgodzimy 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 local hosta, 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.

Opanuj.AI. Pug, wszystko zrobione, tak, 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 wystawiony, my tylko sprawdziliśmy, okej, 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 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 Engineering, 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.

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ć tę aplikację po prostu w asystenta głosowego, żeby nie musieć robić różnych hacków na tym, co jest w software, czy też kombinować, jak w moją aplikację czy w przeglądarkę wrzucić jakiegoś asystenta. Opanuj.AI Podcast.

I tutaj jest ten największy win, to zwycięstwo po prostu z tych obu światów, gdzie z jednej strony masz coś przewidywalnego, z drugiej strony masz tą elastyczność agenta i właśnie w takich warunkach rzeczy się dzieją. Zakładam, że u ciebie to też jest właśnie 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, bo 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.

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ć.

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 dewelopmencie, 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. Troszkę ze względu na czas na jakieś też umówiliśmy. 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.

Sam software z ich strony działał niestabilnie. Te same prompty, te same modele i jednego dnia działało to dobrze, 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 kursora. 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 jakby oni sami tego nie używali czasami.

Opanuj.AI Był taki okres, że był peak of peak. To mogłem sobie wybrać, że OpenCode nie ma off-peaka w ogóle, a olama miała. Czyli najpierw mogłem sobie z olamy skorzystać. Jak wchodziło w okres off-peaku, czyli droższy, to się automatycznie przerzucał na OpenCoda. Także własny software, Naprawdę niedużo czasu to kosztowało, niedużo pieniędzy, jeśli by to nawet przemnożyć na zużyte tokeny, a mamy absolutną wolność, a i tak musielibyśmy to zrobić, tak musielibyśmy to zrobić.

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 3-4 subskrypcje co-pilota. To teraz musimy mieć jeszcze dodatkowy software do tego, żeby rotował ci klucze, żeby rotował ci wszystko, jeszcze do tego, żeby faktycznie to wszystko działa.

Opanuj.AI Podcast. Episode 3 Opanuj.AI Podcast. Tak, no ja się ostatnio też z tym spotkałem, czy właśnie z tym, jak trzeba sobie ważyć właśnie to wykorzystanie software'u i hardware'u, kiedy chciałem właśnie 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 chmurowymi 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, tak? Jakby z punktu widzenia GitHub Actions, Nie jest jakby żadne wytłumaczenie, że tam czekasz na jakąś porcję tokenów i nic się nie dzieje w tej konwersacji.

Opanuj.AI. 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 wszystko pilnować, testować. Ale jeśli możemy użyć AI do popsucia czegoś, czyli włamania się gdzieś, no to dlaczego nie możemy powiedzieć jednemu agentowi zrób coś, a drugiemu powiedzieć popsuj to coś.