Krzysztof:
To jest 319 odcinek Porozmawiajmy IT. Dziś rozmawiamy o agentach AI jako części zespołu 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 bez widełek, to zajrzyj na Solid Jobs. Tam wszystko jest na tacy. Wynagrodzenie, technologie, projekty. Bez zgadywania. Nazywam się Krzysztof Kempiński, tworzyłem ten podcast, napisałem też książkę Marka Osobista w branży IT. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej albo zostaw ocenę w swojej awce. 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 Bartosz Fijałkowski. Cześć Bartku, bardzo miło mi gościć w podcaście.

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

Krzysztof:
A przed nami ciekawa, interesująca rozmowa o temacie, który już trochę dzieje się teraz, Czas 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ą.

Bartek:
No to tak, Krzysiek, 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 auta do pociągu i jak już jestem w tym pociągu, to niestety częściej na biurku przede mną ląduje 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ę, więc z tego rodzimego podwórka to na pewno porozmawiajmy o IT, bardzo lubię też DevTalk Maciej Kanisterowicza Maciej Kanisterowicz jest ex.netowcem, tak samo jak ja, więc tutaj mamy pewną nić porozumienia.

Bartek:
I lubię go też posłuchać Co prawda DevTalk 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ę, no to też oczywiście bardzo chętnie ich zawsze posłucham. Z zagranicznych podcastów to .net rocks, tutaj oczywiście idą z tym samym trendem, dotnetowym, z Richardem Campbellem i Karlem Franklinem. Nie będę się chyba rozwijał, o 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 Joe Rogan, jak mam ochotę na coś takiego, co w ogóle nie jest związane z branżą. Więc z grubsza wygląda to tak.

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

Krzysztof:
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 niejako do zespołu, a co jeszcze leży trochę w domenie przyszłości, w domenie science fiction?

Bartek:
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 Jiry, wytwarzał kod. Jak czegoś nie będzie wiedział, no to dopyta analityka na Teamsach. 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, no to w zasadzie możemy sobie porozmawiać o czymś.

Bartek:
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, 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 itd.

Bartek:
No i tutaj na przykład w naszym procesie mamy to ograne 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.

Bartek:
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 promptu 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.

Krzysztof:
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, quasi-członku zespołu, czy też może nadal traktujemy to jako algorytm, jako zaawansowane narzędzie?

Bartek:
Wiesz co, tak jak ja sobie o tym myślę, to jednak mimo wszystko dalej powiedziałbym, że jest to po prostu po prostu bardziej zaawansowane narzędzie i jakieś 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 JetBrains. Trochę się do tego przyzwyczailiśmy, zresztą ja też swoją drogą bardzo lubiłem te 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 ID, no albo tak jak w tym przypadku, no po prostu delegując sobie pracę do jakiegoś lekkiego agenta, który stoi nam z boku procesu. Natomiast no mimo wszystko to jest dalej delegacja tam powiedzmy jakiejś części naszej pracy, do tego powiedzmy tam tula z boku. No i raczej bym go zestawił 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 samdecyzyjny.

Krzysztof:
Mówimy tutaj o tej personifikacji, niejako prawie o myśleniu, o AI-agencie jako o takim namiastu przynajmniej członka zespołu, ale mam wrażenie, że dołączenie niejako 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 10-osobowego 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 takimi full stackami, albo przynajmniej próbuje dotykać różnych jego aspektów.

Krzysztof:
Jak ten klasyczny model zmienia się w momencie, kiedy dodajemy tam ten element agentowości?

Bartek:
Pierwsza myśl, która mi tutaj przychodzi, to jest zmiana liczby osób technicznych w zespole. No 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, no bo zrobi to za niego agent. Przy Code Review też to pierwsze 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ęcioosobowego, No a 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ć.

Bartek:
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 back-endowców, trzech front-endowców i tak dalej, no to myślę, że spokojnie możemy ścinać tę liczbę osób do mniejszej liczby.

Bartek:
No i tutaj jest takich też ciekawostek, jeżeli mamy… Dobrze opracowane to nasze SDD, jeżeli mamy dobrze porobione harnessy, dobrze napisane w skile, no to w zasadzie też z tego, co obserwuję u nas na projektach, nie ma też żadnego większego problemu, żeby przesiedlać się między technologiami. W sensie dotnetowcy spokojnie mogą pisać w Javie, Javowcy 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 i 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ę przyzwyczailiśmy, czy potrzebujemy Scrum Mastera, ceremonii scrumowych i tak dalej, i generalnie spędzania dość dużej ilości naszego czasu na meetingach.

Bartek:
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 te prace, no 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 ownerzy, no to to są takie osoby, które gdzieś tam zaczynają być bliżej deweloperów, no a te osoby, które koordynują troszkę zostają z tyłu.

Krzysztof:
Okej, czyli mamy mniejsze zespoły, trochę po 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 bottlenecki, które się pojawiają, 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. Ale wiadomo, że ta osoba też nie będzie w stanie nadążać za taką ilością przyrostu kodu, który się generuje itd.

Krzysztof:
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 to jakby tutaj też trzeba mocno zaznaczyć, w miarę łatwo możemy sobie tutaj migrować i przechodzić. Ale jestem ciekawy, jak zmienia się też taki klasyczny, gdzie mamy właśnie back-endowców, front-endowców, jakichś DevOpsów, 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?

Bartek:
Tak, generalnie szedłbym 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.

Bartek:
W ostatnim projekcie, który robiłem, właśnie też zrobiliśmy taki eksperyment.

Bartek:
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 back-endowe, dwa, napisali front-end i do tego napisali wszystkie pipeliny, jeżeli chodzi o to, jak to releasować, 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 back-endowców, ale oni dostaną dobrze skonfigurowane skille, dobrze skonfigurowane harnessy gdzieś tam na podstawie jakiegoś szablonu, który był dostarczony przez ekipę frontu, no to 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.

Bartek:
No i raczej w kierunku tego, że jesteśmy w stanie dość szeroko patrzeć na problemy.

Krzysztof:
Z tego, co tutaj mówisz, myślę, gdzieś tam słucham między wierszami, że wypływa też taka myśl, że

Krzysztof:
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 jakiś 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świadczenia, jakieś już umiejętności, które oczywiście mogą być przenaszalne na inne technologie,

Krzysztof:
jak najbardziej, ale gdzieś musimy je zdobyć. No i tu wracamy do, czy też wchodzimy w ten problem, który istnieje od pewnego czasu związany z juniorami, z osobami inspirującymi do 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 z 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. I czy tutaj branża nie strzela sobie trochę w stopę wycinając niejako ten nowy narybek, 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.

Bartek:
No tak, 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 no, Jeżeli narzędzia robią za nas wszystko, no to po co się czegokolwiek uczyć, nie? I tutaj mam taką fajną anegrodkę odnośnie tego, jak to wyglądało kiedyś z matematykami i z kalkulatorami. W sensie w 1986 roku w Waszyngtonie, no tam jakaś grupa matematyków zaczęła strajkować właśnie przed wprowadzaniem kalkulatorów, no bo jak wprowadzimy kalkulatory, no to oczywiście wszyscy zapomniemy już jak się liczy.

Bartek:
No właśnie. I co się z tym stało dalej? No 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. No 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 i to jak one się uczą, no to zanim dotkną 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 pracę w 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.

Bartek:
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, no 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 no idźcie na studia i nauczycie się to robić bez sztucznej inteligencji, bo wtedy ze sztuczną 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 trzymiesięcznych, po których szliśmy do pracy.

Bartek:
Co prawda był taki czas w IT, kiedy to było potrzebne, bo było tak duże zapotrzebowanie, że de facto to szybkie wdrożenie i później praca w pocieczoła na projekcie była w stanie nas nauczyć tej pracy. Natomiast teraz, jeżeli mamy te nasze procesy bardzo mocno zautomatyzowane, to mimo wszystko dobrze już wchodzić z jakąś taką wiedzą odnośnie tego, jak to tutaj działa. No i powiedziałbym, że no dobrym krokiem jest po prostu nauczenie się tego najpierw na sucho i dopiero później wskoczenie w głęboką wodę nie wiem Krzysiek 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 LL ma, a dopiero później dać mu te narzędzia już dalej do ręki, żeby pracował bardziej efektywnie.

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

Krzysztof:
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 RLM-y. Jedni delegują pewne zadania do RLM-a, ale później starają 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, 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, gdy nagle będzie jakaś duża awaria na produkcji i obudzą cię o 3 w nocy i wygenerowałeś większość kodów za pomocą RLM-a, to czy ty 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ć? Też może takie drugie pytanie do tego, czy to w ogóle jest potrzebne, czy tutaj jest to w ogóle problem, że my nie do końca rozumiemy de facto, jakie są te elementy składowe, w jaki sposób części projektu ze sobą współpracują.

Bartek:
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ą 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łowiowej trzeciej w nocy się nam wywali.

Bartek:
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 programisty, który właśnie w SDG sobie dewelopuje, no to jak go zapytamy tydzień po tym, jak zaimplementował daną funkcjonalność, no to… 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 i jest zrobiony dobrym SDD, czyli cała specyfikacja, wszystkie plany implementacji itd. Wylądowały w naszym repozytorium, no to taka osoba może nie pamiętać tego.

Bartek:
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 standaryzowany 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.

Bartek:
Ż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 jej 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 w ogóle bardzo zasadne pytanie z punktu widzenia organizacji, czy my możemy sobie pozwolić właśnie na takich błubogó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, 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 nikt tak łatwo z tego projektu go nie wypuszcza, no bo ma całą wiedzę, a z drugiej strony, no 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,

Bartek:
natomiast z drugiej strony jest nam się dużo łatwiej w takie systemy wdrożyć.

Krzysztof:
Mam wrażenie, że stoimy trochę przed taką zmianą paradygmatu tego, jak właściwie widzimy, jak opisujemy tak zwanego dobrego programistę, osobę, która, tak jak mówiłeś w tych czasach wcześniejszych, była wybitnym specjalistą, często w wąskiej dziedzinie 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. Dobry programista to niekoniecznie musi być właśnie ten, który idealnie zna rzemiosło, potrafi quicksorta 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?

Bartek:
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. Myślę, że to jest takie pierwsze skojarzenie. No i właśnie, ten świat 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 powiedzmy robiłem pierwsze eksperymenty z Copilotem, jak szybko jestem w stanie rozwiązać problemy, nad którymi kiedyś siedziałbym.

Bartek:
Dużo czasu, właśnie od strony takiej tylko i wyłącznie technologicznej, więc tutaj jakby ta wartość powiedzmy zaczyna się zmniejszać.

Bartek:
Natomiast zaczyna się zwiększać wartość osób trochę z drugiego biegunu, 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 dobre 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ć to 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, bo zazwyczaj jeżeli ktoś znał i technologię i rozumiał bardzo dobrze domenę, to też był takim bardzo mocnym punktem naszego zespołu od zawsze.

Krzysztof:
Mam tutaj w tym temacie relacji międzyludzkich w zespołach IT 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 LLM-ami, 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, no 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 z tymi relacjami międzyludzkimi teraz w tej dobie AI w IT?

Krzysztof:
Zyskują na znaczeniu, czy może tracą?

Bartek:
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.

Bartek:
No i jak technologia schodzi nam na dalszy plan, no 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ś produkt-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łubał właśnie w tej swojej przysłowiowej jaskini. No i teraz tak, programista już nie dłubia tego przez dwa tygodnie, bo dowozimy oprogramowanie dużo szybciej. Co za tym idzie, no 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, no 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.

Bartek:
No, a jeżeli chodzi o osoby techniczne, no to fakt, no 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.

Krzysztof:
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 jakby powiedzieć w 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. Te wszystkie rozmowy przy kawie, w kuchni, burze mózgu przypadkowe itd. Jakieś odkrycia, ciekawe uwagi, które w ten sposób powstawały, które nierzadko przyczyniały się do powstawania ciekawych rozwiązań w projekcie. Tutaj mam wrażenie, że troszkę tracimy tego aspektu działania zespołów IT. Nie wiem, czy tak też wynika z Twojej obserwacji i nie wiem, czy według Ciebie to jest problem, czy niekoniecznie.

Bartek:
Tak jest. Wydaje mi się, że tak jest. I nie wydaje mi się, żeby 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 garbage 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 LLM-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 pięć dni, tylko powiedzmy dwie godziny, no to nie zapada mi to na tyle w pamięci, żebym, chciał się jakoś super tym pochwalić powiedzmy przy kawie.

Bartek:
Więc powiedzmy, że tracimy rozmowy 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ęc tutaj bym powiedział, że no może… Przestajemy rozmawiać o szczegółach implementacyjnych, natomiast spokojnie dalej rozmawiamy sobie o rozwiązaniach, jakie dostarczamy, więc finalnie powiedziałbym,

Bartek:
że sprowadza się to mniej więcej do tego samego, tylko może na troszkę wyższym poziomie abstrakcji.

Krzysztof:
No to jeśli wytwarzanie software’u, jeśli go generowanie, ten proces developmentu 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?

Bartek:
Z tego co obserwuję, to powiedziałbym, że tym bottleneckiem właśnie przestaje być technologia, a zaczyna być jeszcze bardziej biznes, co 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 backlog szybko nam się kurczy, więc, w zasadzie no to mamy ryzyko w drugą stronę, że po prostu skończy nam się backlog, i dopóki nowe wymagania nie zostaną doprecyzowane, a decyzje biznesowe, w co wchodzimy, a w co nie, zostaną podjęte, no to zespół może, tać 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 EA Native.

Bartek:
To jest to, że paradoksalnie możemy mieć paraliż decyzyjny, bo jak product ownerzy i ogólnie nasz biznes widzi, jak szybko te rozwiązania dostarczamy, no to paradoksalnie ten backlog 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. No a teraz jak widzę po tych osobach, które właśnie zarządzają biznesem i patrzą na to, jak szybko ten biznes tutaj powiedzmy 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 zajmie 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 backlog po prostu zamiast nam szybko maleć, to okazuje się,

Bartek:
że zaczyna nam puchnieć szybciej niż widzieliśmy to kiedyś.

Krzysztof:
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 AI pisze kod, testuje go, reviewuje, to jak właściwie zmienia się ta rola seniora? Czy on staje się bardziej takim kuratorem jakości całego projektu niż twórcą, a może jeszcze w jakichś innych kierunkach, a właśnie ta rola podąża?

Bartek:
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ż w GFT 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 korzystać z jednego takiego ujednoliconego standardu. No i to nam trochę jako tym seniorom zabiera ten taki, myślę, że swoją drogą najfajniejszą część 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ć.

Bartek:
Niż tam powiedzmy tworzyć. Tej pracy twórczej wydaje mi się, że tutaj niestety mamy coraz mniej, ale chyba trzeba będzie z tym żyć po prostu.

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

Bartek:
To chyba zależy jak wysoko eskalacja dotrze.

Krzysztof:
Dyplomatycznie.

Bartek:
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 okej, żeby wpuścić ten kod do naszego repozytorium, więc jakby, 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 dnia to człowiek się podpisuje pod tym, że to co mu wyszło z tych wszystkich narzędzi dookoła niego,

Bartek:
no to on jest okej z tym, żeby to weszło do naszego repozytorium.

Krzysztof:
Rozumiem. Mówiąc o zespołach IT, też trzeba powiedzieć o liderach. Jak zmienia się leadership w tej sytuacji, kiedy mamy część kodu tworzonego przez ludzi, część 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?

Bartek:
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 technologią. 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 praca, że 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, no to powiedzmy, że w dwa lata lider jest w stanie dostarczać powiedzmy 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.

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

Bartek:
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-em, 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’u, to zacząłbym od tego, żeby na pierwszym miejscu przeszkolić ludzi, żeby ludzie wiedzieli jak dobrze pracować z AI-em i wtedy też od razu.

Bartek:
Jesteśmy w stanie nie skasować takie dyskusje na zasadzie, no bo wiecie, bo ja to próbowałem z tym LLM-em sobie coś napisać, powiedziałem mu, żeby mi napisał aplikację, a on mi nie napisał, więc jej to się da 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ą powiedzmy to oprogramowanie w tej naszej nowej, metodzie dowozić, więc to powiedzmy powiedziałbym, że to jest drugi krok, czyli właśnie trochę przestawienie metody pracy na projektach i tutaj też, z mocnym skupieniem się, żeby ułatwiać wdrożenie nowych ludzi w projekty, no ale to nam powiedzmy w jakiś sposób też zapewnia trzymanie tego standardu HDD.

Bartek:
No i po trzecie, no tutaj chyba ten ostatni, etap, czyli no zacząłbym po prostu budować troszkę mniejsze zespoły z troszkę większą odpowiedzialnością niż było to historycznie, czyli, no 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 przestawić, metodę pisania, oprogramowania właśnie na ten kierunek AI-Native i może bym tutaj zaczął iść w kierunku tego, że taki projekt może być dostarczony dwoma zespołami, a niekoniecznie trzema, czterema.

Krzysztof:
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, będzie to się zmieniało?

Bartek:
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 dowozić 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.

Bartek:
Który pomaga mu wyciągać biznes z tych ludzi, którzy na przykład nie są do końca techniczni, 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 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 frontend, 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.

Bartek:
A z drugiej strony zespół, który produkuje tak dużo kodu, musi być, bardzo dobrze zabezpieczony od drugiej strony, czyli, ten tester idący za zespołem musi budować testy regresyjne, które dają nam odpowiedź po, wrzuceniu nowego feature’a, 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 jakiejś tam osoby nietechniczne, PMO i tak dalej. To bym powiedział, że silnie zależy. Tak na pierwszy rzut oka 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

Bartek:
aplikacji albo kawałków systemów po prostu dostarczać.

Krzysztof:
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 LLM-y tutaj nam przyjmują 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 Fijałkowski z KFT. Bartku, bardzo ci dziękuję za tą rozmowę.

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

Krzysztof:
Cieszę się bardzo. Powiedz jeszcze na koniec, gdzie cię możemy znaleźć w internecie?

Bartek:
Myślę, że takim pierwszym źródłem kontaktu to będzie mój LinkedIn, więc w zasadzie Bartosz Fijałkowski z KFT. można mnie tam dość łatwo znaleźć. Ewentualnie jeżeli ktoś LinkedIna nie ma, no to w zasadzie można też do mnie się odzywać mailem tutaj imię.nazwisko.małpa.gft.com no moje nazwisko nie jest może takim najprostszym, do werbalizowania powiedzmy, ale na pewno Krzysiek gdzieś je tutaj podrzuci, więc na spokojnie można się odzywać. No i ja oczywiście jeżeli ktoś chce porozmawiać o AI Native Developmencie, to zawsze chętnie swój czas na to poświęcę i zawsze chętnie porozmawiam.

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

Bartek:
Dzięki, Krzysiek, cześć.

Krzysztof:
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 krzysztof@porozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek Porozmawiajmy IT o agentach AI w zespołach IT. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!