“Jeżeli chodzi o architekturę, nie pozwalam mu podejmować żadnych decyzji.” 🎯 Łukasz stawia granicę, a Szymon kontruje: “pozwólmy tym agentom robić ten kod, który jest krótkowzroczny” - i raz na pięć iteracji każmy zrobić refactor. Przechodzimy SDLC z AI fazę po fazie, od zbierania wymagań do życia po deployu.
Na wejściu AI tylko wspomaga - “nie pójdzie do legala, do procurementu” i nie odsiedzi dupogodzin na spotkaniach. Dalej: linki do chatów od biznesu zamiast przepakowanych wymagań, powrót Enterprise Architecta i YAML jako formalny output specyfikacji. Plus prototypy klikane przez biznes, których nie negujesz - ale kod i tak idzie do kosza. ⚠️
Potem twarda część: harness to nie pliki MD, tylko hooki, lintery i SonarQube, których agent nie ominie. Frontend przechodzi testy - OK, skasujesz i wygenerujesz na nowo. Logika biznesowa - review. Agent SRE na read only halucynuje, a z pełnymi uprawnieniami stwierdzi, że “buga nie będzie jak będzie baza pusta”. 🤖
Na deser koszty tokenów (150-300 dolarów na DevOpsa, od 300 na developera), mBankowe 3-4% wpływu AI na cały proces i złośliwa puenta: “Jakbyś miał dobry proces, to byłeś już gotowy.” Kto definiuje good enough - Ty czy agent?
Linki i ciekawe znaleziska
Transkrypcja
Szymon Warda: I tu nie oszukujmy się, nasz AI może pomóc w myśleniu, ale to jest ten obszar, kiedy…
Łukasz Kałużny: Jeżeli chodzi o architekturę, nie pozwalam mu podejmować żadnych decyzji.
Szymon Warda: To jest tak pozwólmy tym agentom robić ten kod, który jest krótkowzroczny. Większość ludzi po prostu wklepie prompt i odpowiedź przekleja dalej. To samo się dzieje u developerów.
Łukasz Kałużny: Jedna duża rada i bardzo prosta: obcięcie uprawnień.
Szymon Warda: Jeżeli przeciętny developer w Twoim repo po tygodniu się nie odnajduje, to agent też nie będzie się odnajdywał.
Łukasz Kałużny: Cześć. Słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda.
Łukasz Kałużny: No dobrze Szymuś, to co dzisiaj w odcinku, bo wymyśliłeś strukturę i wywróciłeś wszystko do góry nogami.
Szymon Warda: Dobrze Łukaszu, mój misiu Pysiu, o czym będzie? Przechodzimy trochę, idziemy w dół właściwie, mieliśmy odcinek o tym, jak ubrać powiedzmy AI-a w software developmencie. To teraz powiemy o temacie, którego Ty trochę nie lubisz, a ja trochę bardziej wierzę, choć dalej nie jest to vibe coding, włożenie i realne spojrzenie jak obecnie wygląda nasz cały proces SDLC jeżeli chodzi z punktu widzenia powiedzmy takiego seniora, powiedzmy, albo team leadera.
Łukasz Kałużny: Seniora i też dzisiaj nie technikalia. Powiedzmy sobie, zarezerwowaliśmy sobie na oddzielny odcinek Spec Driven Development, czym on jest. Dzisiaj też to poruszymy jeszcze raz i na przykładzie GitHub Spec-kita. Ale to za tydzień.
Szymon Warda: Tak, więc dzisiaj powiemy sobie o tym, jak obecnie wygląda proces w ogóle wytwórczy, ale taki zaczynając od biznesu.
Łukasz Kałużny: No dobra Szymon, to co, lecimy z pierwszą fazą, o której mówimy, czyli zbieranie wymagań, tak to powinno się poprawnie, w zależności jak tam patrzysz na cykl życia, to mamy wymagania.
Szymon Warda: Tak. I tu nie oszukujmy się, nasz AI może pomóc w myśleniu, ale to jest ten obszar, kiedy AI nie pójdzie do innego departamentu, nie dopyta się jak to wpłynie, nie pójdzie do legala, do procurementu, do wszystkich innych rzeczy, nie zrobi tych dupogodzin na spotkaniach, więc on nam spisze notatki i tak dalej. Tu człowiek jest niezastąpiony, tym bardziej, że może powiedzieć: nie, nie potrzebujemy tego jednak.
Łukasz Kałużny: Jak mówimy sobie o zbieraniu wymagań, to kontekst jest królem w tym miejscu, bo zupełnie inaczej będzie wyglądało, firma, która żyje produktem, jest produktowa, a inaczej będzie to w SAS-ie, w innych rzeczach. Zupełnie inaczej będzie, jak tworzysz internalowy soft korporacyjny, nawet jeżeli do głównego procesu, to są dwa różne światy.
Szymon Warda: Tak i żeby było jasne, ja będę się odwoływał do kontekstu korporacyjnego, bo po pierwsze, większość naszych słuchaczy żyje w tym kontekście, no nie, a duże organizacje produktowe, jak są odpowiednio duże, to też już to się robią korporacje tak naprawdę.
Łukasz Kałużny: Ale mają swój zupełnie inny flow.
Szymon Warda: Tak, ale jest to wszystko łatwiejsze po prostu. A w tym momencie…
Łukasz Kałużny: Raczej tak, w produktowym, pod tym względem… Raczej z perspektywy technicznej jest to prostsze, bo owner biznesowy żyje metrykami produktu zazwyczaj i żyje tym, jak to jest używane, powinien żyć.
Szymon Warda: Bo wszyscy wiedzą skąd są pieniądze.
Łukasz Kałużny: Tak.
Szymon Warda: Bardzo proste.
Łukasz Kałużny: Dobra, to odkrywanie potrzeb i co, feedback użytkownika, te wszystkie sygnały i inne rzeczy.
Szymon Warda: To ja bym jeszcze jedną rzecz dorzucił, moje przemyślenia odnośnie zbierania potrzeb użytkownika i doprecyzowania, w ogóle całość tej fazy. Naprawdę dużo lepiej by nam się wszystkim żyło, gdyby biznes wysyłał linki do chatów i mówił: stąd mamy te wymagania. Bo nie oszukujmy się, to jest przepakowywanie kolejnych, kolejnych odpowiedzi.
Łukasz Kałużny: MID proxy, i teraz tak, bo był ten moment, że zachłysnęliśmy się chatami. Nie oszukujmy się, dla mnie to jest fajne, że jest odkrywanie potrzeby, człowiek sobie bierze i poczatuje. Jest problem taki, że trudno dostarczyć kontekst systemu do takiego chata. To nie jest takie, bo wbrew pozorom teraz…
Szymon Warda: I też kontekst myślenia w ogóle, co właściwie odrzuciliśmy czy co chcieliśmy, co jest niemożliwe, jak to zrobić.
Łukasz Kałużny: Tak, ale ja mówię tak, żeby wiesz, żeby te user story było zajebiste. Bo nie oszukujmy się, to nie jest user story. W większości przypadków to jest feature epic, w zależności w czym pracujecie. I teraz, żeby to było zajebiście przydatne, to najlepiej, żeby chat takiej osoby nietechnicznej miał dostęp do, w teorii, do repozytorium, do jakichś, inaczej, do większej ilości informacji. I wchodzimy w agentic, który w chuj zaciemnia.
Szymon Warda: Może inaczej, ja bym powiedział, że niekoniecznie do repo z kodem, ale do repo innych decyzji, do jakichś ADR-ów, do decyzji, które były podpięte wcześniej, może na przykład do Jiry, do analizy i tak dalej. W sensie kontekst, a z reguły ta cała biznesowa po prostu leci w oknie chata i to jest koniec tej dyskusji. I naprawdę ten kontekst, co ta osoba chciała, nie chciała, co odrzuciła, byłby lepszy niż ten finalny wynik. Oczywiście nikt…
Łukasz Kałużny: Niż rozmowa z człowiekiem.
Szymon Warda: Nikt tego nie zrobi z prostego powodu generalnie, bo z reguły ta rozmowa jest dość krótka. To jest jeden prompt, jedna odpowiedź.
Łukasz Kałużny: Wiesz co, to zależy, o tak, może to jest takie duże…
Łukasz Kałużny: Hiperbolizuje.
Łukasz Kałużny: Tak, duże “to zależy”. I teraz i patrząc się, dobra, to moja perspektywa na to, że te chaty, gdybyśmy dostali, to jest w ogóle myśl genialna, która, jak mi to powiedziałeś, to akurat świetnie to ubrałeś w słowa, więc zobaczenie takiego chata jest super patrząc się, jak bardzo mi to wspomaga. Na pewno jedną rzeczą niedocenioną, którą przydałoby się kurde udostępniać na przykład jako skill wtedy, to jest, żeby napisać testy BDD, żeby mieć jawne kryteria właśnie akceptacji odbioru, żeby napisać starą, dobrą ogórkową składnią.
Szymon Warda: Czyli mieć formalny output z tego wszystkiego.
Łukasz Kałużny: Scenariusze, tak, żeby mieć proste scenariusze. I teraz ja nie mówię, żeby… Bo problem jest taki, który też przy rozmowach, które miałem z klientami, że ludzie nie będą chcieli wypełniać tych scenariuszy. Ale, i zgodzę się, rozumiem ich podejście, większość osób, która wrzuca tam, wrzuca pomysł, że chce mieć to zrobione, tam właściciel, zazwyczaj większość czasu ma zawalone blokiem spotkań w kalendarzu, nie oszukujmy się.
Szymon Warda: Tak.
Łukasz Kałużny: Tak, ale na przykład zmusić, przygotować skill i pomóc, żeby taka osoba w kontekście tej rozmowy dostała skilla A, który powiedzmy, że robi jakąś strukturę.
Szymon Warda: Łukasz, a jak się robiło opcję pomóc, żeby ktoś miał strukturę i pomóc komuś z biznesu? Jak to robisz? Bookujesz mu spotkanie na godzinę i siedzisz i z nim, rozmawiasz.
Łukasz Kałużny: Tak.
Szymon Warda: To jest stary sposób każdej korporacji.
Łukasz Kałużny: Tak. A druga, tylko jeszcze potem, kurde, audiencja jest za trzy tygodnie, znasz ten problem. Ale polećmy z tym, że być może w tym miejscu pomoże nam, żeby ten output chociaż był dla nas łatwiejszy, to jest właśnie jakiś kawałek decyzji, całego kontekstu, żeby w takim output’cie się znalazło, z całej rozmowy podsumowanie co było, jak było rozważane i na przykład te kryteria akceptacji Definition of Ready, Definition of Done, wstęp do tego. To nie ma być finalna wersja, ale jakieś takie trzy, cztery główne scenariusze wydobyte i śmierdzący edge case na przykład, który ta osoba widzi, że ma problem.
Szymon Warda: To jest dobry trop. I co ja bym jeszcze chciał innego? Bo to mówimy odnośnie czy to w ogóle, ja będę myślał odnośnie tego, czy to w ogóle robić? Proste skille, które mówią: zbadanie konkurencji, zbadanie rentowności, takie proste rzeczy, które ustrukturyzują ten proces.
Łukasz Kałużny: Ale to jest, co tylko…
Łukasz Kałużny: Dlatego właśnie wewnętrzny agent, który po prostu, żeby biznes nie wchodził na ChatGPT.com.
Łukasz Kałużny: Ale dobra, to w tym wypadku to jest to miejsce, w które na przykład tak jak mówisz przeanalizuj konkurencję, pomóż z rentownością, nie wierzę w to. O tak, to jest taki moment, w który… Inaczej, osoba, która chciała, to jest bardziej dla mnie produktowe niż korporacyjne. Tak zupełnie, zupełnie szczerze, to jest produktowe. I wiem, że w świecie produktowym takie rzeczy bardzo ludzie wykorzystują.
Szymon Warda: To może inaczej, w sensie korporacyjnym podpięcie się pod Jirę, pod poprzednie zgłoszenia, podrzucenia, żeby na przykład nie dublować, żeby wiedzieć co było, jakie były decyzje i tak dalej. W sensie danie tego, wymuszenie tego scope’u, żeby to nie było na zasadzie generalnie: o, ja bym to bardzo chciał, to ja wklepie i widłami daleko przerzucam.
Łukasz Kałużny: Tak.
Szymon Warda: Bo tak się często w ogóle dzieje.
Łukasz Kałużny: Czy wiesz co, ja tak eksperymentuję z boku zupełnie, może kiedyś to pokażę, jeżeli zacznie działać. Próbowałem ubrać, niektórzy by mnie zabili za to, co teraz powiem, ale żeby ubrać w Yamla taki output specyfikacji.
Szymon Warda: Wiem o co Ci chodzi.
Łukasz Kałużny: Żeby dało go się bardziej mechanicznie do niego podejść.
Szymon Warda: To teraz ja rzucę taki temat, czy może nie wróci Enterprise Architect, który na podstawie Enterprise będziemy wygenerowali kod. Szalony pomysł, ale to…
Łukasz Kałużny: Nie, to nie jest szalony. Powiem Ci tak…
Szymon Warda: Zaczyna mieć ręce i nogi.
Łukasz Kałużny: Pamiętasz Tomka, z którym pracowaliśmy i Marcina. Pamiętasz, mieliśmy dwóch kolegów na pewnym etapie. Przepraszam, od nich specyfikacje, które wychodziły w Enterprise Architekcie, prawdopodobnie w tym momencie, gdyby jeszcze zajmowali się pisaniem specyfikacji, bo pewnie już tego nie robią, sorry, znam analityków, od których, moim zadaniem, gdybym miał pracować jako developer, byłoby wzięcie ich Enterprise Architecta i diffów, zmian, żeby mieć tylko część zmian, które robili i po prostu robienie za, sprawdzanie, czy agent poprawnie tylko zrobił logikę biznesową.
Szymon Warda: I żeby było jasne, my nie mówimy konkretnie o narzędziu Enterprise Architect, ale o formach yamlowych czy formach przepływowych, (…), tak, i inne rzeczy.
Łukasz Kałużny: Tak, tylko że, raczej w sensie formalizacji, przygotowania analizy i wymagań. Bo sposób, w którym oni pracowali…
Szymon Warda: Bardziej centralizacji i weryfikacji poprawności z innymi rzeczami.
Łukasz Kałużny: Tak, tylko że oni mieli to spójne. Zobacz, że sposób w tym narzędziu, oni korzystali z Enterprise Architecta nie do rysowania diagramów, tylko faktycznie do modelowania i zbierania wymagań.
Szymon Warda: Tak i w tym systemie i w ekosystemie, gdzie ten system będzie istniał tak naprawdę, bo to jest problematyczne z agentami, nie wiedzą, co się dzieje dalej. Dobrze. Czyli mamy, mamy, mamy ogarnięte.
Łukasz Kałużny: To tak. Czyli zanim powstanie zadanie, podsumowując, bardzo dobrze wspomaga, ale wspomaga, to nie jest autonomiczne.
Szymon Warda: Tak. I co jest dla mnie też bardzo ważne, to jest to, że tutaj to nie jest tak, że będziemy to wymagali od biznesu, to jest biznes + analityk + ktokolwiek, kto jest bardziej techniczny, bo biznes tego nie zrobi, nie oszukujmy się.
Łukasz Kałużny: Raczej przyśpieszać, czyli powiedzmy sobie wprost, jest tutaj jakaś realna szansa, żeby przyśpieszyć. I tu bym dorzucił jeszcze jedną rzecz, Szymon, której Ty w notatkach nie masz, dużo IT ma tego dosyć. Raczej uważam, że całe IT ma tego dosyć. Czyli próby budowania przez niektórych użytkowników PoC i MVP, takich PoC, makiet i innych rzeczy. I powiem Ci tak, jedna rzecz, którą trzeba przekazać, uważam, że, moja perspektywa, to jest zajebiste. Tylko trzeba przekazać, że hej, sorry, bardzo szanujemy Twoją pracę, zainspirujemy się, zrobimy to w ten sposób, żeby odwzorować tam, gdzie to technicznie będzie miało sens, ale wszystko, co zrobiłeś pójdzie do kosza. W sensie cały kod, który wygenerowałeś, to nie jest gotowe, bo trzeba pokazać i powiedzieć, że uważam, że walidację, że ktoś zrobił sobie prototyp, poklikał po nim i w ogóle…
Szymon Warda: To jest super.
Łukasz Kałużny: To jest genialne i ja bym tego słuchajcie nie wyrzucał do kosza, że w sensie pozwolił…
Szymon Warda: Ani nie negował.
Łukasz Kałużny: I nie negujcie, to jest świetne. Ba, powiedziałbym, że nawet zróbcie kawałek Nginxa czy czegoś, żeby tego NextJS-a, Reacta, pozwolić im wyhostować i żeby ktoś inny mógł poklikać…
Szymon Warda: Tak.
Łukasz Kałużny: Bo będziecie mieli zaangażowanych ludzi. To widzę na przykład nie negowanie tego jest świetne, tylko trzeba bardzo jasno przekazać jedną rzecz: hej, sorry, nasz system wygląda trochę już inaczej pod spodem, ale inspiracja procesu jest zajebista i bierzemy ją od Ciebie.
Szymon Warda: Dobra. Co jeszcze możesz zrobić, to wykorzystanie artefaktów claude’owych do takich rzeczy. Fajnie działają wbrew pozorom.
Łukasz Kałużny: Tak, to jest akurat, zgadzam się, tylko, że nie w każdym orgu będziesz to miał. Weźmy na przykład tych, których mamy gdzieś tam klientów, korzystają z Claude’a, ale przez Bedrocka, Vertexa czy Foundry.
Szymon Warda: Inny case.
Łukasz Kałużny: Tak.
Szymon Warda: Dobra, idziemy teraz: projekt, czyli mamy tam architektura i granice, dokumentacja na zadania, dekompozycja na zadania i przygotowanie środowiska pracy, wszystkie harnessy, toolingi i tak dalej.
Łukasz Kałużny: Jaką masz zatem myśl główną i przewodnią?
Szymon Warda: Dla mnie to jest kilka rzeczy. Po pierwsze, moja taka jedna myśl przewodnia, jaka mi przyjechała, to było to, że bardzo narzekamy na to, że agenci nie są w stanie na przykład przygotować, przewidzieć, co będzie się działo w przyszłości, agent myśli tutaj bardzo krótkofalowo, myśli tylko w tym kontekście i tak dalej. A moja myśl często jest taka: przez te dziesiątki lat naszego kombinowania a co będzie, jeżeli będziemy chcieli usunąć bazę danych? Co będzie, jeżeli będziemy chcieli? To nagle te nasze proste crudy, które mogłyby być naprawdę crudami…
Łukasz Kałużny: Crudami.
Szymon Warda: Crudami, mają więcej abstrakcji, interfejsów i innych rzeczy niż pól na formularzu.
Łukasz Kałużny: I wiesz co, tutaj wrzucimy na ekran komentarz Dominika na Spotify’u. Czytaliście Why Software Factories Fail? Obecnie modele nie są w ogóle trenowane do tworzenia “long term maintainable code” i nie potrafią też tego ocenić. I wiecie co? Dominik, ja się z tym na przykład bardzo nie zgodzę z jednej prostej przyczyny.
Szymon Warda: Dajesz. A ja się z tym zgodzę w ogóle.
Łukasz Kałużny: Nie, ale ja z drugiej strony, bo słuchajcie, kurde, mieliśmy wyznawców, przepraszam, architektura heksagonalna, clean code, solid i wiesz…
Szymon Warda: Dry i tak dalej.
Łukasz Kałużny: Tak, inaczej, czy wiesz, czy całość. Czy weźmy książkę, którą kurde polecamy te czasami gówno, czasami przepiękne, ale jest przepiękne, czyli na przykład Enterprise Integration Patterns. W tych modelach to wszystko jest, to, co niektórzy tak czczą. I…
Szymon Warda: Tak.
Łukasz Kałużny: I Szymon i wiesz o tym, że to na koniec dnia doświadczenie Cię uczy dobierania.
Szymon Warda: Właśnie o to chodzi, przeciętny developer, jakiego mamy w zespole będzie to aplikował prosto, żeby nie powiedzieć na pałę generalnie. I będziemy mieli tych interfejsów, będziemy mieli połączenie 1:1 interfejsu z klasą, już wchodząc w szczegóły. A teraz moja teoria jaka jest, którą muszę jeszcze wypróbować, ale ona na razie mi działa, to jest tak, pozwólmy tym agentom robić ten kod, który jest krótkowzroczny. I co powie? Ale oni teraz robią tam nam slop w tym obszarze i tak dalej, są nieutrzymywane. Ok, to zróbmy tak. Tylko teraz jaki możemy zrobić case? Raz na pięć takich opcji mówi mu: ej, zrób refactor tego. Czemu? Bo w tym momencie on wie już co jest wymagane, mamy wymagania i nie ma takiego patrzenia wprzód: a co będzie, jeżeli? Co się wydarzy, gdy…
Łukasz Kałużny: Dobra, to teraz tak, moje tam patrząc, bo rzuciłeś tak, architektura i granice, dekompozycja na zadania, przygotowanie środowiska pracy. To są…
Szymon Warda: Agenci to ogarniają świetnie.
Łukasz Kałużny: Dobra. Czyli tak, przygotowanie środowiska pracy, harness, toolingi, dane testowe, dostępy. I bądźmy szczerzy, znowu przypominam Gista, którego wrzucałem też parę odcinków temu, może nawet z tego zrobię repo. To chyba będzie lepsze, bo patrząc się ile Boris przekombinowuje to warto to update’ować częściej. To w tym miejscu sorry, wrzucam zbuduj mi harness z takimi wymaganiami.
Szymon Warda: Tak, ale tam jest więcej.
Łukasz Kałużny: I teraz tak, ja teraz, bardzo ważne, przez harness, teraz Szymon co dopracuje, to nie są pliki MD. Ja przez to rozumiem twarde hooki, skrypty bashowe na zasadzie skończył ci subagent działać, nie pozwól mu przestać działać, tylko wyrzuć mu na przykład, że teraz mają się odpalić jeszcze raz automatyczne lintery, testy, skan SonarQubem, metryki czy nie są przekroczone. Czyli harness dla mnie to jest bardzo twarda rzecz.
Szymon Warda: Wrzucimy też tutaj komentarz, który dostałem od kolegi odnośnie tego, jak mu agent tłumaczy, że faktycznie było to, że mam tego nie robić, ale usunąłem bazę, sorry Gregory.
Łukasz Kałużny: Mam ten screen na Discordzie, wrzucimy.
Włodzimierz Cimoszewicz: Potwierdza się, że trzeba być przezornym, trzeba być zapobiegliwym, trzeba się ubezpieczać.
Łukasz Kałużny: Zapraszamy przy okazji na Discorda.
Szymon Warda: Dobra.
Łukasz Kałużny: Dobra. I to od tej strony. Dane testowe, patrząc się jeszcze w połączeniu do libek i innych rzeczy, Szymon, kurde, to jest genialne. Akurat to jest pierwszy czas kiedy wygenerowanie datasetów testowych razem z dodatkowym toolingiem…
Szymon Warda: Łukasz, ja myślę, że do jednej rzeczy wrócimy, o której powiedziałeś, bo powiedziałeś generalnie harnessów i tak dalej. To będzie, bo dostajemy czasami krytykę od niektórych naszych słuchaczy, dziękujemy pięknie, odnośnie tego, że no tak, ale to nie, to jest za dużo i tak dalej, i tak dalej. Tak, tylko że rozdzielmy dwie rzeczy. Rozdzielmy ludzi, którzy będą brali, budowali harnessy i przeciętnego developera, który robi kod biznesowy. To są dwie zupełnie inne role.
Łukasz Kałużny: Raczej wiesz co, czy budowane harnessy? Ja bym tego nawet nie tak. Powiedziałbym ja dzielę inaczej. Są osoby, Oskar znowu pozdrowienia za dzisiejszą rozmowę, bo z Oskarem ostatnio dużo dyskutujemy sobie, trzeba rozdzielić osoby, które bardzo mocno agentic, workflowy wykorzystują, potrafią wykorzystać i mają dopasowane pod swój proces myślowy swoje działania, czy w tym. I fajnie też Oscar u nas na Discordzie powiedział, na przykład są okresy, że przez to, przez jego tryb pracy by dużo nie dowoził, a dzięki agentom na przykład i sposobie pracy jest w stanie coś puścić i zrobić o wiele więcej niż byłby w stanie. Ale ma swój workflow. I teraz wasza krytyka, jeżeli dopracowaliście swój workflow, jest on wydajny, faktycznie przyśpieszyliście, dowozicie więcej, chwała Wam za to. Ale jeżeli popatrzymy na średnią rynkową, tak nie wygląda. I wszystkie te standaryzacje harnessów, podejścia są właśnie po to, żeby zwiększyć średnią zespołu.
Szymon Warda: Tak, dokładnie. Więc jak mówimy, że: o, agenci się nie nadają, o, agenci są świetni, mówmy o tym samym obszarze, na którym pracują. Bo często to są ludzie, którzy mają inne zastosowania, inne przypadki użycia, inny kontekst, ale finalnie oceniają całość.
Łukasz Kałużny: Tak. Dobra, dekompozycja na zadania. I teraz tak, dlaczego idę od tyłu? Bo zaczynam od rzeczy łatwych, które można delegować. Więc przygotowanie środowiska pracy 100%. Byłem na przykład w moim eksperymencie z różnymi eksperymentami z dark software factories. Sorry, ale zawsze IaC, te toole, to zawsze wychodziło bezbłędnie, nawet infra. Jeżeli powiedziałem, jakie chcę mieć technologie i toole, w sensie nie można było pozwolić, żeby sam wybierał toole, to jest duże ten. Zawsze trzeba było to zaakceptować.
Szymon Warda: Wiesz co, tu wchodzi mi jedna rzecz, którą chciałem zaznaczyć w tym odcinku. Odcinek nagrywamy na tu i teraz, na ten konkretny dzień. To, że agent czegoś nie umie, albo że musimy dawać mu harnessy i tak dalej, się zmienia za pół roku całkowicie, to jest nieaktualny fragment. To widzimy załóżmy co się zmieniło. Na przykład kiedyś musiałem mówić dokładnie załóżmy jaki chcę, żeby odpalił krytyków i jakie kryteria sprawdzenia, co mają zrobić, jakie mają być, jak ma oszacować ich wynik i tak dalej. Teraz odpal krytyków i samo wszystko się dzieje faktycznie i robi to dobrze.
Łukasz Kałużny: Ja się z tym będę kłócił, ale zostawmy to w tym momencie. Dekompozycja na zadanie. I w tym miejscu, jeżeli masz dobry plan przez Ciebie zreview’owany, to działa. Jest coraz mniej w tym momencie, tak jak patrzę, Fable albo dobrze przycięty Slopus w tym, czy tam 5.6, nieważne który weźmiecie model, większość z nich frontierów robi to naprawdę…
Szymon Warda: Robi na poziomie średnim rynkowym albo wyżej.
Łukasz Kałużny: Tak, ale teraz bardzo ważne, to jest dekompozycja na zadania. Niestety. I teraz idziemy sobie. Architektura i granice, czyli moduły, kontrakty, modele danych. I tu powiem wprost, tu nadal moim zdaniem w wielu przypadkach są dwa tryby. Ja teraz pracuję w takim, moim zdaniem jest tryb weź, każ mu to wygenerować i potem go zrobić 3 tury na przykład review drugim modelem. Więc ja mam domyślnie w tym moim setupie, takim mini setupie, który używam, mam tak, że odpal Codexa i każ mu zrobić agresywne review i tak 3 razy i dopiero mi to przedstaw.
Szymon Warda: To działa, tak.
Łukasz Kałużny: Czy do jakichś mniejszych rzeczy. Do większych wolę sam to przemyśleć.
Szymon Warda: Łukasz dowozi 80% wartości, a (…) tylko na 20%.
Łukasz Kałużny: Dobra, tylko nadal w niektórych miejscach moim zdaniem i z mojej praktyki wolę mu, jeżeli chodzi o architekturę, nie pozwalam mu podejmować żadnych decyzji. To jest taka rzecz, z którą się nie zgodzę. To jest rzecz, opisanie tego to jest inna sprawa, ale to Ty musisz core rozbudować, core założenia.
Szymon Warda: To moja obserwacja jest taka i to jest jedna z tych takich bardzo ważnych (…) człowieka, który tu istnieje. Definicja wystarczająco dobre, good enough, bo dostajemy dwie skrajności: albo enterprise aplikacje do subskrypcji na maile, albo drugi koniec, wciśnięte nogą rozwiązanie, które powinno być dużo bardziej skomplikowane w to, co już istnieje.
Łukasz Kałużny: Szymon, wiesz, że jestem leniwy i staram się… Inaczej, moja podstawowa zasada: co będzie, jeżeli ktoś do mnie zadzwoni, bo jest problem? I to jest moim zdaniem taki właśnie rule of thumb: zastanów się, co będzie jak Ci każą to utrzymywać?
Szymon Warda: W jaki sposób? Chodzi mi właśnie, tu wchodzi ten moment ważny, w sensie, że decydujemy jaki poziom złożoności my właściwie chcemy i nam tego agent nie dobierze.
Łukasz Kałużny: Tak, ale, teraz była architektura, ale jeżeli chodzi o boundries i granice, to dobry, agresywny krytyk. I to bardziej mówię, to jest per programming rubber duck podejście, pozwoli znaleźć, dobrze znaleźć granicę.
Szymon Warda: I użyłeś tego słowa: znaleźć. To nie, że on wyznaczy i Ty mówisz: narka, nie ma, na to nie patrzę. Nie, on patrzy na wiele kątów, jak moża do tego podejść i pomaga Ci złapać rzeczy, których byś czasami nie złapał.
Łukasz Kałużny: Tak. I teraz patrząc się, tak i dobrą rzeczą jest to, że patrząc, jak złapiesz sobie architekturę, granice, to łatwo wyznaczyć coś, z czego byliśmy zawsze leniwi, czyli znaleźć edge case’y. Szukanie edge case’ów, przygotowanie właśnie kontraktów, testów BDD, to jest na tym, na tym etapie jest świetne. Jaki mam problem z modelem danych? Kurde Szymon, nadal uważa… Inaczej, model danych zawsze był, dało się zrobić go prościej, moim zdaniem.
PRO8L3M: Mordo, chyba czegoś prostszego potrzebujemy.
Szymon Warda: Przekombinowują z reguły strasznie, to się z tym zgodzę.
Łukasz Kałużny: Dobra, czyli co? Projekt jest taki, że on znowu mocno wspomaga.
Szymon Warda: To są jak ORM-y. Większość sytuacji ogarną dobrze, a tam, gdzie potrzebujesz zerknąć, to kupują Ci czas.
Łukasz Kałużny: Wiesz co, to powiem, to jest tak, jak przypomnę, dla mnie to jest taki wiesz, wiem jak się czuje. Moje pierwsze podejście do ORM-ów w 2010… Linq kiedy wchodziło na poważnie? Linq to SQL?
Szymon Warda: Nie mam pojęcia.
Łukasz Kałużny: Dawno, dawno.
Szymon Warda: Dawno.
Łukasz Kałużny: Ale to początki naszej kariery. To jest taki stan powiedzmy. Nie powiedziałbym, że to jest ORM dzisiaj, tylko ORM z początków naszej kariery. Dobra, idziemy do wytworzenia, wytwarzania.
Szymon Warda: Tu jest, może bym powiedziałem, może niekoniecznie dark factory, ale takie naprawdę przyciemnione bardzo mocno.
Łukasz Kałużny: Dobra, jeżeli popatrzymy sobie, tak, implementacja, testy, code review, integracja i merge, build i CI. I teraz tak, od roboty DevOpsowej zostaje nam w tym momencie opisz co chcę, jakie mam wymagania i review tego.
Szymon Warda: Doprecyzujmy, co rozumiemy przez robotę DevOpsową, tą inicjalne stworzenie.
Łukasz Kałużny: To są, inaczej, są terraformy, deploymenty…
Szymon Warda: Leci.
Łukasz Kałużny: Budowa, w ogóle… Inaczej, Szymon…
Szymon Warda: CI/CD-ków.
Łukasz Kałużny: Raczej dobra, przyznajmy się, ja ostatni raz z palca pipeline napisałem może półtora roku temu, jak nie bardziej, o tak.
Szymon Warda: Podobnie.
Łukasz Kałużny: Yamle do Kubernetesa naprawdę nawet nie chce mi się tego… Inaczej, robi tylko review. Inne elementy, muszę mu czasem wskazać, bo widzę takie, slopy się zdarzają, ale 99% kodu będzie ok.
Szymon Warda: Tak, oczywiście że tak.
Łukasz Kałużny: I bardziej będziesz patrzył czy jest zgodna z Twoimi standardami w firmie, niż to czy jest zgodna z podejściem rynkowym. I przykładowo, jak zarzucisz McP na przykład do Terraforma czy do Kubernetesa, sorry.
Szymon Warda: Tak, jedna rzecz odnośnie całego code review. Tak, on to robi dobrze, ale znowu chodzi (…) człowieka dokładne kryteria, żeby nie zostawić tego na zasadzie, żeby zrób, żeby było dobrze, bo takie rzeczy nie działają.
Łukasz Kałużny: Raczej inaczej, pierwsza warstwa code review jest genialna przed człowiekiem.
Szymon Warda: Pierwszą powinna być linter.
Łukasz Kałużny: Linter powinien się odpalić automatycznie.
Szymon Warda: O tym właśnie mówimy, tak. A potem patrzę na to code review, tylko z wytycznymi, jak chcemy, żeby było dobrze i jakie jest nasze good enough.
Łukasz Kałużny: Dobra, i teraz jak tam popatrzysz i tak jak popatrzymy sobie, testy, gdzieś tam właśnie CI i inne rzeczy, to są harnessy, powinny być automatem, sorry.
Szymon Warda: Tak.
Łukasz Kałużny: Jak mówimy o implementacji i teraz mam tu… Raczej, dobra, to jest tak, to jest poziom, znowu potem sobie o tym pogadamy, o odpowiedzialności, to jest poziom bardzo mocny. Czyli tak jak powiedziałem, dla mnie kod DevOpsowy na przykład 100%. I zaczynamy się przesuwać w granicy, gdzie ja muszę co zrobić i pchnąć. I to jest ciągle taka zasada Pareto będzie, 80% roboty wykona za nas, ale frontendy na przykład, to też rozmowa z Tomkiem Ducinem, jak przechodzi testy, to po co na to patrzeć i nie ma optymalizacje.
Szymon Warda: Tu potrzebujemy doprecyzować jedną rzecz, bo znowu będziemy mieli dwie skrajne grupy, które mówią: nie, zrobi wszystko i grupa, która: nie, nie nadaje się.
Łukasz Kałużny: Nie, to jest taka skala szarości.
Szymon Warda: Tak i teraz gdzie ta skala wynika? Jeżeli przeciętny developer w Twoim repo po tygodniu się nie odnajduje, to agent też się nie będzie odnajdywał. Jeżeli natomiast generalnie możesz włożyć developera i on na drugi dzień jest wydajny, może to zrobić, to spoko. Więc dla mikro i małych aplikacji to nawet nie trzeba zarządzać kontekstem, po prostu to działa. Jak mamy aplikację ponad 10 tysięcy kodów, powiedzmy poniżej 100 tysięcy, sorry.
Łukasz Kałużny: Ale inaczej, ale tak, krytyczna logika biznesowa, real time’y, wszystko co nazywamy w firmie, w zależności od tego, co jest mission critical, są różne definicje mission critical.
Szymon Warda: Tylko ile jest takich aplikacji w biznesie? Łukasz, to są z reguły crudy.
Łukasz Kałużny: Raczej dobre i teraz większość nas zabije, ale tak, przyzwyczaimy się, że to się zgadzamy w tym miejscu, że na koniec dnia wszystko da się zrobić maszyną stanów i crudem, gdyby proces biznesowy był transparentny i logiczny.
Szymon Warda: Tak, więc nie komplikujmy sobie życia.
Łukasz Kałużny: Dobra, skończmy a na poważnie żarty. Ale na poważnie, to jest tak, robota DevOpsowa tak, reviewujesz. To jest review. Frontend, tak jak Tomek powiedział…
Szymon Warda: Poklikasz.
Łukasz Kałużny: Tak jak Tomek powiedział, jak testy przechodzi i sprawdzisz testy frontendowe jest ok, to jest ok.
Szymon Warda: Jest ok.
Łukasz Kałużny: Jest ok, bo po prostu skasujesz, wygenerujesz na nowo. Można teraz byłoby powiedzieć jedną rzecz, która gdzieś tam się dzieje. Przykładowo masz testy, że nie wygenerował samodzielnie komponentów, tylko na przykład jak masz biblioteki do komponentów i innych rzeczy, że skorzystał tylko z… Czyli… Ale znowu wracamy do harnessów i pilnowania.
Szymon Warda: Jeszcze jeden obszar, z którym ja się zgodzę. Mianowicie to, żeby on trzymał spójność, żeby za każdym razem ten UI nie wyglądał inaczej, że przycisk jest w lewo, prawo i tak dalej.
Łukasz Kałużny: Dlatego mówię o komponentach i innych rzeczach, że jesteśmy w stanie to też stestować w tym miejscu. I teraz lecimy, logika biznesowa, API i inne rzeczy, backend - review.
Szymon Warda: W większości sytuacji.
Łukasz Kałużny: To jest, trzeba sprawdzić… Inaczej, to jest rozmowa, w większości przypadków powinien być… Inaczej, to jest tak, jak niektórzy siedzą w roli liderskiej, robią tylko review. To jest myślenie krytyczne i umiejętność podpisania się pod tym kodem, zaraz sobie do tego też przejdziemy, podpisania się pod kodem. I wchodzimy na taki niebezpieczny grunt, który też z Oskarem zawsze rozmawiam o tym, rzeczy takie infrastrukturalne pod tytułem jeżeli ktoś tworzy frameworki, biblioteki, tego typu rzeczy, to w tym miejscu agent robi zajebistą robotę, żeby zrobić Ci, zacząć te pierwsze 80%. Będziesz go poprawiał, będziesz przeklinał. Ostatnio ciekawa rzecz, że jak, to też dyskusja u nas na Discordzie była, że jak chcesz przeklinać to najlepiej zacząć, zrobić cleary po prostu w kontekście. Jak to było Szymon? To Ty napisałeś, że i tak trzeba przeklnąć, żeby ładunek emocjonalny zdumpować i dopiero zrobić. Niektórzy robią clear w ramach samokontroli przed, a niektórzy dumpują ten kontekst i wyżywają się na agencie. Więc my się zaliczamy do tej grupy wyżywającej się.
Szymon Warda: Czasami trzeba.
Łukasz Kałużny: Tak, ale jak odchodzi za bardzo. Więc ten, im bardziej są rzeczy krytyczne albo długofalowe, tym bardziej będziesz robił sam. I też przypomnimy te badanie o open source, że wyszło na to, że maintainerzy bibliotek i innych rzeczy, ich wydajność, agent vs oni, była względem błędu statystycznego w wielu miejscach.
Szymon Warda: Tak, ale moja teoria jest też taka, czemu to? Bo w tych jednoosobowych albo paruosobowych projektach masę jest wiedzy stadnej w głowach tych ludzi. Więc agent po prostu, ten agent, który jest w trybie: a rób w aplikacji enterprise, takiego kodu jest najwięcej w sieci, więc on się takiego nauczył, nie odnajduje się w tym wąskim kontekście, gdzie po prostu trzeba coś zoptymalizować. Dlatego też.
Łukasz Kałużny: Ale też z drugiej strony potrafi wykryć. Weźmy na przykład…
Szymon Warda: Tak to jest fajne, on wykryje, on napisze testy i tak dalej.
Łukasz Kałużny: Tak.
Szymon Warda: Dalej, dużo tej roboty, której nie chcemy robić.
Łukasz Kałużny: I wiesz co i tak, czyli wytworzenie. To nie jest znowu dark factories, tak jakby wszyscy chcieli, że zadzieje się automatycznie. To jest człowiek na wejściu, który potrafi, albo z projektu potrafi zrobić specyfikację i ją zreviewować i potrafi odebrać wyniki.
Szymon Warda: O, ale teraz dochodzimy do tematu, który jest dla mnie bardzo ważny. Największy problem jaki jest, to jest ownership tego wszystkiego. Większość ludzi po prostu wklepie prompt i odpowiedź przekleja dalej. To samo się dzieje u developerów, a już ownership tego kodu, który się wytworzył, czy on jest dobry, a czy ma robić to, co powinien robić, jest prawie zerowy.
Łukasz Kałużny: Ale dobra Szymon, to powiedzmy sobie wprost, że…
Szymon Warda: Jeszcze coś dorzucę. Bo kiedyś mieliśmy ownership na podstawie tego kodu, który napisaliśmy, będziemy go bronili, że on jest super fajny, moje tutaj.
Łukasz Kałużny: Teraz agent napisał.
Szymon Warda: Wielka fabryka, jest super i tak dalej.
Łukasz Kałużny: To agent napisał, to agent napisał.
Dario: O, ale to nie do mnie tak, do mnie nie.
Szymon Warda: Więc teraz nie bierzemy poczucia odpowiedzialności za nic kompletnie.
Łukasz Kałużny: Inaczej, moja, patrząc, postrzegając branżę troszeczkę, jak ja tam patrzę i moje oczekiwania… Kurczę, jak to dziwnie, jak to będzie, teraz dziwnie zabrzmi, oczekiwania jako pracodawcy z drugiej strony, to jest to, że ktoś bierze odpowiedzialność za outcome.
Szymon Warda: I tu jest największy problem generalnie, bo większość ludzi nie bierze. Mamy super ludzi w organizacji u nas, ale jak pójdziesz do dużej korporacji, nie oszukujmy się, Łukasz.
Łukasz Kałużny: Nie, bo teraz wiesz, cała dyskusja, wiesz, bo teraz powiedzmy sobie, fajnie powiedział pamiętam, to też było trochę publicznie, Krzysiek Dąbrowski powiedział, na ile wyceniał w mBanku, że jego zakład wykorzystania AI-a po prostu, że w skali całego procesu to są 3-4%, że pisanie kodu, on ma, że ma tyle procesów. Dzisiaj tam nie wrzucę, bo autora, z autorem się nie zgadzam bardzo często artykułu, ale wrzucił ciekawą rzecz akurat właśnie, która pasuje w wielu miejscach, która pokazuje dlaczego jest spowolnienie, że Fintechy to skansen IT. To już tam swoją drogą można byłoby kiedyś o tym podyskutować. Ale jak pójdziemy, to wytworzenie to jest bardziej powiedziałbym, że jesteś w stanie, jest bardzo szare, jest bardzo szare. Są rzeczy, które przeklinam, jak ten. Zresztą wiesz, są rzeczy, które działają genialnie.
Szymon Warda: I to zależy od kultury organizacji bardzo dużo. Ale jeszcze takich parę rzeczy odnośnie tego właściwie gdzie się człowiek odnajduje w tym całym, jaka wchodzi odpowiedzialność. Bo to, czego agenci obecnie nie umieją, to takiego myślenia holistycznego odnośnie całego procesu. Agent nie napisze Ci załóżmy… Powiem o jednej rzeczy, każdy nowy agent to jest nowy pracownik od zera, on nic nie wie, musi się nauczyć. Czyli zarządzanie kontekstem, zarządzanie toolingami, ewoluowanie tego wszystkiego, pilnowanie naszych założeń, zmiana tych założeń, to wszystko są obszary, gdzie dalej człowiek musi myśleć i w tym procesie wytwórczym istnieć na chwilę obecną jeszcze.
Łukasz Kałużny: Wiesz co, będę, tak jak powiedziałem, te modele będą biasować się i skręcać w dziwne strony, w które nie chcemy, więc dlatego pomiędzy etapami nadal będzie musiał być człowiek. Jeżeli wejdziemy tam, będziemy krytykować sobie, rozmawiać na temat spec driven development, czyli że przygotowujemy specyfikację i jedziemy i na każdym kroku człowiek powinien zrobić review, bo to jest proces myślowy.
Szymon Warda: Nie wiem, czy na każdym, ale to pogadamy.
Łukasz Kałużny: Tak, pogadamy potem, jak będziemy męczyć to GitHuba i też w tym. Dobra. Następnie masz dostarczanie, release’y, deploye, weryfikacja na produkcji, działa.
Szymon Warda: Działa, release’y, całe CD i tak dalej. Tu w ogóle nawet nie ma o czym rozmawiać.
Łukasz Kałużny: Tak, to jest, działa, pomaga w tym. Jedna duża rada i bardzo prosta: obcięcie uprawnień, mocne obcięcie do read only.
Szymon Warda: O tym będziemy mówili przy życiu po deployu.
Łukasz Kałużny: Dobra, ale jeżeli chodzi o takie wsparcie w ogóle takie całe do deploy i rzeczy, tak, tak, tak. Inaczej, jedno: przytnij uprawnienia, tak jak przy Twoim tym, przy Twoim momencie, przytnij uprawnienia.
Szymon Warda: Dobra, to teraz jedna rzecz właśnie, bo teraz wchodzimy już na życie po deployu. Wartość, która jest dla mnie niesamowita, to są właśnie agenci SRE zrobieni dobrze. Czyli podpinasz to pod logi, podpinasz to pod metryki, wszystko i tak dalej, to podpinasz pod kod i agent sobie siedzi. Mogą monitorować systemy, które już nikt nie wie co tam się dzieje właściwie. Tylko problem jest teraz taki, że mamy w tym momencie, Ty mówisz tylko read only. Ok, tylko w tym momencie agent nic nie naprawi.
Łukasz Kałużny: Dobra Szymon, przepraszam, to dopasujmy read only, na przykład to co też ćwiczyliśmy u klientów, bo to trzeba takie z życia. No to jedno. Przykładowo restart, to co jest wrzucone, czyli trochę bardziej, nie read only. Trzeba pomyśleć jak o L1, L2, czyli zastanowić się. I to jest rzecz, którą musi zrobić człowiek, zastanowić się, gdzie na przykład może robić troubleshooting…
Szymon Warda: I jak go ma robić.
Łukasz Kałużny: I jak ma go robić. Przykład, to, co mamy zrobione u klienta. Przykładowo, może zmieniać, weźmy na Kubernetesie, może wejść tam na jakiś tam, ma jakieś tam specjalne komendy, skrypty, żeby odpalić skrypty do exeków, które na przykład pozwolą mu zrobić TCP dumpa, odpalić curla jakiegoś i inne takie rzeczy. Czy na przykład ma dwa uprawnienia na Kubernetesie, ma rollout deployment i delete poda, że potrafi, na przykład dajemy agentowi…
Szymon Warda: Ja mam co do tego pewne inne podejście zupełnie.
Łukasz Kałużny: Dobra, ale że pozwalamy, ograniczamy, robimy, traktujemy go jak junior operatora i dajemy mu jakiś zestaw, ale dajemy mu bardzo szerokie read only, na przykład wpuszczenie go. Zresztą sam to też testowałeś i byłeś, jak świetnie potrafi execution plany na przykład na Postgressach i innych rzeczach sprawdzać, statystyki proponować w tym.
Szymon Warda: Tylko jedna rzecz, potrafi też halucynować. Mówi, że to na pewno jest ten powód, na pewno. Potem mówi: ok, jednak się pomyliłem. Dla mnie właśnie krytyczne jest tutaj, żeby to działało dobrze z mojego doświadczenia, to jest taka opcja: ok, czyli read only super. Druga opcja, która jest krytyczna, bardzo, bardzo krytyczna, to jest to, że dajmy mu środowisko, w którym będzie on mógł to zweryfikować. I tu wchodzimy i wiem, że zaraz powiesz, ale tego nikt nie zrobi. Tak i do tego właśnie dążymy. Dążę, że taką opcję, żeby agent był niezależny, to co powinien mieć? Opcję skopiowania produkcji, odpalenia środowiska efemerycznego, weryfikacji, tam rolowania w kółko i potem dania to, co powinien zrobić.
Łukasz Kałużny: Inaczej…
Szymon Warda: Ale tego nie zrobimy, to jest drogie.
Łukasz Kałużny: Nie zrobimy, wiesz…
Mateusz Socha: You give me five dollars. Ile?!
Łukasz Kałużny: Inaczej, wyliczę prawdopodobnie z całej mojej kariery, Ty wiesz, że to liczymy…
Szymon Warda: Pojedyncze organizacje, nic więcej.
Łukasz Kałużny: Jestem w stanie z 4.
Szymon Warda: To i tak dużo.
Łukasz Kałużny: Raczej w sensie…
Szymon Warda: Ja bym powiedział dwie, trzy.
Łukasz Kałużny: Cztery w jedną, wiem, że w ciemno prawdopodobnie jak zadzwonię, gdyby tam ten, to prawdopodobnie powiedzą, że już to właśnie wykombinowali jakiś czas temu i byli w stanie. To jest takie wiesz, jak wyciągnę telefon i zadzwonię. Więc cała, tak, obserwowalność, monitoring, incydent management on call.
Szymon Warda: Zarządzanie uprawnieniami, to co powiedziałeś.
Łukasz Kałużny: Tak.
Szymon Warda: Nagrywanie ruchu, żeby to potem móc zweryfikować, czy to jest realny ten problem i tak dalej.
Łukasz Kałużny: Tak i to jest świetne. Wiesz, to jest jeden. Inna rzecz, to testujemy z klientem, że jak jest on call, żeby inżynier na przykład właśnie, jak zostanie już podniesiony alert, to żeby agent już w międzyczasie, Holmes GPT właśnie latał i już sprawdzał, że ktoś dostaje już rozgrzanego agenta, jak przychodzi.
Szymon Warda: Tak, tylko znowu wchodzimy, że powinna być ta (…) nie będziemy tego robili. I to jest ten problem właśnie, że pójdziemy w opcję albo: a tam, dobra, jakość będzie, damy temu agentowi fulla. Albo będziemy go trzymali na read me i on w tym momencie będzie dużo halucynował. Ok, coraz mniej z czasem, ale będzie halucynował.
Łukasz Kałużny: Tak i to jest, wiesz, teraz można byłoby zrobić cały odcinek dosłownie gdzieś o moich doświadczeniach, jak przygotowywać sobie repo pod takiego agenta specjalnego, pod Holmesy, pod Holmesa czy inne rzeczy do troubleshootingu, bo to nie jest, jest to problematyczne.
Szymon Warda: Troubleshooting jest jeszcze w miarę prosty. Weryfikacja tego, co on wymyślił sobie, to jest skomplikowane, a tu jest więcej wartości.
Łukasz Kałużny: Tak, przy czym szybkie, on bardzo dużo można zdjąć takich rzeczy, bardzo powtarzalnych czynności, które były na zasadzie zrestartuj serwis, dołóż zasobów i inne takie elementy. Można, to akurat bardzo dobrze można zrobić.
Szymon Warda: Ale wiesz o jednej rzeczy, jak będziemy mieli pecha, a będziemy mieli pecha, bo to jest prawo liczb dużych, to on stwierdzi, że okej, jak naprawić buga? Buga nie będzie jak będzie baza pusta. I do tego dojdzie.
Łukasz Kałużny: Prędzej czy później.
Szymon Warda: Prędzej czy później dojdzie do tego.
Łukasz Kałużny: Dlatego cięcie uprawnień jest ważne.
Szymon Warda: Tak, ale znowu nie naprawi, jeżeli nie będzie mógł zaaplikować czegoś. To jest takie…
Łukasz Kałużny: Raczej nie, ale czy ma naprawić? Moim zdaniem ma zaproponować.
Szymon Warda: Teraz tak. Za pół roku będzie, wiesz jak to będzie wyglądało: coś dodał, apply.
Łukasz Kałużny: Raczej mi się podoba tak jak tam mam znajomych w Google’u, korzystacie… Inaczej, wracamy do tego wszystkiego, a zautomatyzujcie co chcecie, ale Wy jesteście odpowiedzialni za outcome. Twój automat naprawiał on calla, to Twój, to Ty odpowiadasz za ten automat.
Szymon Warda: Tak, ale po tym jak nie będzie backupu bazy to generalnie to jest już problem organizacji.
Łukasz Kałużny: Tak, to jest problem, tak, staje się problemem wszystkich. Dobra i teraz tak, masz jeszcze taki punkcik: utrzymanie i ewolucja. I to jest fajna rzecz. Tylko wiesz co, dla mnie to jest utrzymanie i ewolucja, to są dwa takie elementy, bo ja na to patrzę przez jako architektura i implementacja, dla mnie to jest taki element.
Szymon Warda: Dla mnie jeszcze jedna rzecz, trzymanie aktualizacji bibliotek tego całego…
Łukasz Kałużny: Nie, nie, nie, to w ogóle spłacanie, ciągle bycie…
Szymon Warda: Tak.
Łukasz Kałużny: On time. Inaczej, tylko to jest… Inaczej, traktujemy to jak task wytworzeniowy już wtedy, regularny task wytworzeniowy.
Szymon Warda: No tak, chociaż możesz mieć system po prostu nie utrzymywany już niejako. Nie jest rozwijany, może tak.
Łukasz Kałużny: Tak, ale inaczej, dobra, da się przygotować testy regresyjne dla starego systemu i inne rzeczy. To jest świetne. Ja bym tutaj dodał jedną rzecz i połączę to też z decommissioningiem, decommissioningiem kodu. To jest moment, kiedy tak, tak proste zaczyna być mierzenie wykorzystania i szukania martwego kodu w Twoim repozytorium. To zaczyna być, ja wiem, zaczynają być pewne techniki, którzy robią, ale… Inaczej, to jest już teraz na wyciągnięcie ręki.
Szymon Warda: Łukasz, to jest taka opcja, tak, namierzysz kod, ale potem ktoś musi powiedzieć: tak, usuwamy. I tego nikt nie powie, bo: a może się kiedyś przyda.
Łukasz Kałużny: Chciałem powiedzieć te warsztaty w lutym i marcu. Macie, jak to było? Hej, ale Wy te 70% możecie wyrzucić kodu. Refaktoring.
Szymon Warda: I nikt tego nie usunie.
Łukasz Kałużny: Nie podejmie.
Szymon Warda: Zbyt duże ryzyko po prostu.
Łukasz Kałużny: Ja wiem, ale mówię, że jak mówimy o replatformingu i innych rzeczach, to… Inaczej, pierwsza rzecz, jak zawsze rozmawiamy o modernizacji, to ile da się z tego wyrzucić? Bo to jest w ogóle najprostsza rzecz.
Szymon Warda: Najlepsza, absolutnie tak i ta, której prawie nikt nie robi. Dodawanie, za dodawanie mało kto Cię ochrzani, tak nazwijmy ładnie.
Łukasz Kałużny: Dobra, masz jeszcze mity mój drogi.
Szymon Warda: Tak, jeden mit, który, ważne, żeby, szkoda, że nie było na starcie. To wszystko, o czym mówimy nie zadzieje się, nie zrobimy w ramach subskrypcji dla developerów. Koszty tego to są dziesiątki tysięcy dolarów miesięcznie.
Rafał Pacześ: Ja pierdolę, jebać biedę.
Łukasz Kałużny: Czy dziesiątki.
Szymon Warda: Dla takich systemów powiedzmy średnich, tak Łukasz.
Łukasz Kałużny: Dobra, powiedzmy to są te rzeczy, kiedy mówimy, że abonament na developera, raczej tokeny na developera, tam w zależności jak zrobimy, to jest spokojnie, lekką ręką… Może inaczej, na DevOpsa możesz liczyć pomiędzy 150 a 300 dolców miesięcznie na tokeny.
Szymon Warda: Tak, spoko.
Łukasz Kałużny: Developer to zaczyna się od 300. I teraz jest pytanie, w którym momencie kończy się wartość? To jest pytanie. I jak popatrzysz tak, na (…) tam te Red Haty i inne rzeczy co były, to co też u nas rozmawiamy, to jest pytanie, kiedy taniej byłoby mu juniora kupić, zatrudnić juniora? W którym momencie zwiększanie zespołu jest tańsze niż w tym? Niektórzy traktują już pisanie kodu, że to jest jak zwierzęca praca, że mu każą ręcznie pisać kod.
Szymon Warda: Ustalmy, tym takim opcji jak najbardziej dark, to to są duże koszty tokenów.
Łukasz Kałużny: I moim zdaniem nie ma to…
Szymon Warda: Zależy gdzie. Wydaje mi się, że teraz… Znaczy inaczej, trzeba tam powoli dążyć, ale to nie pchajmy się.
Łukasz Kałużny: Nie, to nie ma, wiesz co, dla mnie to się… Jak ja widzę ten, jest ten, ile przynoszą produkty z dark software factories minus 1000 dolarów miesięcznie.
Szymon Warda: Tak, zgadza się. Ale mój warunek, warunek, sugestia inna jest, powoli przygotowujemy do tego procesy, żeby to dawać i tak dalej, bo tu jest wartość.
Łukasz Kałużny: Dobra Szymon.
Szymon Warda: Niezależnie czy dojdziemy czy nie dojdziemy.
Łukasz Kałużny: Będę złośliwy.
Szymon Warda: No dajesz.
Łukasz Kałużny: Jakbyś miał dobry proces, to byłeś już gotowy.
Szymon Warda: Tak, dokładnie tak. I tylko wpinasz tych agentów i generalnie śmiga.
Łukasz Kałużny: Bardziej to są pytania o integracji. Bo wiesz, to jest teraz taka głupota, że wiesz o tym, że są projekty, które nie miały linterów…
Szymon Warda: Większość.
Łukasz Kałużny: Nie miały, tak. Jak pójdziesz, ten, jak mówisz, to jedyna metryka z SonarQube’a jaka jest sprawdzana, to pokrycie testami kodu.
Szymon Warda: Bardziej czy Sonar w ogóle jest włączony? To jest to.
Łukasz Kałużny: Nie, nie, to jest, nie, nie, ja mówię, że najczęstszą metryką, jaką widzisz, jedyną sprawdzoną, która była, tak realnie, większość, co oglądamy… Wiecie co? Prawdopodobnie teraz powiecie, że tak nie jest, bo u nas w projekcie, słuchacie nas i prawdopodobnie…
Szymon Warda: Jesteście w tej grupie, w której adresujemy problemy.
Łukasz Kałużny: Tak, w której na co dzień adresujemy i tak to wygląda. Więc te wszystkie rzeczy były. Słuchaj, ile razy… Średnio co 4 lata mówimy: zróbcie prawidłowo CI-a. To jest tak mniej więcej, tak wraca.
Szymon Warda: Środowiska efemeryczne to jest już staroć, staroć.
Łukasz Kałużny: Staroć, staroć. Więc to jest takie sobie powiedzenie. Więc w tym miejscu.
Szymon Warda: Tyle, właściwie.
Łukasz Kałużny: Tyle. I słuchaj, czyli tak przelatując, podsumowując, jak sobie popatrzymy, odkrywanie potrzeb, przygotowanie świetnie pomaga.
Szymon Warda: Tak.
Łukasz Kałużny: Projekt pomaga, ale nadal człowiek musi trzymać kontrolę.
Szymon Warda: W dużo mniejszym zakresie.
Łukasz Kałużny: Ale nadal… Inaczej, myślenie krytyczne jest bardzo potrzebne.
Szymon Warda: I ja bym powiedział decyzyjność, tak bym to nazwał.
Szymon Warda: I wsad dobry. Wytworzenie, duża skala szarości, od tego leć całością, zastanów się. To jest krytyczność biznesowa i wielkość projektu, o której trzeba powiedzieć.
Szymon Warda: Dokładnie i wielkość projektu. Dostarczenie.
Łukasz Kałużny: Weryfikujesz, koniec.
Szymon Warda: Tak.
Łukasz Kałużny: Życie po deployu i znowu skala szarości od obszarów.
Szymon Warda: Tu najbardziej krytyczne jest przygotowanie organizacji i te wszystkie rzeczy, które musimy zrobić w związku, żeby nas to nie kopnęło nie powiem gdzie 5 razy.
Łukasz Kałużny: To do usłyszenia za tydzień i zabawa w SpecKita.
Szymon Warda: Czekaj jeszcze, jak się nie zgadzacie, napiszcie w komentarzach.
Łukasz Kałużny: Trzymajcie się! Hej.
Szymon Warda: Hej!
