Jak Pracują Zespoły AI-Native | Opanuj AI

Materiały źródłowe

Witajcie w podcaście Opanuj.AI, gdzie analizujemy najważniejsze zmiany ze świata LLM-ów, agentów i generatywnego AI. Waszymi prowadzącymi niezmiennie jest dwójka doświadczonych programistów i mentorów kodowania agentowego Przemek Smyrdek i Marcin Czarkowski. Witajcie serdecznie. W tym odcinku porozmawiamy o tym, co dzieje się z procesami w branży IT, które przez lata uchodziły za nienaruszalne, za lepsze praktyki. Porozmawiamy o code review, każdej linii kodu. Porozmawiamy o dyżurach on-call i zespołach liczących z 6 do 10 osób. Wszystkie te procesy, wszystkie te praktyki powstały przy założeniu, że największym wąskim gardłem w branży IT jest człowiek piszący kod. No i teraz w wielu firmach większość kodu piszą agenci i przez to takie podejście przestaje działać. Code review w oczywisty sposób się zatyka. Będziemy tutaj się posługiwali m.in. przykładem firmy Imprint, gdzie merżuje się 4 razy więcej PR-ów niż 2 lata temu, a mediana czasu review wzrosła z 33 do 77 minut. Słuchajcie, Will Larson proponuje regułę small change, opowiemy o co w tej regule chodzi. Następnie przejdziemy do znanych, ale nielubianych nocnych pożarów i zobaczymy jak możemy wykorzystać agentów AI właśnie w tym procesie SRE, które będą badali incydenty równolegle, czy takie rozwiązania warto budować in-house, czy może kupować gotowce. No i porozmawiamy o tych zespołach, jakie one teraz powinny być. Czy nadal zależy nam na takim zespole, które możemy wykarmić dwoma pizzami, czy może powinniśmy do tego podchodzić obecnie trochę inaczej. Przemku, od czego tutaj zaczniemy? Jakie mamy założenia, które chcemy w jakiś sposób challenge’ować?

No trzeba by było zacząć od tła, o które opieramy właśnie całą tę dyskusję. Jakieś założenia, na których ta nasza branża działa. Mamy takie dwa światy, można powiedzieć. Świat dzisiejszy, świat już wczoraj, co do którego jesteśmy pewni, że go znamy, że jest sprawdzony, wiemy gdzie ma jakieś tutaj edge case’y, problemy, wyzwania, ale ogólnie się sprawdza. No i mamy ten świat jutra, dotyczący właśnie zaproszenia agentów do naszych środowisk, do naszych zespołów. No i oczywiście pomiędzy tymi dwoma światami jest pewnego rodzaju napięcie. Ja powiem o tym świecie jutra, w większości tego odcinka, ale właśnie zaczniemy od tego świata dzisiaj, gdzie na przykład code review cały czas przede wszystkim bazuje na ludziach, na ich dostępności, na założeniach, że ludzie mają czas, mają przestrzeń w głowie, że są w stanie procesować określone ilości tych pull request’ów, które się pojawiają przed nimi. Mamy na pewno systemy kontroli wersji, które dzisiaj w 99% sprowadzają się do Gita i do tego modelu rozproszonego, gdzie każdy pobiera sobie raz kopię, repozytorium, pracuje sobie we własnym tempie, we własnej rzeczywistości nad tą kopią i kiedyś swoje zmiany merge’uje. Też się do tego przyzwyczailiśmy. Dyżury on-call, które również w dużej mierze opierają się na dostępności ludzi, na tym jak mamy dobrze skonfigurowane powiadomienia, czy akurat jesteśmy przy telefonie, czy mamy jakiś, nie wiem, pager, jakąś aplikację typu PagerDuty. No i to wszystko właśnie jest dopasowane do tempu wytwarzania kodu przez ludzi. Dostępności ludzi i tego, że po prostu pull request’ów na przykład w trakcie tygodnia pojawia się, no nie wiem, 5, 10, 15, bo do tego taka ludzka przepustowość się sprowadza. No i słuchajcie, no tutaj pojawia się wyzwanie, mianowicie tego świata już za bardzo nie ma. Wyzwanie polega na tym, że tego świata nie ma i teraz są firmy, które już to wiedzą i to zaakceptowały i starają się do tego przygotować. Są firmy, które czują, że tego świata nie ma, ale jeszcze nie wiedzą co z tym zrobić. No i jest jeszcze ta trzecia kategoria, której chyba tutaj dzisiaj za bardzo nie poruszymy, ale zobaczymy czy w tę stronę pójdziemy, czyli firmy, które w ogóle uznają to za nieprawdę albo ludzie, którzy uznają to za nieprawdę, za jakieś takie tutaj bajki, które chłopaki w podcaście opowiadają. Skupmy się na tym, co na horyzoncie. My sobie tutaj wykorzystamy właśnie rekomendacje firmy Anthropic jako taką wskazówkę tego, co nas czeka, bo oni piszą, że firma, która pracuje właśnie z modelami frontier jest mniej więcej 12-18 miesięcy przed resztą firm, która jeszcze nie czuje tego, co tak naprawdę się kryje z tym potencjałem sztucznej inteligencji albo pod tym potencjałem sztucznej inteligencji. No więc Anthropic w swoim blogu w październiku opisał kilka punktów tego, jak zmienia się ich miejsce pracy, środowisko pracy i od tego wejdziemy właśnie do dyskusji, jak całe miejsce pracy w naszych firmach potencjalnie może się zmienić. Pierwsza ważna rzecz, do marca 2026 roku agenci przepracowywali już więcej godzin niż pracownicy, niż ludzie, którzy tymi agentami mieli sterować. Dzisiaj na każdą godzinę pracownika przypada około 6 godzin pracy agenta, czyli taki stosunek 1 do 6. Mamy niesamowity przyrost merger, które po prostu dotyczą całego systemu kontroli wersji, tego co na poziomie systemu kontroli wersji musi się dziać. Anthropic mówi, że w maju oni mergerowali około 2500 zmian dziennie, we wrześniu uwaga 30 000 razy, czyli przyrost 12-krotny, jakieś absurdalne liczby i statystyki. No i oczywiście przy takim przyroście wszystkie te projektowane procesy, uzgodnienia, agrementy pod człowieka po prostu przestają działać. Anthropic wspomina, zresztą wy też to na pewno czujecie, że rosną kolejki na review, przybywa konfliktów, o tym nam też mówią studenci 10xDevs, no i właśnie nocnych alertów, którymi też trzeba jakoś zarządzić. No i teraz właśnie są różne sposoby radzenia sobie z tym problemem. Są firmy, które zderzyły się z tym, myślą w sposób krytyczny, akceptują ten potencjał nowych narzędzi i starają się tutaj jakoś tym zarządzić. No i są też te firmy, które niestety jeszcze nie przeszły na drugą stronę mocy i no tak jak mówię, albo nie korzystają z AI, albo twierdzą, że to jest wszystko nieprawda. Tych nie ruszamy, pogadajmy o tym, jak sobie radzić z tym nowym światem, z tą nową rzeczywistością, kiedy to agenci i ludzie z agentami procesują kod w masowych ilościach. I zaczniemy od już absolutnego chyba myma, problemu potencjalnie nierozwiązywanego, czyli tych słynnych bottlenecków na code review. Pisze się szybciej, ale nie da się tego przeglądać. No i po co nam to całe AI, Marcin?

Tak można łatwo powiedzieć, że to co prezentuje firma Anthropic to jest wyłącznie marketing, albo to jakaś psychoza AI, oni przesadzają, ale też jest wiele firm, które powiedzmy jest bliżej tego, z czym spotykamy się w przeciętnej również polskiej firmie. I myślę, że dobrym przykładem jest to o czym mówi Will Larson, czyli doświadczony zarówno inżynier, jak i engineering manager, autor poczytnych książek i też fajnego bloga. No i on opowiada jak zmienia się proces review w firmie Imprint. No tam właśnie trzy razy więcej PR-ów niż dwa lata temu. Może to nie jest 30 tysięcy zmian dziennie, ale cały czas trzy razy więcej. To już i tak powoduje problemy i myślę, że z tym mierzy się wielu z nas w swojej codzienności. No i mimo wszystko też merżujemy w około naście zmian więcej niż do tej pory. Z tego powodu ten czas przeznaczony na review wzrasta co najmniej dwukrotnie jak w przypadku Imprint. No pewnie w wielu filmach to może być znacznie więcej, bo wielu inżynierów nawet nie było specjalnie przyzwyczajonych do robienia code review. To często był taki obowiązek, który się delegowało do tej jednej osoby, która może była mniej asertywna albo z jakiegoś powodu akurat ten proces lubiła. I kiedy obecnie już nie ma wymówek i każdy musi się za to brać, no to pojawia się taki pattern mid-proxy, o którym też często się ostatnio mówi.

No czyli biorę PR-a, przeklejam go do swojego agenta, proszę o komentarze, proszę o analizę.

Dokładnie i potem przeklejamy te komentarze, nie do końca rozumiejąc czy one w ogóle mają sens. I potem ta osoba wrzuca te komentarze do swojego agenta, sprawdza czy to ma sens i mamy gdzieś tam rozmowę pomiędzy agentami za pośrednictwem człowieka.

Ktoś to ostatnio fajnie nazwał slop grenade.

Tak, to też są takie właśnie slop grenade, no masakra. Ciężko gdzieś tam w ten sposób pracować. No i co fajnie zaprezentował Will Larson, w takiej sytuacji warto sobie zadać pytanie, czemu my w ogóle mamy jakiś proces, czemu on służy. No i tak samo możemy się zastanowić po co nam code review, po co my to robiliśmy w przeszłości i zastanówmy się jak możemy teraz zachować te same zalety, te same potrzeby realizować w ramach organizacji, może w inny sposób. No i tutaj Will Larson wskazuje takie cztery główne powody, pod którymi się podpisuje. My też w naszych szkoleniach gdzieś tam właśnie wskazywaliśmy te istotne zalety. Były dość obszerne lekcje w Opanuj Frontend na temat code review, jak robić to dobrze. No i tutaj dzielenie się wiedzą, istotny element call review. Dzięki temu podnosiliśmy swój warsztat programistyczny, no i również zrozumienie samego systemu. No i teraz jak można do tego podejść? Robiąc przegląd z całych klastrów PR-ów, wizualizując tą wiedzę, nie musimy koniecznie skupiać się. na code review linijka po linijce, żeby ten sam cel osiągnąć. Chcemy też zapobiegać błędom oczywiście. Nie chcemy, żeby to co wchodzi na produkcję było wysokiej jakości. No i tutaj znowu możemy postawić na lepszy pipeline CICD, na lepszą automatyczną weryfikację. Możemy tutaj obejść te ograniczenia, które pozornie się pojawiają, jeżeli nie robimy takiego bardzo szczegółowego code review line by line. Następnie nie chcemy wprowadzać żadnych złośliwych zmian, które gdzieś tam z takiej ani innej przyczyny by na tę produkcję trafiły. Czy to ze względu na jakąś bibliotekę, którą nieświadomie dodamy do naszego kodu.

Pracownika, który odchodzi.

Tak, i chce tutaj nabroić. Tak więc znowu twarde reguły tego, co wprowadzamy na produkcję, co możemy robić. No i audytowanie tych zmian w sposób automatyczny i również manualny. No i chcemy również, żeby to co wprowadzamy było zgodne z compliance. Zwłaszcza jeżeli pracujemy w większej firmie, przechodzimy na bieżąco różnego rodzaju audyty. No to musimy mieć świadomość, że faktycznie są obszary, gdzie to ludzkie review będzie niezbędne. Jeżeli pracujesz w banku, jeżeli modyfikujesz jakiś krytyczny moduł obsługi płatności, no to najpewniej te wszystkie usprawnienia to nie jest coś, z czym będziesz mógł wyjść do swojej codziennej pracy. No bo są ograniczenia prawne, z którymi trzeba się liczyć. Tak więc kiedyś to review adresowało te cztery różne powody. To jak najbardziej było fajne.

Tutaj Ci przerwę. Zastanawiam się ile osób świadomie rozkładało to aż na cztery wymiary. Wydaje mi się, że naprawdę wiele osób, które rozmawia o tych tematach, widzi code review tylko jako taką reprezentację jednego z nich albo dwóch. Często to się sprowadza do tego, czy ja zobaczyłem kod przed wyjściem na produkcję, czy nie zobaczyłem. Ale mało kto sobie zadaje pytanie, posłuchajmy ten kod widzieć. Także to jest super rozróżnienie tego, co się może dziać, jaki jest ten outcome. Ty też sporo eksperymentu robisz w ogóle z tym dzieleniem się wiedzą. Jesteś takim gościem, który cały czas gdzieś tam kombinuje, szuka różnych form przedstawienia tego, co masz w głowie. I ten ex-visualizer to jest taki mechanizm, który stosowałeś taki skill. I myślę, że to jest super ogólnie, że siadamy i zastanawiamy się po co tam być. Może tego nie powinno być, może lećmy na proda, ale nie. Możemy różne potrzeby na różne sposoby adresować. To, że kiedyś mieliśmy jakiś sposób, który już nie działa, to nie znaczy, że teraz tracimy to i jesteśmy w przysłowiowej czarnej dupie. Tak nie musi wcale być.

Też wydaje mi się, że dużo ludzi utożsamiało code review przede wszystkim z zapobieganiem błędu albo ewentualnie wprowadzaniu długu technologicznego. Bardzo też zależy od tego, kto ten code review. No więc każdy jakieś tam swoje cele.

Jakieś poczcie kontroli.

Dokładnie. I tak dalej, i tak dalej. No ale to już siłą rzeczy trochę odeszło do lamusa, co nie znaczy, że nie możemy sobie z tym poradzić. No skupmy się na samej tej dużej objętości tych PR-ów. Jak możemy to zmienić? O tym opowiadałeś w najnowszym odcinku na YouTube, który polecamy. O co chodzi w regule Small Change, którą Will Larson rekomenduje?

No Small Change bazuje na takim założeniu, że coś musimy automatyzować. Nie wszystko. Jest jakiś pozbiór pull requestów, które powinny przechodzić właśnie na produkcję albo w kierunku produkcji szybciej niż do tej pory albo przy mniejszym zaangażowaniu po prostu ludzi. No i teraz sobie zadajemy pytanie, ok, no to jakie są reguły tego PR-a, który można zautomatyzować, tej ścieżki tego PR-a, który można zautomatyzować. I teraz tutaj zaznaczę, to nie jest jeden przepis, który powielamy wszędzie i zawsze niezależnie od firmy. To jest po prostu jakby taki wariant tego, co Imprint robi i o czym właśnie Will Larson na swoim blogu pisze. Więc jakie tutaj są kryteria tego, żeby przegląd tego pull requesta automatyzować? Więc tak, po pierwsze zakres zmian, który tutaj jest określony dość tak arbitralnie, po prostu tysiąc zmienionych linii kodu. Ja widziałem na przykład w dyskusji na code review, że dla niektórych osób to jest zbyt dużo. Dla nich to wcale nie jest small change, to jest raczej medium change.

Na stare warianty to jest duży change.

Dokładnie tak, natomiast dzisiaj pewnie w zupełnie innej skali gdzieś tam operujemy, więc te tysiąc zmienionych kodu jest uznawane nadal za small change. Właśnie pewnie pod kątem tego, że jak agent coś ci wygeneruje poniżej tego tysiąca, no to jeszcze to jest mini prompt można powiedzieć, mini tweak. Więc mamy ten zakres. Druga rzecz, integrujemy bota. Integrujemy jakiegoś agenta w roli sędziego, który po prostu patrzy na to, co się dzieje, realizuje tutaj jakieś konkretne testy, czy jakiś taki audyt bezpieczeństwa i w Imprint to się określa takimi różnymi kategoriami błędów, albo priorytetami, albo jakimś impactem. Tutaj to jest nazwane P1 i P2. Pewnie jakieś błędy krytyczne o wysokim wpływie na ten codebase. Tego nie może być. Jeśli to się znajdzie, jeśli ten bot znajdzie tego rodzaju podatności, to od razu wykluczamy taki pull request tej ścieżki automatycznej. Autor musi być zaufany w ramach danego codebase i w ramach danej zmiany musi mieć co najmniej 10 zmergeowanych PR-ów w danym serwisie. Też super pomysł. Myślę, że właśnie wskazówka a propos tego, że to zaufanie jest super ważne i to doświadczenie w ramach jakiegoś tam obszaru firmy też robi robotę i ma ogromną wartość. Zmiana dotyka mniej niż N serwisów, czyli jakaś taka można powiedzieć entropia, ładnie mówiąc, ile tutaj chaosu i zamieszania wprowadzasz do tego projektu. No i nie dotykamy współdzielonych bibliotek, bo możesz komuś życie zapaskudzić, a tego robić nie chcemy. No i to są te założenia. Za tym stoi teraz konkretny tooling. Powiedzieliśmy o jednego rodzaju takim toolingu, czyli o bocie do code review, ale też mamy tutaj konkretne skille, czy też takie pliki konfiguracyjne, które wpływają na to jak ten proces działa. Mamy tutaj w pewnym sensie też taki self service, albo możliwość po prostu dostosowywania tych praktyk do swoich potrzeb. Więc tak, na poziomie projektu mamy plik small change, który pozwala Ci wyłączyć poszczególne ścieżki tego projektu po prostu z tego procesu, według jakichś reguł wrażliwości.

Bardzo ważne, jeżeli mamy takie moduły krytyczne, które są bardzo ważne dla działania systemu, no to możemy tutaj te heurystyki small change wyłączyć, więc pamiętajcie o tym, że to nie jest takie zero-jedynkowe. Mamy duże możliwości dopasowania tego do swoich potrzeb, preferencji. Tak jak mówił Przemek, te wartości, które w Imprint się działają, wcale nie muszą działać u Was. No i też pamiętajmy o tym, że może być wiele systemów, na przykład z małą ilością userów, albo z niskim ryzykiem, gdzie nawet można bardziej zaszaleć.

Tak, gdzie to będzie ciężkie, tak?

Tak.

Tak, tak, 100%, 100%. Tutaj a propos tego small change, to pewnie pytanko do Ciebie, bo Ty więcej czasu w teamach platformowych spędzałeś. To jest ogólnie pytanko, czy też taka prośba o komentarz. To jest taki fajny sposób dzielenia się tego rodzaju narzędziami, czy frameworkami, gdzie określasz właśnie mechanizm, ale dajesz konfigurację do użytkownika końcowego. Nie jako autor tej zmiany wiem, gdzie są te ścieżki krytyczne u Ciebie.

100%, to jest bardzo ważne też dostarczając tego typu rozwiązania dla zespołów, żeby właśnie zapewnić właściwą elastyczność. Oczywiście trzeba ustawić rozsądnie ramy, najlepiej poprzez rozmowy z zespołami i dobre zrozumienie tego, co jest krytyczne i powinno być niezmienne, a gdzie dać elastyczność. I to również w zależności od firmy, skali, nie ma jednej odpowiedzi, jak to dobrze zrobić. Tu jest ten słynny inżynierski osąd i myślenie produktowe, na które my tak gdzieś tam ostatnio stawiamy i mamy poczucie, że to cały czas jest duża przewaga i tak zwane job security. Nie mam poczucia, że tutaj LLM-y będą w stanie wykonać tą pracę za człowieka w przewidywalnej przyszłości.

Dokładnie, ja sobie wyobrażam prompta do LLM-a mówiącego zrób mi taki system, LLM mówi ok, ja to wszystko opakuję w jakiś util, nikomu nie damy w tym grzebać i koniec. Ale nie, nie tak wygląda ta dynamika w zespołach.

To jest znowu gra w kasyno trochę, jest szansa, że się wylosuje tak jak trzeba i często jest tak, że się nie wylosuje jak trzeba. Część ludzi powie, o, AI jest genialne, bo akurat co się wylosowało, to takie wnioski przynosi do stołu. Zupełnie nie o to chodzi, pamiętajmy, że te kluczowe decyzje powinny być po naszej stronie.

Dokładnie tak, więc mamy ten plik konfiguracyjny. Do tego są dwa skille pomocnicze. Zakładam, że to jest coś, co może używać właśnie ten bot. Mamy tutaj właśnie przegląd pull requesta, może być albo zatwierdzenie, albo pominięcie tego zatwierdzenia bez żadnych komentarzy, tam też były uwagi o tym, że też właśnie sporo tego slopu się pojawia właśnie na poziomie integracji AI z pull requestami, więc tutaj nie chcemy tego slopu generować. Review PR cluster to jest też taki ciekawy skill, który przy pomocy automatyzacji albo bota przegląda paczki PR-ów i proponuje tematy do dyskusji ludziom, na przykład, z czym często pracujemy, co się często zmienia, na co zwracać uwagę. Świetna sprawa, można to podjąć na jakimś planningu, na jakimś retro, można to gdzieś tam interpretować na sto różnych sposobów. To wszystko spina fleet, czyli taki centralny harness w humorze. Mamy tutaj pewnego rodzaju mechanizm, który właśnie sprawdza, czy te wszystkie checki są spełnione. Oddawany właśnie, myślę, że takiej szybkiej ścieżce integracji. No i też, co ważne, te zmiany ze small change nie omija takiego klasycznego CICD. Nadal się testy muszą wykonać, nadal jakiś pewnie deploy na środowisko testowe jest wykonywany i wszystkie inne metody, które zwykle na CICD sobie integrujemy, żeby ocenić jakość tego pull requesta. I też takie ważne założenie, jeśli błąd się właśnie prześlizgnie, to my tweakujemy ten pipeline, a nie wycofujemy się w ogóle z tego konceptu. My chcemy tutaj to po prostu szlifować, podnosić tą jakość, nie wycofywać się przedwcześnie. Naprawdę ciekawa sprawa.

Co ciekawe, również ciekawe, w około 2016 roku, w 2018, o ile pamiętam, w Smart Decoder, z którym razem pracowaliśmy, były już podejścia do tego typu automatyzacji. Ja się ogólnie też tutaj uśmiecham, jak zawsze słyszę, że nic nie można zrobić z tym code review. Jak ktoś nigdy nic nie robił i przyjął to jako po prostu złotą zasadę wszechświata, to owszem się nie da. Chociaż nie znam żadnego równania, które tutaj by to code review wyliczało. taki kształt jaki mieliśmy w przyszłości.

No dokładnie tak, więc myślę, że naprawdę wartościowy wpis, wartościowy artykuł, taki też pobudzający ogólnie do działania, do tego, żeby usiąść. Pytanie, czy są tutaj jakieś zastrzeżenia, może też pogadajmy trochę o efektach, które to generuje i jak ty w ogóle to widzisz.

Na pewno trzeba się liczyć na to, że będzie jakiś okres przejściowy, że to nie będzie działało tak dobrze. Musimy podjąć ryzyka i też procesu nauki, który zawsze jest wymagający. Trzeba po prostu eksperymentować i nie warto się poddawać po pierwszej, drugiej nieudanej próbie, bo co jest bardzo fajne w programowaniu z AI, że możemy uczyć się bardzo szybko. Szybko wyciągamy wnioski i kolejna iteracja nie kosztuje nas kolejnego kwartału pracy, kolejnego tygodnia, tylko najzwykle to jest kilka godzin. Kwestia tylko polega na tym, czy mamy dane, czy mamy nowe wnioski, bo inaczej będziemy błądzili, więc tutaj zachęcamy do takiego podejścia trochę laboratoryjnego.

Jak inżynier.

Dokładnie, jak inżynier. O tym zresztą będziemy mówili więcej. Przemek, mamy też nowe heurystyki, które stosuje Anthropic. Może nie wchodźmy jakoś mega szczegółowo, bo tam jest podobna historia, tylko razy 10, jak to zwykle w Anthropic, ale oni też stosują ciekawe podejście, które możecie sobie zaadaptować, wziąć pod uwagę w tych waszych rozwiązaniach.

Tak, no tutaj znowu, można wejść w technikalne, można wejść w takie rozwiązania taktyczne, raczej zwracamy uwagę na to, że to jest dyskusja wielopoziomowa. To nie jest tak, że po prostu pojawia się jakaś zmiana i ona już jest po prostu centymetr przed produkcją.

I tak musi być.

I tak musi być i przełącznik, wchodzisz, nie wchodzisz, tylko ogólnie robota się zaczyna wcześniej. Nawet, kurczę, na twoim komputerze.

100%, 100%. I to nie jest tak, że Anthropic wam powie, jak to zrobić dobrze w waszym zespole, nie powiedzą wam tego również. 10xDevs, oczywiście…

Dajmy klocki takie, z których można sobie poskładać.

Tak, no dokładnie, bo to są heurystyki, które warto przetestować i zobaczyć, na ile one są aplikowalne w naszym środowisku. Pamiętajcie też o tym, że jest wiele rzeczy, które już działało wcześniej, na przykład blokujące czeki automatyczne. Możemy sprawić, że jak testy nie przejdą, no to PR jest zablokowany. Niesamowite rozwiązanie istnieje na GitHubie, od kiedy z niego korzystam, czyli już dość długi czas.

Ja dosłownie wczoraj widziałem taki komentarz pod jednym z wątków na LinkedInie, że słuchajcie, wy tam mówicie o tym code review, a tutaj nikt nie ma jeszcze CI-CD. No ogólnie nie jest tak, nie? Ogólnie jest jakiś spektrum tego, czy masz to CI-CD, czy nie masz. Pewnie sporo firm nie ma, sporo firm się uczy, a dla wielu firm to jest jakaś kwestia trywialna po prostu, do którego dokładamy ten klocek AI.

100%, więc też czas na ten level up taki inżynierski trochę. Nie kopiujmy binarek na jakiegoś VPS-a bez pipeline’u CI-CD, no bo teraz to jest proszenie się o mega dużo problemów. To już kiedyś był ogrom problemów, teraz po prostu to widać. Bardzo lubię tą obserwację, że jesteś tak dobry w AI, jak dobra jest twoja platforma. No trochę widać obecnie, kto pływał bez przysłowiowych gdzieś tam majtek.

Bez platformy.

Bez platformy, więc to jest gdzieś tam koniec tego miesiąca miodowego, że łatwo się dowoziło software i robiło na tym kasę. W taki sposób trochę nie inżynierski, taka jest prawda. Więc czas też najwyższy, żeby praca odprogramowaniem stała się inżynierią, a nie tylko jakimś zajęciem polegającym na klepaniu kodu na podstawie tiketów.

Sześć warstw kontroli, o której mówi Anthropic. Pierwsza właśnie weryfikacja lokalna. Mamy agentów. Ci agenci przede wszystkim chyba raczej cały czas kojarzą się z czymś, co działa u Ciebie na komputerze. My pracujemy z agentami chmurowymi. Nie mówię tego z jakiegoś powodu, żeby się tutaj chwalić, ale wygląda mi na to, że to nie jest MX standard. Ten koncept takiego właśnie bytu wirtualnego gdzieś tam na CI-CD wcale standardem nie jest. Słyszymy, że firmy z tym eksperymentują, ale do tego się dopiero przyzwyczajamy. Więc wszystko się zaczyna od Twojej maszyny, takie shift left jakościowe można powiedzieć. Jak mamy zmiany na branczu, mamy zmiany na jakimś work tree, można sobie zapytać agenta, co Ty o tym myślisz, czy to jest ok, czy to nie jest ok. Można to najlepiej ustandaryzować właśnie w ramach zespołu. Jak to wychodzi, jak to już trafia na jakąś ścieżkę właśnie do CI-CD, mamy pull requesta, no to AI review. I tutaj znowu jakieś standardy, ustalenie tego definition of ready, albo definition of done w zasadzie. Znowu coś, o czym mówiliśmy i zaznaczyliśmy, jak wiele zespołów tak naprawdę nigdy nie usiadło i nie pogadało, co to znaczy, że jest PR gotowy do review. Albo co to znaczy, że PR jest gotowy do wyjścia na produkcję. Security review, jednego rodzaju audyty. Checki automatyczne blokujące, zarówno tak samo jak security review, jak i te checki dotyczące kodu, jakaś statyczna analiza. Tutaj również można w sposób deterministyczny po prostu określać te reguły przy pomocy jakiegoś configa, jakiejś ESLinty i tak dalej, i tak dalej. Ludzkie zatwierdzenie, czy też w ogóle takie zaangażowanie w zależności od ryzyka. Oceniamy sobie na bazie znowu jakiejś heurystyki właśnie, o jakiego rodzaju zmianie mówimy. Tutaj pewnie albo właśnie tą liczbę linii kodu można było wziąć pod uwagę, albo jakiś obszar, w którym ta zmiana jest. Serwisy, których ona dotyka i tak dalej, i tak dalej. Od 0 osób do jakiejś określonej liczby dla tych najcięższych zmian, najwyższego wpływu można powiedzieć na ten nasz projekt. I sam proces jakby wdrażania tego wszystkiego, łączenia tych zmian. To nie jest tak, że lecimy na proda. Anthropic tutaj mówi o bardzo dużym wykorzystywaniu feature flag, przełączników, które po prostu sterują dostępnością danej zmiany, danej funkcjonalności. I też takich kręgów powiedzmy adopcji. Najpierw użytkownicy wewnętrzni, potem kanał latest, czyli ci właśnie early adopterzy i na końcu kanał stable. W Chromie mamy na przykład jakieś canary, jakieś nightly buildy i tak dalej, i tak dalej. Więc naprawdę można czerpać z tak wielu powiedzmy tutaj obszarów tej inżynierii oprogramowania, że aż przyjemnie się o tym rozmawia.

To prawda i raz jeszcze podbiłbym ten element weryfikacji lokalnej, ale która też powinna być wykonywana w chmurze, polegająca na analizie statycznej kodu. Nie pytajmy agenta, czy to jest dobry kod. Nawet przekazując mu konkretne wskazówki, bo 99% z nich można zautomatyzować właśnie za pomocą wszelkiego rodzaju linterów, formaterów, naprawdę ESLint i tego typu rozwiązania. Mogą nam powiedzieć wszystko na temat tego, czy kod jest jakościowy poza naprawdę drobnymi wyjątkami. Jeżeli nasze review z agentem polega na tym, że przekazujemy mu słowno-muzycznie zasady z lintera i liczymy, że w ten sposób będziemy bezpieczni, to nie na tym polega.

To jest chyba szczególnie ważne, jak w ogóle nie miałeś jakiegokolwiek takiego mechanizmu kontroli. Pewnego rodzaju to jest pewnie ekstremum, o którym mówię. Takie przekoloryzowanie.

Albo i nie.

Ale mówię, że właśnie to wskakiwanie do AI od razu na tym obszarze jest super ryzykowne. Raczej to powinna być dostawka do tego, co działa. Jak ty nie masz nic i zaczynasz od takiego…

To jest piąty krok.

Tak, to jest piąty krok dosłownie. No i też znowu z mojego doświadczenia większość code review w przeszłości, w jakim ja brałem udział, to głównie był ludzki linter. A czemu skorzystałeś z var-a zamiast z consta?

Nitpick dwukropek.

Tak, a jeżeli w ogóle był ten nitpick dwukropek, daj Bóg. I na tym polegały te nasze genialne code review, które uprawialiśmy. I przez trzy dni dyskutowaliśmy o tym, czy ta klasa powinna się nazywać subscriber, observer, singleton, factory czy może kolejność tychże rzeczowników powinna być inna.

To również można utrwalić w linterze, jeżeli uznajemy to za istotne. Moim zdaniem to szczególnie istotne nie jest, ale tutaj też każdy może decydować, co by w swoim codebase’ie chciał, a czego by nie chciał.

Znaczy to się powinno na twojej maszynie świecić po prostu.

Tak.

To nie powinno być przedmiotem dyskusji w trakcie code review. Tak samo jak sobie myślę, zgodność chociażby z naszego świata webdevowego, zgodność z jakimiś API, przeglądarek i tak dalej. Są jakieś adaptery i tak dalej, czy lintery, czy nawet to, że to się po prostu przygotuje w odpowiedni sposób po buildzie już. Musimy to rozdzielać, musimy o tym pamiętać. Ostatnio miałem taki feedback interview 10xDevsów, gdzie właśnie jeden z naszych studentów mówił, że fajnie, że zwracacie uwagę na to, że jest cała masa narzędzi takich klasycznych, które się dopiero integruje z AI’em, a nie, że się zaczyna od AI’a, a to jest jakimś tam doklejką.

No tak i to jest znowu to takie doświadczenie, trochę świadomość tego, na czym ta praca inżyniera oprogramowania polega. I wbrew pozorom to też pokazuje, że my nie jesteśmy aż tak zachwyceni tym AI’em w takich obszarach akurat, w takim sensie dosłownym, żeby przełączyła się coś i tylko tym.

Ja w ogóle mam poczucie, że my jesteśmy wtedy zachwyceni AI’em. Wielu osobom się wydaje, że tak jest, a potem przychodzą do nas na szkolenia i my po prostu mówimy o tym, o czym mówiliśmy w szkoleniach jeszcze zanim AI zostało wprowadzone, tylko pokazujemy, no masz to, a teraz sobie jeszcze dołóż niesamowitą technologię, która daje ci dźwignię i ci się pozwala skupić na tych wszystkich istotnych rzeczach, które nie polegają na pisaniu kodziku, bo taką mamy gdzieś tam odważną ideę od lat siedmiu, ośmiu, że w tworzeniu technologii nigdy nie chodziło tak o pisaniu kodziku samego w sobie. Mamy tutaj w tej historii Anthropic jeden z takich przykładów a propos tego, jak łączą się dwaj agenci, jeden do tworzenia kodu, drugi do przeglądania kodu. Był tu jeden z fuck-upów, o których też możemy powiedzieć, Marcin. Jak to było z tymi nocnymi rundami tego całego review, gdzie tam się agenci zapętlili?

No to właśnie na to trzeba uważać, kiedy tworzymy wszelkiego rodzaju pararodziny agentów, jak ja to lubię mówić, gdzieś tam którzy ze sobą rozmawiają.

To już klasyk, pararodziny agentów.

Trzeba nie liczyć się z tym, że taka pararodzina może wejść w bliższą relację i bardzo długo ze sobą konwersować, niespecjalnie wnosząc cokolwiek do naszej firmy poza rosnącym rachunkiem z API. Więc tutaj w Anthropic też takie sytuacje były, że mieliśmy dwójkę agentów, jeden weryfikował, drugi recenzował i to trwało bardzo długo, przez całą noc.

50 rund.

50 rund, no ogrom, tak więc warto też… Jeżeli tworzymy tego typu rozwiązania, one mogą mieć sens jak najbardziej, chociaż zachęcamy do jak najprostszych rozwiązań na start, a potem komplikowania, jeżeli to proste rozwiązanie nie radzi sobie tak, jak byśmy chcieli. Więc blokujmy ilość tych tur, jakie mogą się wydarzyć pomiędzy tymi agentami. Tu na przykład była sugestia, że 3 tury, jeżeli do niczego ci agenci nie dojdą w tym czasie, no to człowiek tutaj wkracza do gry.

Mi tutaj się wydaje nawet, że warto też rozróżnić taki klasyczny workflow agentowy, gdzie coś w pętli działa, od klasycznego nawet prompta, którego do API wysyłamy. Bo można sobie wyobrazić raczej na code review, że mamy prompta z jakimś system instruction, znamy tego diffa, dostajemy odpowiedź i na tym to by się mogło skończyć. To wcale nie musi być pętla, że w nieskończoność mi tutaj naprawię. Może być inny case dla agenta pod tytułem, doprowadź mi to do zielonego, że tak powiem, ale to znowu są dwie inne kwestie.

Tak, co akurat w tym paternie pararodziny jest istotne i ważne, to rozdzielanie kontekstu pomiędzy agentem, który coś weryfikuje, a tym, który coś poprawia. Bo jeżeli agent będzie robił jedno i drugie, no to siłą rzeczy dostrzeże najpewniej mniej problemów w swojej pracy. Więc tutaj akurat to jest im plus, dlatego warto z tym eksperymentować. Tylko znowu zaczynajmy od najprostszych rozwiązań. Kiedy po pierwszych pół godziny pracy widzisz 30-elementowy graf swojego systemu, można poczuć się z tym fajnie i bardzo profesjonalnie, aczkolwiek może to też prowadzić do wysokich kosztów, złożoności i nie do końca do realizowania celów, o które nam chodzi.

Znowu jest taki efekt, że w tych grafach te firmy, które na przykład sobie rozkładają zależności między serwisami w sposób świadomy, do jakichś testów kontraktowych i tak dalej, mają zajebistą dźwignię, ten eks, a firmy, które to robią, żeby właśnie screen na LinkedIn wrzucić, czy osoby, które to robią, żeby screen na LinkedIn wrzucić, no znowu robią ten teatr po prostu.

Tak, no to trzeba sobie gdzieś tam postawić jasno cele. Oczywiście różne jednostki mają różne cele. Pamiętajmy o tym, że jeżeli jesteśmy w firmie, w zespole, to naszym celem jest efektywny proces SDLC, a nie do końca, żeby coś wyglądało fajnie i można było się tym chwalić na spotkaniach, na social media.

Powiem jeszcze o tych efektach w Claude Code, o co się właściwie zmieniło. Po tym, jak oni stopniowo usprawniali ten proces, no to te odrzucane PR-y, które w ogóle nie były gotowe, żeby wejść na produkcję i tylko traciliśmy na to czas, ich odsetek spadł o 40%. No więc super, 40% niepotrzebnych PR-ów, których nikt nie musi sprawdzać, bo odpadają wcześniej za pomocą wszelkiego rodzaju automatów. No ekstra, nie? Tego byśmy chcieli. Tak, świetna sprawa. Odsetek wewnętrznych PR-ów z merytorycznymi komentarzami wzrósł z 16 do 54%. Też super, nie? Bardziej świadoma komunikacja, też to dzielenie się wiedzą. Tutaj Boris Cherny, też twórca Claude Code’a mówi, że jak Claude ma sprawdzić swoją pracę, przy założeniu oczywiście, że to jest taki pipeline zrobiony dobrze, no to wynik jest 2-3 razy lepszy względem pewnie, albo takiego ludzkiego szybkiego review, przy takiej objętości tych zmian, o których mówimy, albo przy tym, kiedy to robimy niestarannie.

Tak, to też jest coś, co coraz częściej jest powtarzane, że ta automatyczna weryfikacja jest bardzo ważna, no podpisuje się pod tym. Agent, tak samo jak człowiek, potrzebuje pensji zwrotnej. My często korzystaliśmy z testów manualnych, bądź też z naszego doświadczenia intuicji. Agent jednego i drugiego nie posiada, no trzeba dać mu inne sposoby, a jest ich naprawdę dużo. Te narzędzia do automatycznej weryfikacji się fajnie rozwijają w ostatnim czasie.

No dobra, no to mamy zmianę, czasami small change, czasami wcale nie. Mamy usprawniony proces code review, mamy dodatkowe integracje, wychodzimy na proda. Trafia to do tej docelowej grupy użytkowników, ale coś może pójść nie tak, jak to zwykle bywa.

Zawsze idzie prędzej czy później.

Prędzej czy później coś idzie nie tak, więc chcemy teraz przejść do tematu pożarów i tego jak te pożary gasić w czasach agentów. Tutaj dosłownie wczoraj 27 października pojawił się na blogu Pragmatic Engineer Gergely’ego Orosza bardzo ciekawy artykuł o AI SRE, który tu pokazuje, że znowu jest troszkę inny aspekt tego, gdzie tych agentów integrować. Już nie mówimy o zmianach, o tym momencie, kiedy coś trafia na produkcję, tylko mówimy o sytuacji, kiedy już coś jest na produkcji i zaczyna się palić. Wiadomo, że kiedy ten pożar gasiliśmy tylko w zależności od dostępności ludzi, no to różnie z tym bywało. Tempo, sprawność tego procesu, gdzieś tam powielanie tych samych błędów, to czy my na pewno adresujemy jakieś źródko, czy adresujemy jakiś taki powiedzmy objaw tymczasowy, imprezy, choroby, urlopy. No myślę, że jest sporo takich sytuacji, gdzie to ASRE naprawdę było poddawane próbom, w ogóle też taki koncept w ogóle bus-factora, ile jest osób, które wiedzą jak naprawić dany obszar, czy dany model, czy dany serwis. No naprawdę sprawa dużego ryzyka, bezpośrednio wpływająca na użytkowników końcowych i też na produkcję. Trzeba by się tym zająć. No i właśnie tutaj na blogu Pragmatic Engineer kilka takich pomysłów, o których zaraz pogadamy. Na początku takie spostrzeżenie, że liczba incydentów, które potencjalnie mogą się pojawić w twoim systemie, no wynika z dwóch składowych. Po pierwsze samo tempo zmian, więc jak przyspieszamy to ich się pojawi więcej, ale też mnożone przez prawdopodobieństwo, że pojedyncza zmiana coś zepsuje. No i teraz w zależności od tego jak ty masz sprawny ten system i odporny na zmiany, no to albo to tempo, kurczę, jest małym problemem, średnim albo dużym, albo może nie być, chociaż to, że nie jest w ogóle problemem, to pewnie nie występuje.

Siłą rzeczy jest to element tego równania, więc trzeba liczyć się z tym, że jeżeli więcej dowozimy na produkcję, to najprawdopodobniej będziemy mieli większą liczbę incydentów. W jakim stopniu ta liczba wzrośnie, no to oczywiście już zależy od wielu innych czynników, które są ukryte, bo to jest dość proste równanie, ale bardzo trafne. Znowu mamy, powiedzmy, przez to, że jest więcej incydentów. No są różne raporty, które to udowadniają. Jest to swego rodzaju prawo inżynierii oprogramowania.

To jest ogólnie truizm, że jak dowozimy tak dużo na proda, to więcej mamy alerty. To jest tak, jak dowozisz więcej, to masz więcej linii kodu na produkcję. Dzięki za informację. Zwykle znowu, żeby mi ktoś nie wyciągnął życzeń zmian, usuwa linijki kodu, ale pozdrawiamy wtedy za taką obserwację.

Dokładnie tak. Słuchajcie, kto kiedyś konfigurował alerting w starych dobrych czasach, to wie, że to jest wybitnie trudne. Ciężko mieć alerty automatyczne, które dają nam sam sygnał bez szumu. Siłą rzeczy albo mamy tych alertów za mało, albo za dużo i w większości firm i tak o tym, że jest realna awaria, często dowiadywaliśmy się niestety od klientów albo od naszego dyrektora, który dzwonił do nas o 3 w nocy, że produkcja się pali. Tutaj pewnie znowu pojawią się ludzie z tych tak zwanych jednorożców, chociaż nie mówię tu o wycenie, tylko tych wybitnych firm, gdzie nigdy tak nie było. Ja nie miałem przywileju pracowania w takiej firmie i też nie słyszałem o takiej z pierwszej ręki, aczkolwiek niewątpliwie jest ich od groma, tylko my coś tam mówimy, że to takie trudne.

Chociaż wydaje mi się, że akurat wśród naszych programistów, wśród naszej branży, zgodność co do tego, że bugi na produkcji są jest raczej wysoka. Tutaj akurat o tym się trochę łatwiej rozmawia, bo wiemy, że się coś spieprzy.

To prawda, to prawda. No i bardzo ciężko gdzieś tam dowiadywać się o tym bardzo szybko. To jest po prostu trudne, ale wydaje mi się, że w tych czasach agentów to jest duży potencjał w tym, żeby dowiadywać się szybciej, nie od klientów, no bo jest to system inteligentniejszy niż jakieś IFS-y, na których tak naprawdę te alerty automatyczne do tej pory polegały. No i teraz Przemek, jak to można obecnie robić? Jak się do tego podchodzi?

Możemy do tego podchodzić dając dostęp agentom do wszelkiego rodzaju tooli observability. Mamy np. Sentry, mamy Cloudflare, wszelkiego rodzaju rozwiązania, gdzie logujemy błędy, obserwujemy ruch, no i tworzyć bardziej elastyczne heurystyki, które będą nam mówiły, kurczę, no tutaj zaczęło rzucać pięćsetkami. No ale może to, że mamy 10 pięćsetek przez dwie minuty, to jeszcze nie jest powód, nie? Niech on zobaczy w te logi Sentry, czy faktycznie rzuca czymś istotnym, czy tutaj faktycznie coś się dzieje. Więc mamy dużo więcej możliwości łączenia różnych źródeł informacji i też wyciągania wniosków w taki sposób dynamiczny. Znowu, skonfigurowanie tego w sposób niezawodny jest bardzo trudne, aczkolwiek jest to duży potencjał. Obecnie w naszych systemach też z tym eksperymentujemy. Daje to różne rezultaty, raz lepsze, raz gorsze, ale jako osoba, która gdzieś tam siedziała w Grafanie, w Kibanie, no to nie jest to jakiś, wydaje mi się, ulubiony experience większości programistów, no to tutaj czuję dużo złota, które jest do wykopania.

Ja bym to odwrócił z punktu widzenia jakiejś takiej motywacji, tego czemu tym się w ogóle zajmować. No nie chcesz mieć niespodzianek, nie chcesz jakby tracić reputacji, chcesz szybciej reagować, reagować w sposób automatyczny, ale nie z twojej wygody, po prostu chcesz tą jakość w taki sposób realizować. No i nie o trzeciej w nocy, jak gdzieś tam śpimy, tylko lepiej się o tym dowiedzieć w ciągu dnia, mając lepszy wgląd w to, jak te zmiany, które tak coraz liczniej wprowadzamy na produkcję, wpływają na system, żeby móc je szybko wycofać, skorygować i móc ze spokojem zamykać rooftop’a po tej 16, 17.

No dokładnie. Mamy tutaj taką oś czasu, która pojawia się właśnie w kontekście przykładowego tutaj wendora Resolve AI, który przebudował taką architekturę, o której my rozmawiamy, architekturę do powiadomień, do obsługi tego reliability. W 2024 roku jeszcze właśnie… jest skryptowany workflow pełen tych if-else’ów, o których Ty mówiłeś. Jak mieliśmy tylko delikatną niezgodność do scenariuszy, to oczywiście były przecieki. W 2025 roku jeden agent z grafem wiedzy, gubienie się w długim kontekście, rozumienie intencji, też tak naprawdę właśnie interpretowanie tych różnych wskazówek. W 2026 roku taka para-rodzina, ale para-rodzina, która już gdzieś tam opiera się o stabilniejsze fundamenty. Różne role agentów, współpraca tych agentów. Myślę, że w ogóle w 2027 i 2028 roku też tutaj przyniosą upgrade’y, bo to jest jakaś tam podróż. Nie mówimy o takim stanie końcowym, że zrobisz i zapominasz. Tylko po prostu nadajesz sobie taki North Star, idziesz w tym kierunku i odkrywasz te kolejne czaptery w tej całej podróży.

Tak, i teraz agenci po pierwsze mają wystarczające możliwości na poziomie zdolności do zoomowania, szybkości, jak i dostępu do wszelkiego rodzaju usług. Już wszyscy prowiderzy tych topowych tooli observability, alertingu mają swoje CLI, mają swoje API, mają swoje MCP, do których możemy tych agentów podpiąć. Takim fajnym patternem właśnie tego, jak można rozłożyć te akcenty, tworząc nasz tooling do alertingu w oparciu o agentów, to jest ten podział na tego, który obserwuje, patrzy czy coś się dzieje. Ten, który odpowiada za komunikację z kanałami, na które gdzieś tam patrzą deweloperzy, czy jest to Slack, czy wszelkie inne rozwiązania. Routing. Routing, dokładnie. No i też weryfikator, który upewni się, że faktycznie mamy problem, zanim ta wiadomość zostanie wysłana. To oczywiście jest jeden z wielu sposobów. Warto tutaj eksperymentować. To jest fajny punkt wyjścia. Jeszcze pewnie w najbliższych latach, tak jak powiedziałeś, dużo w tym obszarze zostanie odkryte.

Gdybyś miał powiedzieć o takiej jednej akcji, którą można wykonać, żeby ten 5% improvement w swoim systemie zrobić, właśnie na bazie tego, co na przykład robiłeś w naszej platformie, bo tutaj dla wszystkich, którzy nas słuchają, to nie było tak, że Marcin gdzieś tam zniknął na 4 tygodnie i nie było go i powiedział, idę robić observability, żeby te rzeczy się działy, pracowaliśmy nad 10xami, robimy support, robimy podcast, content, dzielimy się tą wiedzą. Zniknąłeś na półtora dnia, pojawiły się te informacje na Slacku, ale jakbyś miał sobie zrobić takie retro, powiedzmy just in time, to od czego by tutaj zacząć twoim zadaniem?

Przede wszystkim patrzyłem na to, co nie wychodziło w przeszłości, gdzie mieliśmy najczęściej wpadki, gdzie pojawiały się problemy, jakie zmiany często wywołują problem, jakie mamy kanały informacji, czy tam te informacje są właściwie zbierane. Zwykle nie są, zwykle te nasze toole takie jak Sentry nie są tak dobrze dostrojone. Możemy wspólnie z agentem to poprawić, wykryć dziury, jakie mamy. Bardzo teraz sprawnie można to robić. Więc pierwszy wykonałbym audyt systemu, czy my realnie zbieramy dostateczną ilość właściwych informacji. No i też na retro, gdzie my mieliśmy te pobudki o 3 w nocy i jak możemy im zapobiec.

No 100%, myślę, że właśnie sam Slack czy tego typu komunikatory też są tutaj fajne pod kątem tego reagowania, bo tam masz całe API do akcji, przyciski, możesz tam znowu podpinać jakiegoś rodzaju hooky po drugiej stronie, które reagują. Więc też ten developer experience jest naprawdę fajny i przyjazny. Myślę, że sporo osób, które budowały jakieś automatyzacje w oparciu o Slacka zna ten koncept właśnie tych interaktywnych wiadomości. Dla osób, które nie znają, ogólnie chodzi o to, że to nie jest tak, że na przykład dzisiaj na Slacku już dostajesz jakiś alert typu SMS i musisz dopiero zaczynać pracę. Nie, możesz tam mieć na przykład przyciski ABC, zignoruj, podejmij akcję automatyczną albo zaraportuj itd. I też już to wdrażałeś.

Tak, bardzo łatwo coś takiego dodać na poziomie pipeline’u. Slack ma do tego gotowe API. Nie wiem jak jest w Teamsach, jeżeli z niego korzystacie, to współczuję. Być może coś takiego również tam działa. Warto się zainteresować, czy jest.

Tak, dokładnie. Na Discordzie również te ich integracje są bardzo dobre.

Tak, Discord jest na pewno, przoduje w tych automatyzacjach.

Tak, więc tam też można jeszcze więcej rzeczy sobie skonfigurować niż w przypadku Slacka.

Słuchajcie, może przejdziemy teraz do ostatniego tematu tego odcinka, czyli jak to wszystko jeszcze dostosować do struktury zespołu, bo to również budzi wiele wątpliwości i obecny stan rzeczy generuje problemy. Przemek, jak możemy ten temat otworzyć?

No, do pizzerii musimy gdzieś tam zawitać. Musimy się udać do pizzerii. Musimy się zastanowić ile pizz gdzieś tam nakupować, żeby wystarczyło takiej liczby osób, która ma się zajmować rzeczami. Znowu trochę tła. Mnie w ogóle tym tematem zainteresował jeden z uczestników właśnie 10xDevs, który to zadał nam takie pytanie na naszych godzinach trenerskich, czyli takich piątkowych sesjach, gdzie rozmawiamy o praktyce, który to zapytał o konflikty przy merge’ach. Konflikty, które pojawiają się w momencie, kiedy każdy dostaje dostęp do AI, pracujemy gęsto, blisko siebie w ramach projektu i każdy odpala już nawet nie jednego agenta, tylko hordy swoich agentów. Jak to fajnie nazwałeś na swoim LinkedInie, ja zrobię przycisk, a ty API i TS, a tam ja border radius, a ty color.

Tak, tak, tak, lecimy tutaj.

Lecimy tutaj. No i ogólnie to za bardzo już nie są te czasy, żeby można było w ten sposób pracować. No więc ogólnie sporo firm, które podchodzą do tematu jakiejś takiej organizacji zespołu w sposób świadomy i tego wdrażania agentów, rozkminia problem takiego optymalnego kształtu zespołu. Mieliśmy Jeffa Bezosa, który kilka dobrych lat temu mówił, że tak naprawdę powinniśmy mieć zespoły, które wykarmimy dwoma pizzami, czyli gdzieś 6, 10, 12 osób, bo to był taki odpowiedni balans między sprawczością, a można powiedzieć autonomią tym, żebyśmy mieli wszystkie role na pokładzie, żeby nie było dependencji w ramach innych tutaj unitów w naszej organizacji. No i tylko, kurczę, problem w tym, że te 6 do 10 do 12 osób to jest troszkę dużo na te dzisiejsze warunki. Patrząc na to jak zwykle wygląda, nie wiem, utrzymanie albo rozwój jakichś serwisów, czy też produktów w firmach, no ogólnie wydaje się, że raczej pracujemy za gęsto. Jesteśmy ustawieni za gęsto, nie?

Na poziomie, na poziomie codebase’u. Między nami to dobrze widać, bo można powiedzieć, że każdy z nas mógłby być ownerem całej platformy w pewnym sensie, która się rozwija. Jakoś naturalnie to wyszło tak, że na przykład ty wziąłeś ta część user-facing, ja na przykład CMS-a wziąłem całego i ty do tego CMS-a wchodzisz bardziej read-only, a ja read-only wchodzę do lekcji i tam do uwierzytelniania i tak dalej, i tak dalej. No gdybyśmy pracowali na poziomie jednego przycisku, to byłby tutaj problem.

No więc właśnie mniej więcej od tego roku można, można powiedzieć tutaj Dan Shipper z Every pierwsze to wrzucił na bazie naszego research’u. Od początku roku gdzieś tam eksperymentuje się z takim konceptem już nie two pizza teams, czyli te 60 osób, a raczej two slice teams, czyli na przykład dwie osoby do jakiegoś serwisu, może nawet jedna osoba do jakiegoś mini-produktu, który tutaj rozwijamy, które to właśnie odpalają tych swoich agentów i nagle się skalują, ta ich sprawczość się skaluje. Więc pojawiają się takie zespoły, które w dawnym świecie nie przypominają zespołów, a w nowym świecie są nadal sprawcze, unikają takich często występujących konfliktów, no ale jednak przesuwają ten ciężar pracy na agentów. W polskim ogródku choćby Maciej Mendrela i krakowski edrone z tym eksperymentuje. Maciek ma też bardzo fajne podejście do tej integracji z AI, takie forward thinking, oni się tam w edronie nie boją zmian. Na live’ie z chłopakami z AI Product Heroes była o tym rozmowa, możecie sobie to na YouTube zobaczyć. No więc ogólnie pojawia się to wyzwanie dotyczące właśnie kształtu zespołu, tego jak pracować, w jakim kształcie, żeby te zmiany agentów na siebie nie nachodziły i tendencja jest taka, że raczej to będą teamy mniejsze niż większe. Widzisz tutaj jakieś konsekwencje może negatywne z punktu widzenia dewelopera, który coś takiego słyszy, jakbyśmy sobie tak pogrillowali troszkę?

Na pewno może budzić tę obawę, że jeżeli teamy będą mniejsze, no to w ogóle będzie mniej osób w firmie. Tylko to znowu jest myślenie w oparciu o korelację, o nieprzyczynowość. Mówiłeś o tym ostatnio, jak to z tą pracą może być.

Tak, może być tej pracy tyle samo albo i więcej. Mówimy o strukturze zespołów, czyli jeżeli teraz mamy zespół sześćosobowy, to po prostu rozbijamy go na przykład na trzy zespoły dwuosobowe, gdzie każdy zyskuje ownership pełen może jednego modułu z tych trzech. Wiadomo, to jest taki wygodny podział, który do tej pory zespół obsługiwał. I ten mały zespół jest dużo bardziej wtłorzony w tą jedną konkretną aplikację, a nie gdzieś tam ma uwagę rozmytą na trzy różne, gdzie mamy ogrom PR-ów, już w ogóle nie jesteśmy w stanie nad tym wszystkim zapanować. Więc zawężamy trochę tą naszą koncentrację i w zamian za to oczywiście bierzemy pełną odpowiedzialność za to, co się w danym module dzieje.

Ja się zastanawiam, jak dwie rzeczy zrekompensujemy. Taki well-being osobisty, bo nie jest to wcale oczywiste dla mnie.

No dla mnie również.

To jest właśnie ten ciężar, który masz na barkach. Bo jednak jego będzie więcej. I teraz pytanko, jak z tym dealować? Przepraszam, Ty byłeś menadżerem, więc też masz to jakieś doświadczenie. Wypowiedz się, pewnie i w jednym, drugim zakresie będziesz w stanie coś powiedzieć.

Wydaje mi się, że to jest kwestia jednak charakterologiczna i trudno tutaj o uogólnienie. Ja byłem raczej takim gościem, który lubił dowozić i mieć tą przestrzeń. Okazji na integrowanie się z ludźmi szukałem poza tym, co robię. To nie był dla mnie tool albo cel sam w sobie.

To ja znowu mam inaczej, o czym wiemy. Gdzie ja sobie cenię tą współpracę. I to jest dla mnie ważny element. Bardzo bym nie chciał być na stałe w teamie jednoosobowym. To jest mega trudne ogólnie, longtermowo, żeby w firmie 4 lata tak przepracować. Ja bym skończył w jakimś miejscu, które nie wiązałoby się z uśmiechem na twarzy. Dla mnie, im więcej, tym lepiej tak naprawdę ludzi z którymi mam bieżący i stały kontakt, więc trzeba się z tym liczyć. Myślę, że tutaj na pewno waga takich eventów jak jakieś brown bagi, demo, takie eventy scalające zespoły rosną na wartości. Waga tego wszystkiego rośnie, bo musimy mieć jednak tę przestrzeń, żeby gadać o tym co się dzieje. Ja też z doświadczenia, jak nie zamkniesz tych klapek od laptopu wszystkim ludziom w zespole i powiesz słuchajcie idziemy teraz sobie pogadać, a nie każdy patrzy tutaj w swojego agenta, to to się nie wydarzy. Nawet to, że będziesz miał jakieś description na pull request i to będziemy ogólnie nazywać tym dzieleniem się wiedzą, to pewnie nie spełnia tak do końca swojej roli. Wydaje mi się, że naprawdę trzeba usiąść, mieć ten space, żeby gadać. Tutaj właśnie bardzo fajnie to w Pragmatic Coders wygląda. Miałem z Wiktorem Żołnowskim dyskusję na 10xDevsach. On tam powiedział, że właśnie planowanie sprintu czy planowanie tygodnia to jest taki event zespołowy, który do roli takiej świętości urasta trochę. Wyłączamy tych agentów i gadamy o tym co my w ogóle chcemy robić. Wydaje mi się, że to będzie jakoś kompensować to co się będzie działo w takiej codziennej pracy. Wydaje mi się to kluczowe.

Tutaj też fajnym przykładem tego jak to można robić nawet w bardzo dużej firmie jest to o czym opowiadał Josh Woodward, VP Google Labs, którego miałem okazję przynajmniej przyrodnie poznać na Google.

Nasz kolega, twój kolega.

To daleko idące stwierdzenie. Aczkolwiek byliśmy kilka razy w tym samym pokoju na przestrzeni trzech dni.

Demis Hassabis, też twój znajomy.

Również, również. Gdzieś tam mogę powiedzieć to samo. Ale co jest ciekawe w Joshu, bardzo pozytywna energia od niego bije. Bardzo taki energetyczny człowiek. Widać, że ma dużo zajawki. Mimo tak wysokiego stanowiska w tak dużej firmie. No i on głęboko wierzy w to, że takie małe autonomiczne zespoły, które mają pełen ownership, mogą robić super rzeczy. Opowiadał też o tym w podcaście Lenny’ego Rachitsky’ego. Mam nadzieję, że tutaj nie przekręciłem za mocno tego nazwiska.

Lenny’s Podcast.

I w tym oto podcaście on mówił o kulisach powstawania NotebookLM. Czyli jednego z takich większych sukcesów Google w dobie AI. I to również wyszło od zespołu, który nie miał w ogóle zadań na stwórzcie coś takiego. Tylko eksperymentujcie z AI. I z tym jak AI można wykorzystać do efektywnej nauki, która będzie angażująca, ciekawa. No i były te słynne podcasty, które dwa lata temu zrobiły niesamowitą furorę.

Podcast Overview.

Tak, dokładnie. No i to też po prostu jego pracownicy stworzyli coś takiego. Dwójka z nich. I musisz tego posłuchać. Zobaczysz, czy ci się spodoba. I on był totalnie zachwycony tym, co zobaczył.

I oni też, nie?

I oni też. To była ta motywacja. Ale właśnie dzięki temu, że to nie był 12-osobowy zespół z trzema gdzieś tam jeszcze warstwami menadżerskimi. Tylko ludzie, którzy się mega znają na swojej robocie, mają dużo przestrzeni. I dzięki temu mogą robić niesamowite rzeczy. Więc to jest ten taki plus. Dlaczego ta duża autonomia, onowanie rzeczy w 100% i dowożenie jako mały, zwinny zespół może dawać naprawdę fajne rezultaty w dzisiejszych czasach.

No o tym nie mniej wydaje mi się, że gdzieś musi być ta kompensacja tego teamworku. Ten team building. On tam też właśnie mówi, że cały czas rozkminiają na przykład w Google czy nie grupować tych zespołów w jakieś takie klastry. Mimo tego, że każdy jest tym właśnie dwuosobowym teamem albo stajemy się tymi dwuosobowymi teamami, wchodzimy w skład, to czy jednak w tych szóstkach gdzieś tam nie wyskakiwać na te śniadania. To już ja tak trochę dopowiadam. Czy nie mieć właśnie jednego eventu więcej, żeby sobie o czymś pogadać. Zastanawiam się cały czas jak to będzie z tą presją. Ostatnio słuchałem podcastu tutaj może bez nazwisk osoby, która jest uznawana za autorytet i która moim zdaniem się bardzo myli twierdząc, że to LLM przejmie presję i to, że ten stres, to obciążenie będzie na LLM, bo robi brudną robocę. Wydaje mi się, że ten ownership jednak spłynie na człowieka. I już to czujemy po prostu. I tak się zastanawiam, coś co mi tutaj w głowie mignęło na przykład takie odcięcie dostępu do agenta o 18.

O 16.01. Nie wiem co to za podcast, albo być może nie wiem do kogo się odpowiadasz. Dla mnie to jest straszny bullshit.

Jak ci powiem nazwisko po nagraniu, to będzie zaskoczony kto tak powiedział.

Myślisz, że będę zaskoczony? A może nie będę?

Nie, myślę, że będziesz.

A, okej, okej. No dobra. Do LLM’a nikt o 3 w nocy nie będzie dzwonił, jak system przestanie działać. To są takie relacje, które pokazują, że raczej ktoś ma interes w tym, żeby mówić w taki sposób. Albo jest daleko od takiej cyfrowej relacji. Albo nie do końca sobie zdaje sprawę jak wygląda codzienna praca inżyniera. To mnie osobiście triggeruje. Ja też lubię mówić i pisać triggerujące rzeczy.

To jest ten drugi scenariusz. Ktoś kto był autorytetem, ale teraz trochę dalej od codzienności i osoba zza ocen.

Dobra. Ja sobie zdaję sprawę, że czasami mogę pisać albo mówić triggerujące rzeczy. Aczkolwiek staram się to robić mimo wszystko w sposób empatyczny, żeby bardziej otwierać ludziom głowę i pomagać gdzieś tam spojrzeć szerzej na rzeczy.

W sensie takie spłycenie.

Tak, tak, tak. Bo często mi się to zarzuca, a to moim zdaniem jest takie oczywiste spłycenie. Więc tutaj minus, minus jeden za tego typu tejki. Tak więc dużo się kurczę dzieje w tym świecie programowania za sprawą AI. Myślę, że możemy powoli zmierzać do brzegu. Te najważniejsze tematy poruszyliśmy. Jaki jest wniosek albo wnioski końcowe z tej rozmowy? Warto wyciągnąć swoje zdanie.

Moim zdaniem pierwsza sprawa jest taka, że starego świata nie ma. Pytanie tylko, czy ty się już z tym zgadzasz, czy to czujesz, czy jeszcze nie.

Oczywiście wydaje mi się, że każdy to czuje. Wiele osób na te emocje, które odczuwa, różnie reaguje. Takie wyparcie, zaprzeczenie jest dość częstą reakcją na dużą, niewygodną zmianę. Zwłaszcza jeżeli mamy też obawy, czy aby na pewno nie podcinamy sobie gałęzi, na której siedzimy, jak to wiele osób mówi. Ja to rozumiem.

Jasne.

To jest racjonalne podejście. Wydaje mi się, że antyproduktywne na dłuższą metę, bo z biegiem historii jeszcze nikt nie wygrał i z postępem technologicznym. Dla mnie rozsądniej jest wpływać na to, w jakim kierunku to idzie i jak najlepiej ustawiać się w odniesieniu do tego, co się faktycznie zmienia.

Druga taka rzecz to jest na pewno audyt tego, jak robimy rzeczy. I takie uświadomienie sobie mamy tego mema Talk to your agent. Uświadomienie sobie tego, że jak włączasz generowanie kodu AI-owe, to wszystko inne też w jakiś sposób z AI musi być połączone. Po prostu nie ma bata, że w jednym obszarze to włączysz, a reszta procesu się utrzyma, bo po prostu to się rozwali.

To prawda. I pamiętajmy też o tym, że LLM to nie jest wyłącznie maszynka do generowania kodu. Ma również możliwości różne analityczne, z których możemy korzystać właśnie, żeby lepiej zrozumieć tego, jak robimy rzeczy i co możemy poprawić. Tak więc pamiętajmy o tym, że to nie jest tylko maszynka do produkowania feature’ów, ale też coś, co może nam pomóc przeanalizować nasz proces code review, jak my to robiliśmy, czy to był taki genialny proces, a może robiliśmy nitpicky dotyczące tak naprawdę nieistotnych rzeczy i musimy wykonać dużo więcej pracy niż byśmy chcieli, a przed nią uciekaliśmy przez długo, długo.

No i chyba trzeci taki outcome, trzeci taki wniosek z tego wszystkiego, to naprawdę nie ma starego świata, ale też świętości nie ma. Trzeba challenge’ować tak naprawdę wszystko, co się dzieje i tak naprawdę jak się problem pojawia, to paradoksalnie jesteś w tej sytuacji, żeby jak najbardziej korzystnie się w całej organizacji ustawić, bo czujesz ten problem, możesz podjąć decyzję, czy to należy rozwiązać LLM, czy nie należy, ale sam fakt, że zauważyłeś, że gdzieś tam coś w szwach pęka, to to jest fajny początek nowej roadmap’y na przykład.

100%. Tutaj, żeby też nie podchodzić w sposób taki prosto inny do tego, co powiedziałeś, wydaje mi się, że świętości jakieś są i ty też na pewno to uznajesz, czyli chodzi o to, żeby użytkownik był zadowolony.

O to, żeby ludzie się w pracy dobrze czuli.

Żeby ludzie się w pracy dobrze czuli, żeby firma cały czas dobrze prosperowała. To są świętości. O to zawsze w naszej pracy programistycznej chodziło. I wszystko inne tak naprawdę już powinno być wynikową tych rzeczy, które mogą się zmieniać na poziomie procesów naszego podejścia wraz z rozwojem różnych technologii. Tą wiodącą obecnie są agenci AI i tak powiedzmy cały świat się ustawia do tego. To, jak robiliśmy rzeczy przez ostatnie 10, 15, 20, 30 lat, żadną świętością samym w sobie nie jest. Często jest wynikową tego, do czego się dostosowaliśmy. Kiedyś ustawialiśmy do tego, że mamy mało programistów, którzy wolno piszą kod. No to teraz mamy trochę więcej programistów, bo też jakby ich liczebność wzrosła. Plus jeszcze pisanie kodu przestało być wąskim gardłem samo w sobie i z tego powodu wiele się musi zmienić.

Bardzo wartościowe rozplątanie tego mojego uproszczenia. Tutaj plus jeden, plus jeden dla Ciebie. Słuchajcie, na tym kończymy ten dzisiejszy odcinek. Jak widzicie, to jest w ogóle odcinek szczególny, bo w zupełnie nowych warunkach go nagrywamy. Chcemy zainwestować więcej w ten podcast. Chcemy, żeby tutaj jakość szła w górę, więc nagrywamy to w Katowicach, w studiu Daj Głos. Mamy nadzieję, że taki format Wam się spodoba. Zachęcamy do obserwowania, dzielenia się z innymi, klikania w pięć gwiazdek na danej platformie, na której akurat tego podcastu słuchacie i też zachęcamy do tego, żeby subskrybować newsletter Opanuj.AI co poniedziałek, takie trzy ręcznie wyselekcjonowane materiały na temat sztucznych. inteligencji i uczenia maszynowego, które cały czas wybieramy dla Was my. Są związane z odcinkami, z tym co robimy w ramach Przeprogramowanych 10xDevs. Jest to taki suplement, dodatek do tego o czym tu słyszycie.

Dokładnie tak, teraz też będziemy pewnie więcej inwestowali w YouTube’a. Byliśmy mocno nastawieni na Spotify do tej pory, więc jeżeli słuchacie nas na YouTube’ie na co mamy nadzieję to zostawcie subskrypcję, zostawcie przycisk like, podbijcie ten podcast tak żebyśmy mogli szerzej trafić do odbiorców zainteresowanych merytoryczną rozmową o agentach, programowaniu. Zapraszamy na kolejny odcinek, który najpewniej pojawi się szybciej niż za miesiąc. Spoiler. Będzie tutaj zejście bardziej w tematy techniczne jeszcze. Dzisiaj może było troszeczkę wysokopoziomowo, chociaż i tak wydaje mi się, że nie było lania wody, ale będzie jeszcze więcej kodu i może tak będzie bardziej na drugą nóżkę. Dzisiaj trochę mówiliśmy o AI w samych superlatywach, że to wszystko jest ekstra i zmieniajmy procesy, a będzie bardziej o tym na co uważać, że to wszystko nie jest takie proste, jakby mogło się wydawać. Też wiele razy mówiliśmy, wyśmiewaliśmy takie tejki, że AI można się nauczyć w jeden dzień. No to będzie cały odcinek o tym, że nie można, więc zachęcamy do odsłuchu. Dzięki, że byliście z nami. Zapraszamy do kolejnego odcinka.

Jak Pracują Zespoły AI-Native | Opanuj AI

Transkrypcja odcinka

Materiały źródłowe

Newsletter Opanuj AI