AI agent jako część zespołu IT. Gość: Bartosz Fijałkowski - POIT 319

Witam w trzysta dziewiętnastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy są agenty AI jako część zespołu IT.

Dziś moimi gościem jest Bartosz Fijałkowski – ekspert na styku AI, software delivery i budowania nowoczesnych zespołów technologicznych. Zawodowo skupia się na backendzie i AI w GFT Technologies Poland, ale jego perspektywa wykracza daleko poza kod – koncentruje się na tym, jak AI realnie zmienia sposób tworzenia produktów i pracy zespołów. Interesuje go, jak budować organizacje, które potrafią efektywnie łączyć ludzi i AI w jeden, działający system. Zdarza mu się występować na konferencjach, gdzie pokazuje jak zmienia się rola inżyniera, czym jest AI‑driven product development i jak wygląda leadership w świecie, gdzie AI zaczyna współtworzyć software.

W tym odcinku o agentach AI rozmawiamy w następujących kontekstach:

• czym jest AI agent i gdzie kończy się hype, a zaczyna praktyka
• roli agenta AI jako narzędzia lub członka zespołu
• zmian w strukturze zespołów IT wspieranych przez AI
• przyszłości specjalizacji i roli software engineera
• miejscu juniorów w świecie AI Native
• odpowiedzialności za awarie i błędy popełniane przez agentów
• nowych kompetencji dobrego programisty
• wpływie AI na współpracę i relacje w zespołach
• ryzyku powstawania nowych silosów oraz utraty wymiany wiedzy
• największych wąskich gardłach w erze szybkiego developmentu
• ewolucji roli seniora i lidera w organizacjach AI Native
• wizji zespołów produktowych za 3–5 lat: ludzie, agenci i nowe role

Subskrypcja podcastu:

• zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
• poproszę Cię też o polubienie fanpage na Facebooku

Linki:

• Profil Bartka na LinkedIn – https://www.linkedin.com/in/bfijalkowski/
• GFT Technologies Poland – https://www.linkedin.com/company/gft-technologies-poland/posts/?feedView=all

Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/319

Transcript

SPEAKER_00 0:00

To jest 319 odcinek Porozmawiajmy IT. Dziś rozmawiamy o agentach AI jako części zespołu

Wprowadzenie i gość odcinka

SPEAKER_00 0:06

IT. Notatkę, linki i transkrypcję, czyli wszystko to, co porządny słuchacz powinien mieć pod ręką, znajdziesz na porozmawiajmyit.pl łamane na 319. A jeśli myślisz o zmianie pracy, albo po prostu masz dość klikania dalej na ogłoszeniach bezwidełek, to zajrzyj na solid Jobs. Tam wszystko jest na tacy wynagrodzenie, technologie, projekty bez zgadywania. Nazywam się Krzysztof Kępiński. Tworząc ten podcast, napisałem też książkę Marka Oswista Flash. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej, albo zostaw ocenę w swojej apce. To jest dla mnie nieoceniona pomoc. A teraz odpalamy. Cześć, mój dzisiejszy gość to ekspert na styku AI, software delivery i budowania nowoczesnych zespołów technologicznych. Zawodowo skupia się na backendzie i AI w GFT Technologies Poland, ale jego perspektywa wykracza daleko poza kod. Koncentruje się na tym, jak AI realnie zmienia sposób tworzenia produktów i pracy zespołów. Interesuje go, jak budować organizacje, które potrafią efektywnie łączyć ludzi i AI w jeden działający system. Zdarza mu się występować na konferencjach, gdzie pokazuje, jak zmienia się rola inżyniera, czym jest AI Driven Product Development, jak wygląda leadership w świecie, gdzie AI zaczyna współtworzyć software. Moim waszym gościem jest Barosz Fiałkowski. Cześć Bartku, bardzo miło mi gościcie w podcaście.

SPEAKER_01 1:26

Cześć, Krzysiek, dzięki za zaproszenie. Również bardzo miło jest mi tutaj z wami być.

SPEAKER_00 1:32

A przed nami ciekawa, interesująca rozmowa o temacie, który już trochę dzieje się teraz, trochę wkracza w erę takiej przyszłości, trochę science fiction, ale myślę, że mniej lub bardziej większość osób z IT będzie miała z nim do czynienia, ponieważ z Bartkiem będziemy rozmawiać o tym, jak wygląda sytuacja zespołu, jak zmienia się zespół, kiedy AI agent zostaje właśnie częścią tego zespołu. Zanim przejdziemy do właściwej rozmowy, to chciałbym cię Bartku zapytać o to, czy słuchasz podcasty i być może jakieś ciekawe audycje na Twojej liście się znajdują.

SPEAKER_01 2:08

No to tak, Krzyś, zdecydowanie słucham podcastów. I tutaj muszę też przyznać szczerze, że kiedyś słuchałem ich troszkę więcej niż teraz. Wynika to z tego, że przesiadłem się mocno z auto do pociągu i jak już jestem w tym pociągu, to niestety, niestety, częściej na biurku przede mną ląduję laptop i coś tam na tym laptopie sobie dziergam. Więc generalnie albo sobie zaczynam pracować, albo sobie robię jakieś szkolenia i wtedy tych podcastów jest troszkę mniej. Natomiast z tych podcastów, które słucham, no to przede wszystkim słucham Krzysiek Twojego podcastu. Bardzo go lubię. Miło. Więc z tego rodzimego podwórka, no to na pewno porozmawiajmy o IT. Bardzo lubię też DevTok, Maczkawicza. Maciek Anicerowicz jest eks dotnetowcem, tak samo jak ja, więc tutaj mamy pewną nici porozumienia. No i lubię go też posłuchać. Co prawda, DewTok miał sporą przerwę w nagrywaniu, bo tam głównie go słuchałem te 5-6 lat temu, jak nagrywali regularnie. Natomiast wrócili na antenę, więc jak wrócili na antenę, to też oczywiście bardzo chętnie ich zawsze posłucham. Z zagranicznych podcastów, no to Dotnet Rocks. Tutaj oczywiście idą z tym samym trendem dotnetowym z Richardem Kampelem i Karlem Franklinem. No nie będę się chyba rozwijał, czym to jest podcast, bo nazwa sama wskazuje. Natomiast jak nie mam ochoty na nic związanego z IT, to jeszcze często wpada u mnie żurnalista albo Jouran, jak mam ochotę na coś takiego, co w ogóle nie jest powiązane z branżą, więc z grussza wygląda to tak.

SPEAKER_00 3:56

No i dzięki. Mocne rekomendacje, na pewno warte polecenia.

Czym jest agent w zespole

SPEAKER_00 4:00

Dobrze, to przechodząc do tej części już właściwej naszej rozmowy, to chciałbym Cię zapytać, co to właściwie znaczy, że AI agent jest częścią zespołu? Co możemy osiągnąć już teraz, co mamy na myśli już teraz, mówiąc właśnie o AI agencie, dołączającym niego do zespołu, a co jeszcze leży trochę w domenie przyszłości, w domenie science fiction?

SPEAKER_01 4:21

Dobra, to możemy sobie tutaj zacząć od końca, czyli możemy sobie zacząć od tego, co uważam, że jest science fiction jeszcze na ten moment. No i tutaj w tej takiej domenie science fiction powiedziałbym, że jeszcze jesteśmy mówiąc o sytuacji, w której mamy członka zespołu, który w zasadzie wchodzi na stand-up, to jest Robert. Robert jest zaawansowanym algorytmem. Od dzisiaj będzie z nami razem programował, będzie sobie zbierał taski z giry, wytwarzał kod, jak czegoś nie będzie wiedział, no to dopyta analityka na Team'ach. Także tutaj, jeżeli mówimy o czymś takim, no to zdecydowanie znajdujemy się w tej sferze science fiction i tutaj tego bym się jeszcze przez najbliższy czas nie spodziewał. Chociaż warto podkreślić, że nagrywamy ten podcast w lipcu 2026. To jest stan na lipiec, bo oczywiście ta technologia się zmienia tak dramatycznie szybko, że różnie to może wyglądać za te kilka lat. Natomiast tutaj to, o czym mówimy, jeżeli chodzi o agent jako członek zespołu, to w zasadzie możemy sobie porozmawiać o czymś, co nazywa się konceptem personifikacji, czyli ogólnie rzecz biorąc, nadawania cech ludzkich pewnej klasy rozwiązania powiedzmy. Więc tutaj wyjdę trochę od tego, że my, jeżeli chodzi o nasze procesy w GFT, o nasze i o nasze SDLC, no to używamy konceptu Spec Driven Development. Wiem, że miałeś Krzysiek cały odcinek na ten temat, więc może już nie będziemy się w to bardzo zagłębiać. Natomiast głównie chodzi o to, że wytwarzamy ten kod ze specyfikacji, ta specyfikacja zawiera w sobie mniej więcej to, jak to ma wyglądać od strony biznesowej, od strony technicznej i tak dalej.

Agent jako architekt

SPEAKER_01 6:28

No i tutaj na przykład w naszym procesie mamy to grane tak, że zanim ta specyfikacja finalnie zostanie dostarczona do dewelopera, który ma z niej wytworzyć kod, no to jest przeglądana. Jest właśnie przeglądana przez agentów, którzy mają w pewien sposób udawać pewne osoby powiedzmy. Czyli mamy sobie takiego agenta, który na przykład sprawdza, w jaki sposób ta specyfikacja ma się do tego, co mamy w naszym standardzie organizacyjnym. Innymi słowy, ten agent nazywa się architekt, no i zamysłem jest to, żeby w ramach takiego narzędzia sprawdził, czy ta specyfikacja jest zgodna z naszym firmowym standardem architektonicznym. Więc de facto trochę o tym mówimy tak, że architekt robi nam review. Ten agent architekt robi nam review naszej specyfikacji i zgłasza nasze uwagi. Ustawiamy go tak, żeby powiedzmy zachowywał się trochę jak architekt, ale koniec końców, jest to po prostu napisany jakiś tam kawałek kodu z kawałkiem PROP-u. I tak może troszkę go utożsamiamy z człowiekiem. Natomiast jest to po prostu jedno z kolejnych narzędzi w procesie, którego tutaj używamy. Więc tak to wygląda.

SPEAKER_00 7:50

No właśnie, bo myślę sobie, że jedno to jest to, jakie mamy możliwości techniczne, które tak jak zaznaczyłeś z miesiąca na miesiąc idą do przodu i nieraz aż ciężko za tym nadążyć. A z drugiej strony, takie mam wrażenie, postrzeganie członków zespołu, tak jak ten nowy, nazwijmy to byt, powiedzmy, tutaj się odnajduje. No właśnie, jak z Twojej perspektywy to wygląda? Czy my już zaczynamy coraz bardziej myśleć o takim agencie, jako takim, wiesz, qua-członku zespołu, czy też może nadal traktujemy to jako algorytm, jako zaawansowane narzędzie?

SPEAKER_01 8:26

Wiesz co, tak jak ja sobie o tym myślę, to jednak mimo wszystko dalej powiedziałbym, że jest to po prostu bardziej zaawansowane narzędzie i jakiś tam powiedzmy, kolejny etap ewolucji, tego, z czym pracujemy. Także tutaj też trochę wracając do historii, no tam może nie aż tak daleko jak do kart perforowanych, ale możemy powiedzieć, że wyszliśmy historycznie z Terminala do trochę cięższych środowisk deweloperskich, takich jak Visual Studio, czy narzędzia od Jade Brains. Trochę się do tego przyzwyczaiłem. Zresztą ja też swoją drogą bardzo lubiłem to narzędzia i lubiłem z nimi pracować. No i teraz w zasadzie robimy to kółeczko i wracamy z tych ciężkich narzędzi albo do lekkich IDI, albo tak jak w tym przypadku, po prostu delegując sobie pracę do jakiegoś lekkiego agenta, który stoi nam z boku procesu. Natomiast mimo wszystko to jest dalej delegacja tam powiedzmy jakiejś części naszej pracy, do tego powiedzmy tam tu na zboku. No i raczej bym go zostawił po prostu jako taka następna maszynka dookoła naszych narzędzi, która nam pomaga, ale niekoniecznie jaki członek zespołu, który jest jakoś super sam decyzyjny.

SPEAKER_00 9:50

No właśnie, mówimy tutaj o tej personifacji, nie jako prawie że o myśleniu, o AI-igencie, jako właśnie o takim wiesz, na miastę przynajmniej członka zespołu, ale mam wrażenie, że dołączenie nie jako tych algorytmów do zespołu ma większą wagę, większy wpływ niż na przykład dołączenie kolejnego człowieka, co mam na myśli. Chciałbym cię zapytać o to, jak ta zmiana, którą obecnie przechodzimy, wpływa właśnie jak osoby ze sobą współpracują w zespole, co znika z tego takiego klasycznego modelu, powiedzmy, dziesięciosobowego zespołu, z jasno wytyczonymi rolami, jakimiś zasadami współdziałania, kiedy to przechodzimy na właśnie współpracę z agentami, kiedy coraz bardziej spora część członków zespołu jest z takimi full stakami, albo przynajmniej próbuje dotykać różnych jego aspektów. Tak, jak ten klasyczny model zmienia się w momencie, kiedy dodajemy tam ten element agentowości.

Mniejsze zespoły, większa wydajność

SPEAKER_01 10:56

Pierwsza myśl, która tutaj przychodzi, to jest zmiana liczby osób technicznych w zespołe, bo tak jak mówisz, zaczynamy budować dookoła siebie środowisko, które składa się z pewnych narzędzi, które coraz większą część naszej pracy automatyzują. No i jeżeli postawimy sobie takiego pojedynczego dewelopera, który zautomatyzował sporą część swojej pracy powiedzmy, czyli już nie musi pisać dokumentacji ręcznie, bo zrobi to za niego agent. Przy Code Review też to pierwsze powiedzmy, przejrzenie za pomocą jakiegoś innego agenta, też daje mu dużo lepszy ogląd sytuacji tego, gdzie w zasadzie te jego zmiany się znajdują. No i rezultatem tego jest to, że rzeczywiście pojedyncza osoba techniczna jest w stanie dostarczyć więcej w tym samym czasie. Więc to jest tutaj taki fakt, z którym już myślę, że na dzisiejszym etapie ciężko się nie zgodzić. Natomiast to też rodzi pewne problemy właśnie tak jak wychodzimy od tego zespołu dziesięciaosobowego, jeżeli pojedynczy inżynier jest w stanie dostarczyć dużo więcej oprogramowania w tym samym czasie i to są naprawdę przyrosty ogromne mogę powiedzieć, no to jeżeli mamy takich inżynierów w zespole za dużo, to zaczyna się robić problemy z konfliktami. W sensie zaczynamy więcej czasu spędzać nad tym, jak się dogadać i jak rozwiązać, kto jakich części ma dotykać, no bo prędzej czy później i tak dotkniemy tych części wspólnych projektu i pewnie jakieś tam konflikty powstaną. Więc tutaj ta pierwsza rzecz, to powiedziałbym, że zdecydowanie zmiana liczby osób technicznych w projekcie. Więc tutaj tak jak mieliśmy kiedyś takie duże zespoły, gdzie na przykład mieliśmy trzech backendowców, trzech frontendowców i tak dalej, no to myślę, że spokojnie możemy ścinać tę liczbę osób do mniejszej liczby. No i tutaj jest takich też ciekawostek, jeżeli mamy dobrze opracowane te nasze SDD, jeżeli mamy dobrze porobione harnesy, dobrze napisane w skile, no to w zasadzie też z tego, co obserwuje u nas na projektach, nie ma też żadnego większego problemu, żeby przesiadać się między technologiami. W sensie, dotnetowcy spokojnie mogą pisać w Java, driwowcy w dotnecie, w Pythonie i tak dalej, więc tutaj jakby ten próg wejścia i taka powiedzmy, wąska specjalizacja też zaczyna nam w pewien sposób zanikać, jeżeli ten proces mamy powiedzmy dobrze opanowany. No też, jeżeli zmienia się ta liczba członków zespołu, jest mniej osób, nad którymi musimy zapanować, no to wtedy też jest pytanie, czy potrzebujemy tych takich ciężkich procesów agile'owych, do których się przyzwyczaliśmy, czy potrzebujemy scram mastera, ceremonii skramowych i tak dalej, generalnie spędzenia dość dużej ilości naszego czasu na mech. Z tego, co widzę w tych naszych zespołach AI native, to przestaje być potrzebne. Więc jakby te osoby, które dodatkowo jeszcze były narzutem takim koordynującym tę pracę, to można powiedzieć, że one też gdzieś tam z tego obrazka nam zaczynają znikać. Natomiast na obrazku większa waga jest przyłożona do osób, które zbierają biznes, takich jak analitycy, powiedzmy, product rownerzy, to te są takie osoby, które gdzieś tam zaczynają być bliżej deweloperów, a te osoby, które koordynują troszkę zostają z tyłu.

SPEAKER_00 14:52

Oczy, czyli mamy mniejsze zespoły, trochę pod to, aby się gdzieś tam wzajemnie nie pozabijać w zespole, bo do tego to może prowadzić, ale też pewnie do tego, żeby zmniejszyć takie botelny, które się pojawiają tak, jakieś związane z przeglądaniem kodu, czy jakimiś głębszymi decyzjami podejmowanymi, jednak na przykład jednostkowo przez jakiegoś tam architekta takiego białkowego w zespole, no wiadomo, że ta osoba też nie będzie w stanie nadążać za taką ilością przyrostu kodu, które się generuje i tak dalej, i tak dalej.

Koniec wąskich specjalizacji

SPEAKER_00 15:26

Mówiłeś też o tym, że technologia w sensie język programowania może, albo już wręcz staje się wtórny, że z wykorzystaniem tych narzędzi AI możemy swobodnie posiadając pewne podstawy, bo tak gdyby tutaj też trzeba mocno zaznaczyć? W miarę łatwo możemy sobie tutaj migrować i przechodzić, ale jestem ciekawy, jak zmienia się też taki klasyczny model, gdzie mamy właśnie backendowców, frontendowców, jakichś TWOP-ów, tak może programistów aplikacji mobilnych. Jak to się zmienia pod wpływem zastosowania właśnie tego podejścia związanego z agentami AI, czy również te technologie się niejako zacierają, czy za chwilę będzie tak, że będzie tylko jedna specjalizacja pod tytułem Software Engineer, który będzie w stanie to wszystko ogarniać, czy też według ciebie jednak te specjalizacje jeszcze nam są potrzebne?

SPEAKER_01 16:17

Tak, generalnie szedłem w tym kierunku, że w zasadzie będziemy odchodzili od takich powiedzmy wąskich specjalizacji, jak backend engineer, frontend, czy DevOps. Raczej to, co obserwuję, to jest właśnie, i to znowu można powiedzieć, że to jest powrót do tego, z czego historycznie wychodziliśmy, bo historycznie też obserwowaliśmy raczej właśnie inżynierów oprogramowania, którzy byli w stanie dowozić całość softu. No i tutaj wychodzi na to, że w zasadzie zaczynamy wracać do tego modelu. W ostatnim projekcie, który robiłem, właśnie też zrobiliśmy taki eksperyment, i to był projekt, który napisaliśmy samymi dotnetowcami. I to takimi dotnetowcami, których backgroundem głównie był backend development. Więc zrobiliśmy taki właśnie jeden zespół AI Native, no i patrzyliśmy, co dalej się z tym będzie działo. Więc wynik tego był taki, że rzeczywiście ci backendowcy byli w stanie zrobić rozwiązanie całościowe, czyli raz, że zrobili wszystkie serwisy backendowe, dwa napisali frontend i do tego napisali wszystkie pipeliny, jeżeli chodzi o to, jak to resować. W zasadzie całe CICD. Więc tutaj można na pewno zauważyć ten trend, że idziemy w kierunku takich inżynierów, którzy dostarczają bardziej całościowo. No i tutaj w zasadzie jeżeli mamy nawet tych backendowców, ale oni dostaną dobrze skonfigurowane skile, dobrze skonfigurowane harnesy gdzieś tam na podstawie jakiegoś szablonu, który był dostarczony przez ekipę frontu, no to spokojnie, spokojnie mogą sobie poradzić z napisaniem tego systemu całościowo. Także tutaj myślę, że idziemy w kierunku właśnie braku tej wąskiej specjalizacji. No i raczej w kierunku tego, że jesteśmy w stanie dość szeroko patrzeć na problemy.

SPEAKER_00 18:34

Z tego, co tutaj mówisz, myślę gdzieś tam słucham między wierszami, że wypływa też taka myśl, że okej możemy oczywiście skorzystać z tych wszystkich narzędzi, które dają nam możliwości, o których wcześniej pewnie moglibyśmy tylko pomarzyć, ale pewien warunek wstępny zakłada, że musimy mieć jakieś tam doświadczenie, jakąś tam wiedzę, jakieś tam podstawy, tak, żeby, wiadomo, nie generować tylko pustego kodu, tylko żeby to miało jakąś tam sens biznesową i żeby się dało jeszcze z innymi w zespole ciągnąć i realizować, no i pewnie też dalej utrzymywać. Jest potrzebna jakaś wiedza, jest potrzebne jakieś doświadczenie, jakieś już umiejętności, które oczywiście mogą być przenoszalne na inne technologie jak najbardziej, ale gdzieś musimy je zdobyć.

Problem juniorów

SPEAKER_00 19:17

Tu wracamy do czy też wchodzimy w ten problem, który jest nie od pewnego czasu, związany z juniorami, z osobami aspirującymi właśnie ról, na przykład związanych z programowaniem, no i nie ma co ukrywać jednak dużo wyższą barierą, jaka teraz stoi przed tymi osobami. Po części wynika to ze zmian rynkowych, po części wynika z tego, że wiele zadań, które wcześniej były tak dosyć naturalnie delegowane do tych osób, tak jakieś prostsze rzeczy, jakieś tworzenie dokumentacji i tak dalej, i tak dalej, wszystko to możemy teraz bardzo łatwo ograć rozwiązaniami AI. Czy tutaj branża nie strzela sobie trochę w stopę, wycinając niejako ten nowy narywek, no bo z jednej strony, wiadomo, jakaś tam oszczędność, jakieś tam cięcie kosztów, ale z drugiej strony, gdzie te osoby mają też zdobyć niezbędne doświadczenie.

SPEAKER_01 20:10

No tak, rzeczywiście, rzeczywiście jest to pewien problem, który pojawia się coraz częściej i coraz częściej nam wypływa na wierzch. I w zasadzie, jeżeli narzędzia robią za nas wszystko, to po co się czegokolwiek uczyć. I tutaj mam taką fajną anegdotkę odnośnie tego, jak to wyglądało kiedyś z matematykami i z kalkulatorami. W sensie, w 1986 roku w Waszyngtonie, jakaś grupa matematyków zaczęła strajkować właśnie przed wprowadzeniem kalkulatorów, no bo jak wprowadzimy kalkulatory, to oczywiście wszyscy zapomnimy już, jak się liczy. No właśnie. I co się z tym stało dalej? Chodzimy do szkoły i w zasadzie, zanim zaczniemy korzystać z kalkulatorów, no to najpierw uczymy się, jak się liczy powiedzmy na kartce w słupkach. Myślę, że na tym etapie życia, to może już niekoniecznie to robimy i prędzej sięgamy po telefon albo po laptop, żeby coś policzyć. No, ale generalnie, jeżeli chodzi o dzieci i to, jak one się uczą, no to zanim dotknąłem kalkulatora, to najpierw muszą rozumieć to, jak to policzyć powiedzmy bez tego kalkulatora. No i w IT wydaje mi się, że skończymy w tym samym modelu. Ja tutaj akurat jestem bardzo dużym fanem studiów kierunkowych, jeżeli chodzi o obecę IT i rzeczywiście studiowania informatyki najpierw. I wydaje mi się, że w tych czasach, kiedy naprawdę mamy dość dużą łatwość w pisaniu kodu właśnie za pomocą LLMów, no to bardzo. dużą wartość będą zyskiwały osoby, które właśnie na przykład były na studiach i zanim dotknęły LLM-a, to musiały się najpierw nauczyć samodzielnie, jak napisać strukturę danych, jak napisać tam jakieś API i tak dalej, musiały zdać z tego kolokwium i rozumieją, jak to działa pod spodem. Więc na etapie, w którym te osoby powiedzmy, są po studiach i rozumieją, jak to działa bez LLM-ów, no to wtedy też dużo łatwiej jest im ocenić to, co im wyjdzie z tego LLM-a. Więc w zasadzie to chyba zacząłbym od tego, że tutaj idźcie na studia i nauczcie się to robić bez sztucznej inteligencji, bo wtedy ze szczuszną inteligencją też to zrobimy, no a w drugą stronę niekoniecznie to musi tutaj działać. Także ja też nie byłem nigdy jakoś super fanem bootcampów takich trzy miesięcznych, po których szliśmy do pracy. Co prawda, był taki czas w IT, kiedy to było potrzebne, no bo było tak duże zapotrzebowanie, że de facto to szybkie wdrożenie i później praca wpcieczoła na projekcie, no była w stanie nas nauczyć tej pracy. Natomiast teraz, jeżeli mamy te nasze procesy bardzo mocno zautomatyzowane, no to mimo wszystko dobrze już wchodzić z jakąś taką wiedzą odnośnie tego, jak to tutaj działa. No i powiedziałbym, że dobrym krokiem jest po prostu nauczenie się tego najpierw na sucho i dopiero później wskoczenie w głęboką wodę. Nie wiem, czy się na ile to jest realne w dzisiejszych czasach, ale tak bym chciał, żeby to wyglądało. I na przykład, jakbym ja szukał jakiegoś juniora do mojego zespołu, no to właśnie w takim kierunkowym porze. W sensie najpierw bym chciał zobaczyć, czy on jest w stanie sobie poradzić z problemem bez LAM-a, a dopiero później dać mu te narzędzia już dalej do ręki, żeby pracował bardziej efektywnie.

SPEAKER_00 23:59

No tak wydaje się to bardzo rozsądne podejście.

Kod z AI a zrozumienie systemu

SPEAKER_00 24:03

Wiesz, słyszałem niedawno o takim podejściu, czy też dwóch podejściach do tego, w jaki sposób interpretujemy, czy w ogóle patrzymy na ten kod wygenerowany przez AI, przez LLMy. Jedni delegują pewne zadania do RLM-a, ale później staram się gdzieś tam jednak to przejrzeć, zrozumieć, zweryfikować, a inni dosyć ślepo wierzą, że to jest dobre, wystarczająco dobre i idą dalej. No i oczywiście w tym drugim przypadku naturalnie z biegiem czasu, z biegiem miesięcy, na przykład pracy nad projektem, no brak jest później zrozumienia tego, w jaki sposób pewna architektura, czy pewien design tego kodu w ogóle wygląda. No i pojawia się takie pytanie, tak, gdy nagle będzie jakaś duża awaria na produkcji, obudzą cię o trzeciej w nocy, tak? I wygenerowałeś większość kodów za pomocą LLM-a, to czy będziesz wiedział, jak to jest wewnątrz zbudowane, jak to działa, jakie są zasady działania tego projektu, czy będziesz w stanie szybko zareagować. No i też może takie drugie pytanie do tego, czy to w ogóle jest potrzebne, tak? Czy tutaj jest to w ogóle problem, że my nie do końca rozumiemy de facto, jakie są te elementy skodowe, w jaki sposób części projektu ze sobą współpracują?

SPEAKER_01 25:22

Tak, to jest często podnoszony problem, szczególnie przez takich powiedzmy, AI-sceptyków, którzy dość długo pracują w jednym projekcie, znają ten projekt, po prostu z każdej strony, każdą klasę wiedzą o nim wszystko. No i rzeczywiście to są to osoby, które często pytają właśnie. No dobra, no ale jak nie znasz tego systemu, no to jak go poprawisz, jeżeli właśnie coś o tej przysłowej trzeciej w nocy się nam wywali. No i teraz tak, to jest prawda, że jeżeli piszemy sobie w tym Spec Driven Development i nie spędzamy tych długich tygodni na implementacji poszczególnych rozwiązań, no to to nam wylatuje z głowy. I tak jak mamy takiego programistę, który właśnie w SDG sobie dewelopuje, no to jak go zapytamy tydzień po tym, jak zaimplementował daną funkcjonalność, to on jeszcze będzie coś z tego pamiętał. Natomiast jak go zapytamy o to samo sprzed trzech tygodni, no to jest duża szansa, że już nie za bardzo będzie wiedział, jak to dokładnie wyglądało. No i to powiedzmy, jest jakiś tam problem z perspektywy tego, co wiemy o naszym projekcie. Z drugiej strony, jeżeli ten nasz projekt jest napisany dobrze, jest zrobiony dobrem SD, czyli cała specyfikacja, wszystkie plany implementacji i tak dalej wylądowały w naszym repozytorium, no to taka osoba może nie pamiętać tego, co tam dokładnie było, ale jest w stanie dość szybko sobie odtworzyć, co tam się działo i jest to wszystko dość dobrze udokumentowane i łatwe do zrozumienia dla takiego programisty, który w to wchodzi. No i tutaj też troszkę wtedy zmniejszamy w ogóle barierę przechodzenia między projektami, no bo jeżeli te projekty są ustandaryzowane podobnie, no to łatwiej się nam w takie projekty wtedy wdrożyć. No i tutaj możemy sobie wrócić do tych takich właśnie historycznie w zasadzie półbogów w projekcie, do których zawsze dzwoniliśmy o 3 w nocy, żeby nam coś naprawili, jeżeli się wysypało. No i to jest też pytanie, czy to jest w ogóle dobre z punktu widzenia organizacji, no bo tak naprawdę ta osoba jest dla nas bardzo dużym ryzykiem, jeżeli coś by się stało, albo jeżeli zechciałaby zmienić pracę, no to w zasadzie wtedy, jeżeli nie mamy tego SDD, no to zostawiamy system, którego nikt nie zna i do którego jest bardzo trudno wejść, więc to jest bardzo zasadne pytanie z punktu widzenia organizacji, czy my możemy sobie pozwolić właśnie na takich główów w projektach, którzy wiedzą o nich wszystko, a nie zapewniać tego łatwego wejścia w to, co tam naprawiamy. Z drugiej strony, z perspektywy takiej osoby, no ja wiem, że to też może być różnie, bo różni ludzie preferują różne metody pracy. Natomiast jeżeli taki człowiek chciałby wyjść z projektu, w którym spędził powiedzmy ostatnie 10 lat, no to też oczywiście nic tak łatwo z tego projektu go nie wypuszcza, no bo ma całą wiedzę. A z drugiej strony, może on już tego 11 roku nie chce tam spędzić i chciałby w końcu zrobić coś innego. Więc jakby. Podsumowując, jest to jakiś problem, w sensie, że wiemy o tych systemach mniej, natomiast z drugiej strony, jest nam się dużo łatwiej w takie

Nowy obraz dobrego programisty

SPEAKER_01 28:59

systemy wdrożyć.

SPEAKER_00 29:00

Mam wrażenie, że stoimy trochę przed taką zmianą paradygmatu tego, jak właściwie widzimy, jak opisujem tak zwanego dobrego programista, osobę, która tak jak tutaj mówiłeś w tych czasach wcześniejszych była wybitnym specjalistem, wybitnym specjalistą często wąskiej gdzieś tam w dziedzinie, tak, z jednego projektu, być może z jakiegoś obszaru tego projektu, znała go na wylot, i tak dalej. Teraz troszkę ten obraz się nam zaciera, tak? Dobry programista to niekoniecznie musi być właśnie ten, który idealnie zna, rzemiosło, potrafi Quick Sorta z pamięci napisać i wszystkie tam najnowsze wersje bibliotek ma w paluszku. Czy AI tutaj, albo w jaki sposób AI właśnie redefiniuje nam pojęcie dobrego programisty?

SPEAKER_01 29:48

No właśnie, bo tak jak mówisz, jeżeli sobie pomyślimy tak powiedzmy, historycznie, o tym, kim jest dobry programista, no to właśnie pierwsza osoba, która nam przychodzi do głowy, to jest właśnie ten człowiek, który wie o projekcie wszystko, albo wie o technologii wszystko, czyli innymi słowy, człowiek, który jest bardzo sprawny technologicznie. To myślę, że to jest takie pierwsze skojarzenie. No i właśnie, i ten środ troszkę się nam zmienia, bo technologia zaczyna schodzić na drugi plan. Ja tutaj sam się często zaskakiwałem to jeszcze 3-4 lata temu, jak robiłem pierwsze eksperymenty z kopajlotem, jak szybko jestem w stanie rozwiązać problemy, nad którymi kiedyś siedziałbym dużo czasu, właśnie od strony takiej tylko i wyłącznie technologicznej, więc tutaj jakby ta wartość zaczyna się zmniejsza. Natomiast zaczyna się zwiększać wartość osób trochę z drugiego biegu. No, może nie powiedziałbym, że zupełnie. Natomiast tutaj myślę o tych ludziach, którzy dobrze rozumieją domenę biznesową i dobrze rozumieją w ogóle to, co mamy robić jako nasz biznes. I tutaj znowu ta osoba, która spędziła ostatnie 10 lat budując daną domenę biznesową, no to może być właśnie świetny przykład programisty, który bardzo dobrze rozumie to, co buduje. I myślę, że właśnie o tych ludziach teraz będziemy mówili dobry programista. Czyli generalnie o człowieku, który zna biznes, potrafi się ewentualnie z biznesem dogadać, potrafi z osób powiedzmy takich biznesowych wyjąć to, co konkretnie mamy zbudować. No i przełożyć na technologię. Więc on tak czy inaczej trochę z tej technologii musi rozumieć, ale może nie aż tak dużo jak kiedyś, a z kolei myślę, że tutaj to rozumienie domeny i rozumienie biznesu, to myślę, że będzie coś, co będzie na pewno definiowało dobrych programistów w przyszłości. Zresztą historycznie definiowało też dobrych programistów w przeszłości, no bo zazwyczaj, jeżeli ktoś znał i technologię i rozumiał bardzo dobrze domenę, no to też był takim powiedzmy bardzo mocnym punktem naszego zespołu od zawsze.

SPEAKER_00 32:08

Mam tutaj w tym temacie relacji międzyludzkich w zespołach Haiti taki lekki dysonans, bo z jednej strony absolutnie zgadzam się z tym, co powiedziałeś, że ta znajomość domeny biznesu, umiejętności, komunikacji, wyciągnięcia właśnie tych rzeczy, których nam gdzieś tam brakuje jako osobom technicznym, to jest absolutnie kluczowe. A z drugiej strony, ten trochę nowy model pracy, kiedy pracujemy bardzo indywidualnie z elementami, kiedy jesteśmy w stanie dużo więcej z takim naszym sparing partnerem cyfrowym spraw załatwić niż jak to było wcześniej, kiedy właśnie przy tej przysłowiowej kawie w kuchni coś tam obgadywaliśmy? Z drugiej strony pojawia się taki obraz programisty, może nie znowu zamkniętego w piwnicy, ale mimo wszystko pracującego indywidualnie, spędzającego dużo więcej czasu z maszyną, a nie z drugim człowiekiem. Więc jak to według Ciebie jest tymi relacjami międzyludzkimi teraz w tej dobie AI, w IT zyskują na znaczeniu, czy może

Relacje w erze AI

SPEAKER_00 33:12

tracą?

SPEAKER_01 33:12

Dobra, Krzysiek. Więc zacząłbym od tego, że one zawsze były ważne i stają się jeszcze ważniejsze niż były. No i wynika to z tego, że generalnie to budowanie oprogramowania jest teraz dużo szybsze, więc ta technologia schodzi nam na dalszy plan, no i jak technologia schodzi nam na dalszy plan, to w zasadzie musimy zacząć częściej rozmawiać, no bo jeżeli ta faza implementacji, tak jak historycznie sobie o tym pomyślimy, dostawaliśmy jakieś wymagania od analityka, albo od jakiegoś product ownera. No i w zasadzie, jeżeli programowaliśmy jakiś tam boilerplate przez dwa tygodnie, no to mieliśmy też czas na to, żeby doprecyzować te wymagania w międzyczasie, a programista sobie siedział i te dwa tygodnie dłobał właśnie w tej swojej przysłowiowej jaskini. No i teraz tak, programista już nie długie tego przez dwa tygodnie, bo dowozimy oprowo szybciej. Co zatem idzie, on częściej musi rozmawiać z tymi ludźmi. No bo jeżeli zrobił powiedzmy jakąś funkcjonalność w dwa dni, a nie w dwa tygodnie, to musi znowu do tego biznesu wrócić i znowu z nimi rozmawiać o tym, co dalej będziemy implementowali. Więc tutaj jakby, no jakby jesteśmy bliżej, powiedzmy siebie, jeżeli chodzi o te osoby techniczne i biznesowe. No, a jeżeli chodzi o osoby techniczne, no to fakt może mniej czasu spędzamy nad tym, nad jakimi błędami konkretnie siedzimy, ale możemy więcej czasu spędzić nad tym, jak usprawniliśmy nasz proces albo co fajnego zaimplementowaliśmy. Więc tutaj nie powiedziałbym, że te relacje międzyludzkie powiedzmy, byłyby mniej ważne niż kiedyś. Wydaje mi się, że to jest nawet w kierunku pozytywnego wpływu, no bo mniejszy mamy powiedzmy ten fokus na technologię, a większy na to, co my tak naprawdę chcemy zrobić z tymi ludźmi, więc mi się wydaje, że to jest pozytywny wpływ.

SPEAKER_00 35:30

Okej, nie wiem, czy się ze mną zgodzisz, ale tak z mojej obserwacji wynika, że coraz więcej czasu jednak spędzamy, pracując samodzielnie, tak gdyby powiedzieć pojedynkę nad jakimś problemem. I zastanawiam się, czy to nie powoduje takiego ujemnego tutaj wpływu, negatywnego wpływu na to, że tracimy taki nieformalny transfer wiedzy w zespołach, tak? Te wszystkie gdzieś tam, nie wiem, rozmowy przy kawie, w kuchni, jakieś burze mózgu przypadkowe, i tak dalej. Jakieś odkrycia, jakieś ciekawe uwagi, które w ten sposób powstawały, które nie jako albo nierzadko przyczyniały się do powstawania ciekawych rozwiązań w projekcie, tutaj mam wrażenie, że troszkę tracimy właśnie tego aspektu działania zespołów IT. Nie wiem, czy tak też wynika z Twojej obserwacji, nie wiem, czy według Ciebie to jest problem, czy niekoniecznie.

Zespół bez kuchennych rozmów

SPEAKER_01 36:24

Tak jest. Wydaje mi się, że tak jest. I nie wydaje mi się, że by był to problem, jeżeli tak mogę o tym powiedzieć. Więc jak sobie weźmiemy ten nasz ekspres w kuchni i to o czym rozmawialiśmy przy Ekspresie kiedyś, no to rzeczywiście więcej czasu spędzaliśmy nad technologią i nad tym, jakie mamy problemy. I na przykład, jeżeli od tygodnia nie jesteśmy w stanie rozwiązać jakiegoś problemu na przykład z garbycz kolektorem, no to pewnie będziemy szukać tego rozwiązania po kolegach dookoła i pytać, czy mieli może taki problem, albo jak już nam się uda go rozwiązać, to pójdziemy się pochwalić, w jaki sposób rozwiązaliśmy ten problem. No i tutaj ten temat przyznam szczerze, że troszkę nam zastępuje AI, no bo w zasadzie z tymi LRM-ami jesteśmy w stanie dużo szybciej dotrzeć do rozwiązań takich problemów, więc jeżeli ja nie spędziłem nad tym 5 dni, tylko powiedzmy dwie godziny, no to nie zapada mi to na tyle w pamięci, żebym chciał się jakoś super tym pochwalić powiedzmy przykawie. Więc powiedzmy, że tracimy rozmowę o takich detalach technologicznych. Natomiast wydaje mi się, że z drugiej strony zyskujemy rozmowy na wyższym poziomie abstrakcji, czyli co konkretnego udało nam się zrobić, jaką funkcjonalność zrobiliśmy ostatnio, jaki projekt ostatnio zrobiliśmy. Wię powiedział, że może przestajemy rozmawiać o szczegółach implementacyjnych, natomiast spokojnie dalej rozmawiamy sobie o rozwiązaniach, jakie dostarczamy, więc finalnie powiedziałbym, że sprowadza się to mniej więcej do tego samego, tylko może na troszkę wyższym poziomie

Biznes staje się wąskim gardłem

SPEAKER_01 38:14

abstrakcji.

SPEAKER_00 38:14

No to jeśli wytwarzanie software'u, jeśli jego generowanie ten proces dewelopentu przyspieszył tak bardzo, to co według ciebie jest teraz tym największym problemem, jeśli chodzi o zespoły IT, czy to nadal jest technologia, czy może ten przysłowiowy biznes, który nam cały czas gdzieś tam mąci i zmienia pierwotnie podjęte decyzje, czy może komunikacja, może Leadership, co według Ciebie jest tą następną rzeczą, która powinna być ulepszona, by zespoły działały jeszcze lepiej?

SPEAKER_01 38:45

Z tego, co obserwuję, to powiedziałbym, że tym batłunekiem właśnie przestaje być technologia, a zaczyna być jeszcze bardziej biznes. Znowu nie znaczy, że historycznie nie był to problem, bo oczywiście historycznie tutaj często tak czy inaczej się z tym problemem spotykaliśmy. Natomiast wydaje mi się, że on nam wyszedł bardziej na pierwsze plany. No bo jak sobie weźmiemy taki zespół deweloperski, który dostarcza oprogramowanie bardzo szybko, no to ten backrock szybko nam się kurczy, więc w zasadzie to mamy ryzyko w drugą stronę, że po prostu nam się backlok i dopóki nowe wymagania nie zostaną doprecyzowane, a decyzje biznesowe w co wchodzimy, a w co nie, nie zostaną podjęte, to zespół może stać w miejscu i się nudzić. Natomiast tutaj też z kolei w drugą stronę bym czasem powiedział, to, co obserwuję i to, co mnie zaskoczyło właśnie, jak obserwowałem takie projekty AI native, to jest to, że paradoksalnie możemy mieć paraliż decyzyjny. Bo jak produkt onerzy i ogólnie nasz biznes widzi jak szybko te rozwiązania dostarczamy, to paradoksalnie ten background zaczyna nam puchnąć i zaczynamy być zasypywani rzeczami, o których wcześniej nie myśleliśmy, albo których się nie podejmowaliśmy, no bo powiedzmy koszt napisania takiego kawałka był niewspółmierny z wartością, jaką dostarczyć a teraz jak widzę po tych osobach, które właśnie zarządzają biznesem i patrzą na to, jak szybko ten biznes tutaj od strony technologicznej rośnie, no to mają więcej chęci do tego, żeby robić rzeczy, których powiedzmy wcześniej byśmy w ogóle nie zrobili, bo na przykład szkoda byłoby nam czasu zespołu na implementację czegoś, co zamier nam na przykład trzy miesiące, bo mamy inne priorytety, a pewnie Krzysiek, jak dobrze wiesz, z biznesem jest tak, że oczywiście wszystko jest najbardziej ważne i wszystko ma największy priorytet zazwyczaj. No i ten backlock po prostu, zamiast nam szybko omać, to okazuje się, że zaczyna nam puchnieć szybciej niż widzieliśmy

Nowa rola seniora

SPEAKER_01 41:04

to kiedyś.

SPEAKER_00 41:05

No tak, to wszystko, prawda. Mówiliśmy chwilkę o juniorach, to może warto też słowo zamienić o seniorach. No bo myślę sobie, że skoro Jaj pisze kod, testuje go, tak, rewuje, to jak właściwie zmienia się ta rola seniora, tak? Czy on staje się bardziej takim kuratorem jakości całego projektu niż twórcom, a może jeszcze w jakiś innych kierunkach, właśnie ta rola podąża?

SPEAKER_01 41:28

Tak to powoli zaczyna wyglądać. Muszę powiedzieć, że chyba niestety, bo rzeczywiście, jeżeli mamy dobrze opracowany proces, w którym dużo rzeczy dzieje się automatycznie i w zasadzie my tutaj też WGFT idziemy w kierunku tego, żeby budować jak najszerszy standard, czyli jak wytwarzamy sobie to oprogramowanie w Spec Driven Development, no to staramy się, żeby te projekty wyglądały mniej więcej tak samo, i żeby je korzystać z jednego takiego ujednoliconego standardu. No i to nam trochę jako tym seniorom zabiera ten taki, myślę, że swoją drogą najfajniejsza część, najfajniejszą części budowania oprogramowania, czyli ten aspekt twórczy. I aspekt tego właśnie myślenia o tym, jak to powinno wyglądać, jaka tutaj powinna być architektura i tak dalej. Zamiast tego myślenia powiedzmy, w sposób taki samodzielny, no to dostajemy standardy i zaprawdę, czasem może być potrzeba tego, żeby taki standard dopasować do sytuacji projektowej, bo projekt tego z jakiegoś względu wymaga. Natomiast rzeczywiście bardziej zaczynamy patrzeć, czy nic nam się nie rozjechało i czy wszystko jest zgodne z tym, jak to powinno wyglądać. No, niż tam powiedzmy, tworzyć. Tej pracy twórczej wydaje mi się, że no tutaj niestety, mamy coraz mniej, ale chyba trzeba będzie z tym

Odpowiedzialność za błędy AI

SPEAKER_01 42:59

żyć po prostu.

SPEAKER_00 42:59

Też tak myślę. A jak podchodzicie do odpowiedzialności, tak, kiedy agent gdzieś popełni baga, coś źle zinterpretuje, to kto właściwie wybierze za to odpowiedzialność, tak? Dana osoba, która prowadziła konwersacje z AI agentem, czy może cały zespół, czy może lider?

SPEAKER_01 43:20

No to chyba zależy, jak wysoka eskalacja dotrze. Dyplomatycznie. Tak, ale z grubsza powiedziałbym, że generalnie tak czy inaczej odpowiedzialność jest na człowieku, który wpuszcza ten kawałek kodu do repozytorium. No bo jak robimy sobie tam powiedzmy jakiegoś Merge requesta, no to swoim imieniem i nazwiskiem autoryzujemy, że ten kod został przez nas przejrzany i my naszym zdaniem jesteśmy OK, żeby wpuścić ten kod do naszego repozytorium. Więc jakby No, dostajemy dużo kodu, powiedzmy, od agentów, dużo więcej niż widzieliśmy historycznie. Natomiast tutaj ta odpowiedzialność myślę, że w dalszym ciągu jest na człowieku i na koniec z dnia to człowiek się podpisuje pod tym, że to, co mu wyszło z tych wszystkich narzędzi dookoła niego, no to on jest okej z tym, żeby to weszło do naszego

Leadership w świecie agentów

SPEAKER_01 44:29

repozytoria?

SPEAKER_00 44:30

Rozumiem. Mówiąc o zespołach IT, też trzeba powiedzieć o liderach, tak? Jak zmienia się leadership w tej sytuacji, kiedy mamy, powiedziałbym, część kodu tworzonego przez ludzi, część gdzieś tam rozwiązań wytwarzanych w sposób automatycznie. Czy lider nadal zarządza tylko ludźmi, którzy mają do swojej dyspozycji właśnie tego typu narzędzia, czy też może lider w tym momencie zarządza już nie tylko ludźmi, ale również agentami AI?

SPEAKER_01 45:01

Tutaj rola lidera wydaje mi się, że aż tak bardzo się nie zmienia. No bo tutaj, jak sobie myślimy o tych rolach liderskich, no to myślimy sobie gdzieś tam właśnie bardziej o ludziach, o odpowiedzialności za ludzi, o odpowiedzialności za procesy i tak dalej. I tutaj wydaje mi się, że ta praca lidera aż tak bardzo się nie zmienia, no bo lider też pracuje głównie z ludźmi, a nie z technologiami. Co prawda, on może definiować, w jaki sposób nasz proces wygląda, i to jest niezależnie od tego, czy ten proces w sobie zawiera AI, czy nie zawiera AI. Więc wydaje mi się, że ta rola lidera jakoś bezpośrednio nie zmienia się, jego praca się nie zmienia. Powiedziałbym, że jego tempo pracy się może zmieniać. No bo jeżeli mamy te AI native zespoły, to powiedzmy, że w dwa lata lider jest w stanie dostarczać pięć projektów, a nie dwa, więc jakby tutaj powiedzmy, jest większe tempo, jest bardziej dynamicznie, może trochę więcej się dzieje. Natomiast nie powiedziałbym, że sama w sobie ta praca lidera jakoś bardzo się zmienia w tym kontekście?

Jak wejść w model AI Native

SPEAKER_00 46:14

Jasne. A pasując o Twoim doświadczeniu właśnie z zespołami AI Native. Jakie rady, jakie porady dałbyś komuś, kto nie wiem, zarządza na przykład Software Houseem albo jakimś zespołem IT i chciałby właśnie przejść w kierunku pracy w ten sposób, to co powinien zmienić tym swoim starym, klasycznym systemie pracy, aby zbliżyć się właśnie do modelu AI Native?

SPEAKER_01 46:39

Myślę, że zacząłbym w ogóle przede wszystkim od inwestycji najpierw w ludzi, a nie w narzędzia. No bo narzędzia dzisiaj to nam się zmieniają praktycznie co miesiąc, natomiast to, co w ludziach zostaje, to jest ta umiejętność współpracy z AI, rozumienie, jak pracować z technologią, rozumienie tego, jak wytwarzać oprogramowanie właśnie ze specyfikacji. No i przyznam szczerze, że to nie jest, powiedzmy, że to się staje standardem, natomiast to też nie jest tak, że wszyscy w naszych organizacjach już są na tym etapie, żeby rozumieć, jak to się robi w ten sposób. Więc wydaje mi się, że jeżeli miałbym podejść do software house, to zacząłbym od tego, żeby na pierwszym miejscu przeszkolić ludzi, żeby ludzie wiedzieli, jak dobrze pracować z Jajem i wtedy też od razu jesteśmy w stanie skasować takie dyskusje na zasadzie, no bo wiecie, bo ja to próbowałem z tym LLM-em sobie coś napisać, powiedziałem mu, żebym mi napisał aplikację, a on mi nie napisał. Więc ja i to się niczego nie nadaje. To myślę, że zacząłbym tutaj od tego. Jak już miałbym tych ludzi powiedzmy, przeszkolonych, no to warto byłoby zacząć, przedstawiać ten standard wytwarzania oprogramowania, żeby rzeczywiście zacząć wytwarzać to oprogramowanie zgodnie ze Spec Driven Development i zgodnie z tym, co ci ludzie umieją, zbudować sobie jakieś takie reużywalne może narzędzia, agenty, które można postawić w zespołach i które pomagają to oprogramowanie w tej naszej nowej metodzie dowodzić. Więc to powiedzmy, powiedziałbym, że to jest drugi krok, czyli właśnie trochę przedstawienie metody pracy na projektach, i tutaj też z mocnym skupieniem się, żeby ułatwiać wdrożenia nowych ludzi w projekty, no ale to nam powiedzmy w jakiś sposób też zapewnia trzymanie tego standardu SGD. No, i po trzecie, tutaj chyba ten ostatni etap, czyli zacząłbym po prostu budować troszkę mniejsze zespoły z troszkę większą odpowiedzialnością niż było to historycznie, czyli jak mieliśmy kiedyś jakiś tam system, który był utrzymywany powiedzmy przez 3-4 zespoły, no to może spróbowałbym tutaj podejść do tego, żeby przedstawić metodę pisania oprogramowania właśnie na ten kierunek AI natative i może bym tutaj zaczął iść w kierunku tego, że taki projekt może być dostarczony dwoma zespołami, a niekoniecznie trzema-czterema.

Zespół przyszłości

SPEAKER_00 49:27

To jak sobie wyobrażasz taki zespół powiedzmy za kilka lat, tak? Ile tam będzie osób, jakie role będą, ilu agentów, w którym kierunku myślisz, że będzie to się zmieniało?

SPEAKER_01 49:40

No to tutaj to oczywiście zależy od tego, o jak dużym projekcie mówimy. Natomiast jeżeli sobie myślę o takich samowystarczalnych zespołach, które są w stanie całościowo dowodzić oprogramowanie, no to powiedziałbym, że na pewno chciałbym mieć na froncie tego zespołu jakiegoś lidera. Tutaj jest taka koncepcja osób, które nazywamy Forward Deployed Engineerami, więc tutaj widziałbym takiego powiedzmy lidera zespołu, pracującego dość blisko analityka biznesowego, które pomaga mu wyciągać biznes z tych ludzi, którzy na przykład nie są do końca techniczni, no bo tutaj historycznie wiemy o tym, że programiści może nie są tymi najlepszymi ludźmi do wyciągania biznesu z osób nietechnicznych, więc jakby takie wsparcie myślę, że tutaj by się przydało. Także te dwie osoby, dwóch, trzech inżynierów, i tutaj, tak jak o tym rozmawialiśmy, tych właśnie takich inżynierów oprogramowania, czyli osoby, które potrafią całościowo dostarczać rozwiązania end-to-end, czyli i aspekty DevOpsowe, i front-end i backend. Myślę, że bardzo ważny obecnie jest też tester w zespole. I tutaj ta rola testera też troszkę się zmienia, bo bardziej myślę sobie o testerze automatyzującym. Więc ci testerzy manualni powiedzmy, mogą nie nadążyć nad testowaniem tego, jak szybko ten zespół dowozi nowe funkcjonalności. A z drugiej strony zespół, który produkuje tak dużo kodu, musi być bardzo dużo, bardzo dobrze zabezpieczony od drugiej strony, czyli ten tester idący zespołem musi budować testy regresyjne, które dają nam odpowiedź po wrzuceniu nowego feature, czy cała reszta dalej działa tak, jak powinna, więc myślę, że to jest taki dość istotny aspekt. No i pytanie, czy potrzebujemy jeszcze kogoś do koordynacji, typu jakieś tam osoby nietechniczne, PMO itd. To bym powiedział, że silnie zależy. Tak na pierwszy rzeczka wydaje mi się, że poradzimy sobie bez tego. Więc tak podsumowując, tu jakiś dobry lider, analityk, dwóch, trzech inżynierów, tester i myślę, że w takim składzie spokojnie jesteśmy w stanie dość dużą część naszych aplikacji albo kawałków, systemów po prostu

Dokąd zmierza wytwarzanie software'u

SPEAKER_01 52:24

dostarczać.

SPEAKER_00 52:25

Myślę, że z wielkim zainteresowaniem będziemy obserwować, jak to nowe podejście do wytwarzania software'u, produktu będzie się jeszcze zmieniało, patrząc na to, że to zaledwie kilka lat, kiedy właśnie LLMy tutaj nam przejmują i zmieniają to, w jaki sposób wytwarzamy software. No to ciężko aż sobie wyobrazić, gdzie będziemy za 5 czy 10 lat. Ciekawa i fascynująca podróż, myślę, przed nami. Moim waszym gościem był dzisiaj Bartosz Wjałkowski z KRT. Barku, bardzo ci dziękuję za tą rozmowę.

SPEAKER_01 53:00

Dziękuję Ci bardzo, Krzysiek. Bardzo miło było sobie tutaj porozmawiać.

SPEAKER_00 53:06

Cieszę się bardzo. Powiedz jeszcze na koniec, gdzie Cię możemy znaleźć w internecie.

SPEAKER_01 53:10

Myślę, że takim pierwszym źródłem kontaktu to będzie mój LinkedIn, więc w zasadzie Bartosz Fiałkowski z GFT można mnie tam dość łatwo znaleźć. Ewentualnie, jeżeli ktoś LinkedIn'a nie ma, to w zasadzie można też do mnie się odzywać mailem. Tutaj imię.nazwisko małpa GFT.com. Moje nazwisko nie jest może takim najprostszym do werwalizowania powiedzmy, ale na pewno Krzysiek gdzie się tutaj podrzuci, więc spokojnie można się odzywać. No i ja oczywiście, jeżeli ktoś chce porozmawiać o AI native w developmencie, to zawsze chętnie swój czas na to poświęcę i zawsze chętnie porozmawiam.

SPEAKER_00 53:56

Dokładnie i wszelkie oczywiście namiary będą w dodatce do odcinka. Bartku, jeszcze raz wielkie dzięki udanego dnia i do usłyszenia. Cześć.

SPEAKER_01 54:03

Dzięki Krzyszik, cześć.

SPEAKER_00 54:04

To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach albo mailowo na krzyżmałpazmawiajmyit.pl. Nazywam się Krzysztof Kępiński, a to był odcinek porozmawiajmy IT o agentach AI w zespołach IT. Dzięki za wspólnie spędzony czas i do usłyszenia w kolejnym odcinku. Cześć.