POIT #311: Spec-driven development w realnym projekcie: gdzie kończy się eksperyment a zaczyna odpowiedzialność

Witam w trzysta jedenastym podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest spec-driven development w realnym projekcie.

Dziś moimi gościem jest Maciek Kemnitz – CEO Primotly. Łączy myślenie strategiczne z operacyjną skutecznością. Buduje organizacje, które biorą odpowiedzialność za efekt końcowy. Tworzy zespoły od podstaw, porządkuje procesy i prowadzi firmy przez etapy wzrostu. Prywatnie jest entuzjastą sportu i ruchu, od koszykówki i judo, przez taniec i bachatę, po medytację i długie spacery.

W tym odcinku o spec-driven development rozmawiamy w następujących kontekstach:

  • czy spec-driven development to realna zmiana paradygmatu czy tylko ewolucja znanych podejść
  • relacja między spec-driven development a klasycznym programowaniem wysokopoziomowym
  • rola developera jako orkiestratora zamiast implementera
  • praktyczne zastosowania spec-driven development w zespołach mid-market
  • granice sensownego użycia vibe codingu w projektach produkcyjnych
  • sytuacje, w których spec-driven development może przynieść więcej szkody niż pożytku
  • tempo generowania kodu przez AI vs koszty jego utrzymania
  • odpowiedzialność za kod generowany przez modele AI
  • wpływ AI na rolę i znaczenie senior developerów
  • zmiana kompetencji wymaganych w zespołach technicznych
  • dojrzałość obecnych narzędzi spec-driven development
  • możliwe kierunki rozwoju i ewolucji tego podejścia

Subskrypcja podcastu:

Linki:

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

Krzysztof:
To jest 311 odcinek Porozmawiajmy IT. Dziś rozmawiamy o Spec-Driven Development w realnym projekcie, czyli tam gdzie kończy się eksperymentowanie, a zaczyna odpowiedzialność. Notatkę, linki i transkrypcję znajdziesz na porozmawiajmyit.pl łamany na 311. 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 jak na tacy. Wynagrodzenie, technologie, projekty. Bez zgadywania. Koniecznie sprawdź i skomentuj post na LinkedIn, który napisałem z okazji publikacji tego odcinka, aby mieć szansę na otrzymanie książki Andrzeja Dragana „Quo vAIdis” z autografem autora. Nazywam się Krzysztof Kempiński, tworzę 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 aplikacji. To jest dla mnie nieoceniona pomoc. A teraz odpalamy. Cześć, mój dzisiejszy gość to CEO Primotely, który to łączy myślenie strategiczne z operacyjną skutecznością. Buduje organizacje, które biorą odpowiedzialność za efekt końcowy. Tworzy zespoły od podstaw, porządkuje procesy i prowadzi firmy przez etapy wzrostu. Prywatnie jest entuzjastą sportu i ruchu, od koszykówki i judo przez taniec i bacha tempo, medytację i długie spacery. Moim Waszym gościem jest Maciek Kemnitz. Cześć Maćku, bardzo miło mi gościć Cię w podcaście.

Maciek:
Cześć Krzysiek, bardzo miło być z Tobą tutaj dzisiaj.

Krzysztof:
Dzisiaj będziemy rozmawiać o temacie, który przynajmniej na czas nagrywania tego odcinka jest bardzo gorący, ale też bardzo szybko się zmienia. Będziemy mówić o vibe codingu, czy też o nowszej, bardziej już aktualnej pewnie nazwie tego podejścia, którym jest Spec Driven Development, ale przyjrzymy się temu zjawisku w realnym ujęciu, w takich realnych projektach, stąd tutaj rola Maćka, aby podzielić się właśnie tymi doświadczeniami, gdzieś tam z frontu można powiedzieć, spojrzymy na to, gdzie eksperymentowanie z AI już się kończy, a zaczyna się realne wykorzystanie i w związku z tym wzięcie odpowiedzialności za efekty działania właśnie tych narzędzi. Myślę, że brzmi bardzo ciekawie, ale chciałbym rozpocząć, Maciek, od zapytania ciebie, czy słuchasz podcasty i być może jakieś ciekawe audycje będziesz w stanie zarekomendować.

Maciek:
Od czasu do czasu i przyznam, że kilka lat minęło, odkąd słuchałem podcastów, Głównie mi interesowała psychologia i pamiętam, że podcast Esther Perel zrobił na mnie bardzo duże wrażenie, zwłaszcza, że w każdej z jej historii mam wrażenie, że każdy może sobie wziąć troszeczkę dla siebie w swoim związku lub w życiu prywatnym, także bardzo polecam. W dzisiejszych czasach interesuję się bardzo finansami, tam przydają mi się wykresy, widzieć liczby, więc bardziej korzystam z YouTube’a albo nagrań, gdzie jest wsparcie wizualne. No i śledzę AI i tam też chętnie widzę zastosowanie praktycznie, stąd też bardziej to wideo niż same słuchanie.

Krzysztof:
Ja powiem Ci szczerze, że coraz bardziej zaczynam słuchać z wykorzystaniem AI różnych tekstów, Może w ten sposób Gemini w swoich zastosowaniach, na przykład w pakiecie G-Drive już takie rzeczy umożliwia. Mamy notebooka też, który daje nam takie możliwości. To jest takie całkiem ciekawe, ale nieoczywiste zastosowanie audio w odbiorze materiałów. Stąd myślę, że coraz częściej taka możliwość skrótowego przesłuchania danego materiału będzie się rozpowszechniała.

Maciek:
Zgodzę się, jest to przydatne. To notebook LM, który generuje ci na podstawie jakiegoś tekstu jakiś super podcast, to tak robi wrażenie.

Maciek:
W marketingu dużo zastosowań widzę w tym. Fajne.

Krzysztof:
Normalnie przeszlibyśmy teraz do pytań, ale dzisiaj mamy dość ciekawą, myślę, interesującą rzecz dla naszych słuchaczy. Mianowicie swego rodzaju konkurs z nagrodą, którą właśnie Maciek i jego firma chcą ufundować. A jest nią książka Ko Vajdis Andrzeja Dragana, pewnie znanego tutaj naszym słuchaczom z jego autografem, co ciekawe, więc nie byle gratka można powiedzieć.

Krzysztof:
I chcielibyśmy, aby osoby, które będą chciały uczestniczyć pod postem, który na Linkedinie będzie towarzyszył właśnie informacji o pojawieniu się tego odcinka, odpowiedziały na dość, myślę, proste pytanie o to, co wdrożyły z tej naszej tutaj dzisiejszej rozmowy, z tego, co Maciek będzie nam mówił, jaką jedną rzecz zastosowały i co z tego wynikało, jaki był efekt, być może jest jakaś decyzja, jakaś zmiana, która będzie właśnie zainspirowana tą rozmową, być może jakaś zmiana w procesie, jakaś automatyzacja, jakaś rozmowa przeprowadzona. No a chcielibyśmy, abyście się właśnie tymi rzeczami z nami podzielili. Jeszcze raz pod wpisem na LinkedInie, który będzie towarzyszył właśnie informacji o tym podcaście. Wybierzemy jedną osobę, która najciekawiej na to pytanie odpowie i skontaktujemy się celem dostarczenia książki. Także, Maćku, dzięki bardzo za taki ciekawy prezent dla naszych słuchaczy.

Maciek:
Może dopowiem Ci skąd w ogóle taki pomysł. Ta książka miała bardzo duży wpływ na to jak nasza firma obecnie działa albo przynajmniej jak ja operuję, bo to był pierwszy moment, ona się pojawiła w rozmowach z działem marketingu. Pan Drakan tłumaczy, jak działa to AI. A to, jak człowiek zaczyna rozumieć, jak pewne decyzje są podejmowane i że tam tak naprawdę żadnej niesamowitej magii nie ma, tylko są to wektory, prawdopodobieństwo i algorytmy, no to bardzo pozwala zrozumieć ograniczenia, które mamy i bardziej świadomie to dobierać. Także bardzo polecam tę książkę. No i jestem ciekawy, czy uda się

Maciek:
kogoś zmotywować do podjęcia akcji i rzeczywiście zmiany czegoś w życiu.

Krzysztof:
To jest myślę najistotniejsze po każdej lekturze, po każdym przesłuchanym podcaście idealnie by było, jeśli byśmy przynajmniej tą jedną rzecz gdzieś tam wykorzystali, wdrożyli, żeby miało to realny wpływ na nasze życie, naszą pracę. To jest jakby to clou, więc taki tutaj action point mamy, aby właśnie zachęcić was do wdrażania tych rzeczy. No i też dzielenia się, to jest, tak wynika z moich obserwacji, jestem przekonany, że z twoich również, że to całe środowisko związane z AI wokoło IT jest mocno nastawione na to, żeby się dzielić właśnie tymi swoimi obserwacjami, tymi naukami, które gdzieś tam wyniosło. To jest taka bardzo fajna wartość dodana w ogóle pracy w IT. Myślę, że jest możliwość czerpania z doświadczeń innych.

Maciek:
Tak. I też chyba takie podejście kiedyś było, że oj nie, ja nie podzielę się wiedzą, bo mi ktoś zabierze i chyba internet to zmienił, że już jesteśmy ten open source, już duże firmy, sytuacja, którą mieliśmy z DeepSeakiem, że to wypłynęło, to jakby warto się dzielić i tak.

Krzysztof:
No właśnie, bo wiedza sama w sobie jest dość tania obecnie, jest łatwo dostępna, może w ten sposób, natomiast jej konkretne wykorzystanie z aplikowania, te doświadczenia, to jest wszystko to, co wymaga pracy, jakby nie było i jest tym bardziej cenne. Macieju, chciałbym przejść do takiej kwestii związanej z tym, co obecnie obserwujemy, co jest związane z wytwarzaniem różnego typu artefaktów, może tak to nazwijmy, z wykorzystaniem narzędzi AI. Oczywiście będziemy się tutaj skupiać na wytwarzaniu kodu, wytwarzaniu software’u. Obserwujemy, mam wrażenie, dużą zmianę, dużą rewolucję. Oczywiście takich zmian pewnie w historii, jeśli chodzi o software, było trochę. Przeszliśmy gdzieś tam z kart perforowanych i wcześniejszych nośników na języki maszynowe, asemblerowe. Później przeszliśmy na języki nieco nowocześniejsze, które już za pomocą innej składni, innego podejścia umożliwiały wytwarzanie oprogramowania. To, co teraz się dzieje, czyli właśnie wytwarzanie kodu za pomocą vibe codingu czy też spec-driven developmentu, możemy porozmawiać, co jest bardziej sensowne, co bardziej oddaje sens właśnie tego procesu.

Krzysztof:
Czy to jest według Ciebie kolejny krok, kolejna zmiana paradygmatu?

Maciek:
Tak, ale cofnąłbym się do Ciebie, jak ja w ogóle patrzę na to, co nas teraz dotyka, no to tak jak wspomniałeś, to jest powiedzmy taka druga potężna rewolucja w wytwarzaniu oprogramowania czy programowaniu. Nie wiem, czy pamiętasz, jak to było, że kiedyś to miałeś dostępne jako wsparcie albo książkę programistyczną, albo jakiś forum. Pojawił się Google i te strony były troszeczkę lepiej zaindeksowane. Potem dostaliśmy prezent w postaci stack overflow i życie stało się już znacznie przyjemniejsze potem wydaje mi się, że pojawiły się frameworki, pojawiły się konferencje wokół tych frameworków dużo się wydarzyło we frontendzie, więc mieliśmy tą erę meetupów gdzie ludzie się łączyli w community i rozwiązywali różne problemy No a potem przyszedł czar GPT i tak overflow, jeśli widziałeś statystyki, no to podłoga.

Krzysztof:
W dołu, tak.

Maciek:
Cię nie dziwia. To, że teraz nie trzeba szukać po tych różnych forach, tylko te informacje spływają do ciebie i równocześnie one są szyte na miarę z parametrami, które podajemy, albo osadzone w kontekście, no to to już był niesamowity skok i jak się tak słuchało programistów, to były żarty, ach, spytam kolegi, on mi powie, jak to zrobić, po co mam sam myśleć. Oczywiście to były tylko żarty, no bo ten kod często był fatalny albo nawiązywał do bibliotek, które nie istniały. No ale to samo doświadczenie mieliśmy przecież na Stack Overflow, nie każde pytanie było prawidłowo rozwiązane, a nie wiem, czy też miałeś takie sytuacje, kiedy już SPAC Overflow nie pomógł i wiesz, że będziesz miał dwa tygodnie ciężki czas, gdzie będziesz grzebał w internecie, gdzie jest ta odpowiedź, jak rozwiązać ten mój problem, czemu nikt inny nie ma z tym problemu. No i to się działo w zeszłym roku.

Maciek:
Jeszcze nie byłem takim entuzjastą tej zmiany, widząc tą jakość i nie był to jakiś taki ogromny boost. A potem przyszli agenci i te modele, które mamy w mojej ocenie są na tyle dobre, że potrafią rzeczywiście zrozumieć szerszy codebase czy tam ileśnaście przynajmniej plików i potrafią na nich bezpośrednio operować.

Maciek:
No i to jest game changer, no bo w tym momencie ludzie zaczynają się bardziej zastanowić, co ja chcę osiągnąć niż jak to osiągnąć. A przedtem przez to, że jak to osiągnąć, bo aż tak wymagające, trudne skomplikowanie, no to jeśli firma była troszkę mniejsza i nie miała jeszcze tych procesów pełnych, gdzie jest pełna analiza wszystkie wymagania, no to się często odkrywało to podczas programowania, a teraz tak już nie ma. Jak za vibe kodujesz i nie dasz wystarczająco dobrego promptu, kontekstu, nie zatrzymasz go, no to on ci ucieknie i będzie ci robił takie błędy, że potem ludzie się śmieją, że naprawiają kody prompt engineeringu czy tam vibe kodingu i budują na tym biznesy. Myślę, że to jest przejściowy okres.

Maciek:
No i taką naturalną następną ewolucją jest spec-driven development w momencie, jeśli chcemy już nie stworzyć malutkie zadanie, tylko chcemy rzeczywiście nad czymś poważnie pracować przed dłuższy czas, no to naturalne jest to, że chcemy te ramy coraz lepiej opisywać, czyli jak chcemy wytwarzać oprogramowanie, jakie technologie mają być użyte, jak będziemy to testować i przede wszystkim jak będziemy wprowadzać nowe featurey, skoro jesteśmy w stanie robić to z dnia na dzień. Czy nowy paradygmat? Bardziej bym powiedział, że to jest następny krok ewolucji, który wcale się nie sprawdzi w każdym projekcie. I tutaj też musimy to zaznaczyć.

Krzysztof:
Dokładnie, nie jest to pewnie taki złoty młotek, narzędzie na wszystko ma swoje ograniczenia, każde inne narzędzie, o tym też pewnie chciałbym dzisiaj z tobą porozmawiać, natomiast z pewnością duża zmiana też w sposobie pracy, takiej codziennej pracy. Myślę, że ten poziom LLM-u w modeli jest już na tyle zbliżony, jeśli chodzi o te takie topowe modele, że tutaj w sumie nie do końca ma super znaczenie, które wybierzemy. Coraz bardziej zaczynamy się poruszać, czy też raczej ta zmiana zaczyna tyczyć się tego, jaki jest tooling, jaki jest marketing, w jaki sposób wszystkie te rozszerzenia ze sobą działają, co też może świadczyć o pewnym dojrzewaniu już całego tego ekosystemu i tego, że coraz częściej, coraz większa ilość programistów nie wyobraża sobie życia już bez tych narzędzi.

Maciek:
Zdecydowanie nie jestem pewien czy by potrafili jeszcze co by się wydarzyło, czy ktoś jeszcze potrafi sam sformatować maila te umiejętności nam troszeczkę zanikają zdecydowanie przez ten pomysł.

Krzysztof:
Właśnie tylko pytanie, czy to jest nam potrzebne. W sensie słyszę nieraz tego typu, zawodzenie czy narzekanie, że zatracimy te takie korowe, można powiedzieć, z punktu widzenia tradycyjnego oprogramowania umiejętności. Zastanawiam się, czy to dobrze, czy to źle, czy to w ogóle nie ma znaczenia, bo tak samo można byłoby powiedzieć, że ja przynajmniej tak pamiętam ze swoich studiów, że jeszcze gdzieś tam coś w assemblerze pisałem. No teraz pewnie ta umiejętność jest kompletnie nieprzydatna, a można było powiedzieć, że ojej, ojej pojawiło się nam C++ i Java i zapomnieliśmy pisać tak, jak to jest pisać coś w assemblerze i zataczyliśmy jakąś cenną umiejętność. Z perspektywy czasu można powiedzieć, że to nie ma kompletnie żadnego znaczenia. Zastanawiam się, czy podobnie nie będzie teraz właśnie z tymi rozwiązaniami AI, że być może, jestem przekonany, że wręcz na pewno zatracenie jakiejś wiedzy na temat chociażby struktur danych, czy tego typu podstawowych jakichś takich kompetencji programistycznych, czy to nie spowoduje, że zatracimy tą umiejętność, ale w efekcie nie będzie to miało żadnego znaczenia, bo te rozwiązania będą już na tyle dobre, że nie będziemy mieli potrzeby, żeby je stosować po prostu.

Maciek:
Wydaje mi się, że sposób w jaki pracujemy się diametralnie zmieni i social media już to potwierdzają, że ludzie są zmęczeni. I zwalają to troszeczkę na to, że AI zastąpiła tą prostą robotę, no i teraz ludzie się męczą przez to bardziej, bo robią to trudniejszą. Myślę, że to jest trochę zakłamane, jesteśmy nieprzyzwyczajeni, tyle odpoczywaliśmy w pewnym sensie przy programowaniu, że teraz faktycznie jak trzeba cały dzień myśleć, no to jesteśmy zmęczeni. Ale to myślenie daje tak dużo benefitów z czasem, że się opłaca. I myślę, że do tego się przyzwyczaimy i stworzymy sobie ekosystem narzędzi, gdzie człowiek na pewno będzie potrzebny. Tutaj to jest bez dwóch znań. Czy teraz drogi programista będzie potrzebny, żeby programować? Nie. Te systemy nadal są skomplikowane. Tutaj nadal ta wiedza jest na wagę złota, AI nie wie, co rozumie. Ono tylko podejmuje jakieś algorytmiczne decyzje, Tak, jest to super, no bo nie jest to sztywny algorytm jak kiedyś, ale nadal jest to tylko algorytm, nie powierzyłbym decyzji w firmie algorytmowi.

Krzysztof:
Były takie eksperymenty, ale chyba z raczej mizernym skutkiem. No właśnie, wiesz, też zastanawiam się, czy to przypadkiem nie jest tak, bo jesteśmy już jak gdyby chyba poza albo wyszliśmy z tego zamartwiania się o to, czy AI zastąpi programistów. Tak zrozumieliśmy, że to jest doskonałe narzędzie, które tylko gdzieś amplifikuje pewne rzeczy, umiejętności i faktycznie użyte w odpowiedni sposób, tylko zwiększa nasze możliwości, nie jest natomiast takim zagrożeniem pod tytułem zabierze nam zupełnie pracę i.

Krzysztof:
Mam wrażenie, że troszkę to już okrzepło, że przyzwyczailiśmy się do tego, że ta nowa rzeczywistość wygląda tak, jak wygląda, ale gdyby tak spojrzeć chyba w detalach, to okazuje się, że chyba aż tak wiele się nie zmieniło. Mam wrażenie, że to wcale nie jest taka kompletna rewolucja, że my teraz zaczynamy działać zupełnie inaczej. I z tego punktu widzenia chciałbym cię zapytać, czy to nie jest przypadkiem tak, że my nadal programujemy, ale używamy innego języka, używamy języka takiego wysokopoziomowego, naturalnego wręcz, do tego, żeby tworzyć kod versus języka, można powiedzieć, nieco niższej klasy, nieco niższej generacji, który był bardziej ułożony, bardziej zorganizowany według sztywnych zasad. Teraz możemy posługiwać się językiem naturalnym, ale efekt, czy też ten flow jest de facto taki sam?

Maciek:
Tak. Wyciągnęliśmy człowieka z programowania, czy tam obietnica marketingowa raczej, no bo to jest dopiero zaczynamy, może w Stanach, może inaczej. W Stanach jestem przekonany, że tam duże zespoły już rozwiązały problem, jak dostarczać kod w sposób powtarzalny i z odpowiednią jakością. Pewnie nadal jest to sprawdzane, ale pewnie są dalej. I na tej podstawie na pewno jakieś narzędzia powstaną, z których my skorzystamy i będzie nam przyjemniej. Widzimy to w kursorze, Antigravity, no to przecież to są ich wynalazki I oni już na tym pracują i to przetestowali.

Maciek:
Więc kto inny będzie wytwarzał ten kod, nadal musimy wiedzieć, nadal trzeba zrozumieć problem, który istnieje i go zdekomponować, znaleźć rozwiązanie, potem zaprogramować i sprawdzić jakość. Tylko przesuwa się ten ciężar, który był na programowaniu, bo to było drogie, czasochłonne i on się przesuwa na ten ciężar przygotowania się do pracy i jak pamiętasz, dawno, dawno temu mieliśmy Waterfalla i Waterfall zaczynał się od tego, że firma większość czasu myślała, co my chcemy dowieźć, było to związane z biznesem, no bo jako firma nie chcesz dowieźć fix price’a czy time material dwa lata i się pomylić. No i potem był dwu-, trzyletni okres programowania, gdzie nikt nie zaglądał, no i było rozczarowanie.

Maciek:
Potem się pojawił Scrum, który odpowiedział na to rozczarowanie, róbmy mniejszymi iteracjami, szybciej się przewracajmy, szybciej pokazujmy klientowi. No a teraz widzę tendencję, że musimy znacznie więcej myśleć o tym, jak to robimy, bo programowanie jest szybciutkie.

Maciek:
Siłą rzeczy role na projektach muszą się trochę zmienić, Nadal robimy to samo, ale nacisk będzie już na tym, żeby teraz naprawdę trzeba zrozumieć, bo jak nie zrozumiesz, to zostanie zakodzone źle i cofnięcie jest tak samo jak w Waterfallu, bardzo kosztowne. No i tutaj Spec-Driven Development, ale z kolei jak robimy MVP narzędzie wewnętrzne, no to kto się będzie bawił w dokładną dokumentację, kogo obchodzi, czy tam jest idealnie, ważne, żeby szybko rozwiązać sobie problem. No i tutaj też trzeba być ostrożnym, więc na pewno będziemy jako ludzie więcej myśleli, no bo robota jest łatwiejsza w wykonaniu.

Krzysztof:
No i to bardzo dobrze. O to chyba właśnie chodzi, żeby zdejmować z naszych barków te nudne, powtarzalne rzeczy, które faktycznie nie są jakoś tam dla nas interesujące. To też pewnie się przekłada na taką satysfakcję, taką jakość z tej pracy. Od jakiegoś czasu zaczyna się mówić o wypaleniu zawodowym w IT, ten problem gdzieś tam jest coraz bardziej namacalny i myślę sobie, że może on po części wynikać z tego, że po prostu robimy nudne rzeczy, robimy cały czas te same rzeczy, mało rozwijające, mało ciekawe, mało jest tam tego myślenia. Być może panaceum to właśnie tego typu narzędzia, o których rozmawiamy.

Maciek:
Na pewno jest część ludzi, która w pracy się nie musiała wysilać, no i właściwie jeśli się prawidłowo zakręci wokół tych narzędzi i ma taką możliwość, że może je wdrożyć, no bo tutaj mówimy jeszcze o, czy w ogóle można zastosować AI nad tym projektem, No to myślę, że jeszcze dużo czasu upłynie, aż ktoś taki zostanie złapany, że rzeczywiście większość robi AI, no i w sumie to znaczy, że prawidłowo wykorzystuje tą technologię, bo do tego służy. I myślę, że nawet jak ludzie wtedy będą mieli więcej czasu, to naturalnie, mając takie fajne narzędzia, będą chcieli eksperymentować, będą chcieli rozwiązywać swoje problemy lub dadzą nam coś zupełnie innego, co docenimy, bo nic ich praktycznie już teraz nie ogranicza, jeśli mówimy o internecie, tworzenie aplikacji lub stron internetowych małych. Duże, zupełnie inna bajka.

Krzysztof:
Tak, tak, absolutnie. No ale należy pewnie przypuszczać, że to też będzie jeszcze się zmieniało, że będziemy widzieć postęp, będziemy widzieć gdzieś tam zwiększenie, polepszenie tej jakości. Oczywiście pytanie jest, czy ta szybkość tych zmian będzie nadal utrzymana na takim poziomie. Należy też pewnie spojrzeć na inne wynalazki, inne technologie. Gdzieś tam w końcu oczywiście jakieś spowolnienie musi nastąpić. Natomiast sądzę, że jeszcze wiele przed nami i jeszcze pewnie wiele rewolucji i zmian w tym kierunku będziemy obserwować. Powiedziałeś, że ta rola dewelopera, ten tooling, który używa się zmienia, że inaczej patrzymy teraz na to, jak ten przysłowiowy programista w projekcie pracuje. To kim on powinien się stać, albo jaką drogę pokonać, aby móc się odnaleźć w tej nowej rzeczywistości, kiedy wytwarzanie softu opiera się właśnie o specyfikację?

Maciek:
No to jaka była w ogóle ścieżka programistów? Kiedy zaczynamy przechodzić do pracy, to jesteśmy juniorami tak zwanymi i w ogóle uczymy się jak tutaj się pracuje, czym jest task, jak go wykonać i głównie czerpiemy od firmy. Potem stajemy się z czasem samodzielni i ta samodzielność, powiedzmy, że to jest główny etap, który większość programistów osiąga, że są w stanie wziąć taska. Tak jak mówiłem, w tym tasku jest jakiś problem do rozwiązania, więc w pierwszej kolejności muszą zrozumieć ten problem, znaleźć rozwiązanie, no i miło by było jakby jeszcze sprawdzili, czy działa. Potem w większych zespołach mamy testerów lub testy automatyczne, no i głównie na tym praca programisty się polegała, jeszcze wchodziliśmy na spotkania, tam pytano nas o techniczne aspekty, żeby ktoś w biznesie mógł zdecydować, tak, robimy to, jest na to budżet. Senior, czyli już to, co dało się teraz powiedzmy osiągnąć na rynku, no to już jest osoba, która patrzy bardziej systemowo, czyli jeśli my będziemy przez jakiś czas wykonywać w taki sposób kod, no to to się dobrze nie skończy, musimy wprowadzić jakieś standardy, zaczynamy mierzyć, patrzeć, czy tam się opłaca,

Maciek:
Troszeczkę zaczynamy patrzeć na finanse, na budżetowanie projektu, na dynamikę w zespole. Więc tutaj już jest bardziej chodzi o to, że jako zespół dowozimy jakąś wartość, a nie po prostu pracę wytwórczą no i wydaje mi się, że tak jak agenci mają orkiestratorów tak też deweloper stanie się powoli orkiestratorem i jak do tej pory deweloper pracował powiedzmy z Figmą, jeśli chodzi o pozyskanie jak coś ma wyglądać i do tego był potrzebny grafik, no to teraz to już nie do końca jest potrzebne albo programista potrafi dość dobrze wyglądający, stworzyć produkt końcowy, który dość dobrze wygląda. Tylko, że nic nie jest za darmo. Tutaj trzeba patrzeć, tutaj są różne pułapki w tych narzędziach, czy to tokeny, czy to kontekst, który ucieka, czy to czym w ogóle jest ładny design. To jest takie bardzo subiektywne.

Maciek:
Ale wracając, bo troszkę odpłynąłem, Więc ta rola staje się bardziej takim organizatorem pracy, gdzie najważniejsze jest to, żebym ja rozumiał, jak tą pracę należy wykonać, bo w momencie, jak agent ruszy, to już go nic nie zatrzyma.

Maciek:
Możemy odpalić agenta, że przed każdą operacją się nas pyta, no ale to nie o to chodzi. To jest współpraca z juniorem. My chcemy współpracować z kimś na poziomie mid-developera, czyli oczekujemy, że on zrobi, ten rezultat może być średni, tak samo jak z każdym mid-developerem, no to będę z nim iterował. No i teraz nad tym procesem programiści powinni być skupieni, czyli które dokładnie informacje są potrzebne, żeby te informacje były jak najmniejsze, żeby nie zajmować kontekstu i żeby też te informacje nigdy nie zostały zgubione. I to jest, wydaje mi się, największy problem teraz w branży, jak to rozwiązać, jak ten problem zostanie rozwiązany,

Maciek:
No to wtedy już się liczy głównie rozwiązanie problemu i znalezienie dobrego rozwiązania, a jak zapewne wiesz, są różne drogi do osiągnięcia sukcesu i tu się liczy security, performance i ewentualnie dalsze rozbudowanie projektu, no i one się staną kluczowe. One są teraz na świetlniku branży.

Krzysztof:
Tak, tak, właśnie powiedziałeś, że teraz skupiamy się jako branżę na tej współpracy dewelopera z AI, żeby najlepszy efekt tej współpracy wyciągnąć. I teraz zastanawiam się, czy gdzieś tam troszkę nie umyka perspektywa zespołu, że skupiamy się na takiej indywidualnej pracy, Człowiek, deweloper z agentem, czy tam z jakąś pulą agentów. Gdzie tutaj jest zespół? Może to jest kolejny krok, może to jest coś, co będziemy analizować, nad czym będziemy się zastanawiać, kiedy już w miarę ten problem współpracy z tym naszym elektronicznym mid-developerem zostanie rozwiązany. Ale myślę sobie, że jakby nie patrzeć, to też jest rzecz, która będzie musiała się w jakiś sposób zmienić albo w jakiś sposób po prostu ewoluować, no bo taka jest naturalna pewnie kolej rzeczy. Czy masz jakieś, nie wiem, obserwacje albo jakieś wnioski właśnie dla zespołów, które rozwijają się w ten sposób, że pojedyncze osoby korzystają tam z rozwiązań AI? Może jakieś obserwacje, jak to wpływa na dynamikę właśnie pracy zespołów?

Maciek:
Trudne pytanie, bo tak jak mówisz, te technologie tak dynamicznie się zmieniają, że jeszcze nie mieliśmy długiego czasu, żeby z tym poobcować. W mojej firmie przynajmniej mamy różne możliwości, tak jak wspominałem. Na niektórych projektach jest to absolutnie zakazane, żeby cokolwiek wypływało do czatu. Te polityki korzystania i zabezpieczeń też są takie, brak zaufania tutaj. Brak tutaj jeszcze, żeby ktoś się faktycznie przejechał, miał problem, poszedł do sądu, dowiedział się jak to się skończyło, więc tutaj jesteśmy trochę zachowawczymi, No i mamy małe projekty, gdzie testujemy, a równocześnie mam programistów, którzy są entuzjastami AI i oni sami zaczęli wdrażać jakieś rozwiązania. Więc na pewno jedna osoba nie jest w stanie dowieść wszystko. I tutaj nie zmienia się nic w zasadzie, że dwie osoby prawdopodobnie wymyślą lepsze rozwiązanie niż jedna osoba w pojedynkę. Mamy problem kaczuszki, druga perspektywa, a nawet więcej perspektyw wprowadza z reguły wartość.

Maciek:
I myślę, że tego będziemy widzieli więcej, czyli zespoły w momencie, jak już wtedy, wcześniej byliśmy bardziej odizolowani, bo siedziałeś przed komputerem i 4-5 godzin byłeś sam na sam z komputerem. Teraz nie ma już potrzeby tak długo siedzieć z komputerem, a zaczynamy bardzo dużo produkować, więc jest problem do rozwiązania, co zrobimy, jak pięcioosobowy zespół zacznie bardzo dużo produkować. Nie będą tak dużo produkować, bo prawdopodobnie pracują nad projektem, który wymaga, już jest tak zaawansowany, że tam musi być ta jakość i oni nie będą 10 razy szybsi. Więc oni będą się inaczej zachowywać niż projekt, który dopiero co powstaje, gdzie dwie osoby praktycznie mogą non-stop pracować w bardzo szybkim tempie. Nie odpowiedziałem na twoje pytanie,

Krzysztof:
Bo też nie znam odpowiedzi. No właśnie, pytanie jest bardzo trudne, w sensie myślę, że jeszcze nawet nie dotknęliśmy gdzieś jako branża tego typu problemów, ona gdzieś tam się dopiero pojawiaje. No bo z jednej strony, tak jak powiedziałeś, być może zwolni nam się po prostu fizycznie czas, który będziemy mogli przeznaczyć na to, żeby rozmawiać na przykład z pozostałymi członkami zespołu. Być może to jest to, czego nam w tej chwili trochę brakuje, tej możliwości interakcji, jakoś zderzenia swoich pomysłów. Taka jest być może nadzieja, czy tak będzie to trudno powiedzieć. Z drugiej strony widzę pewne zagrożenie wynikające z tego, że będziemy chcieli cały czas pozostawać w tym kontekście pracy z AI, z agentem, cały czas gdzieś tam iterować. I jest pewnie taka ilość tych iteracji, kiedy to ma jeszcze jakiś sens, kiedy coraz bardziej dopieszczamy jakieś rozwiązanie, ale myślę sobie, że po którejś tam już próbie nic lepszego nie uzyskamy, musimy gdzieś tam wyjść poza być może tą bańkę, być może spróbować zupełnie innego podejścia i tutaj zderzenie tej naszej perspektywy z innym człowiekiem jest pewnie nieocenione. Więc mam nadzieję, że pójdziemy w tą pierwszą stronę, czyli że zwolni nam się czas.

Krzysztof:
Który wykorzystamy, żeby właśnie rozmawiać z innymi, żeby gdzieś te swoje pomysły zderzać, ulepszać, niż to, że jeszcze bardziej pozostaniemy w tym kontekście pracy z narzędziem, bo to nas nie będzie ubogacało, wręcz przeciwnie, gdzieś ta perspektywa będzie coraz biedniejsza. Zobaczymy, pewnie czas pokaże.

Maciek:
Może jeszcze podczas twojej wypowiedzi przyszło mi do głowy. Tak naprawdę teraz każdy otrzymuje swój zespół. Mamy swoich agentów. Zespoły będą się dzielić skillami i pewnie będą pracować nad skillami, czyli co agent potrafi. No i tak, ja mogę dać zespołowi prezent w postaci, ja pracowałem przez tydzień nad tym, że teraz nasz agent będzie robił świetne code review. I w tym sposobem daje dużo dobrego zespołowi. Pytanie, czy gdzie się skonięc? Kiedy już wszystko będzie, te modele będą tak dobre, będą w stanie zaprogramować, no i w tym momencie każdy programista staje się w pewnym sensie liderem, no i będzie się komunikował z innymi deweloperami jak lider z liderem. Jakie ty masz problemy ze twoim zespołem, jak rozwiązałeś ten problem, oto fajnie też zrobię to z moim zespołem. Może w tą stronę, że nadal będzie ta współpraca, a wręcz będzie,

Maciek:
cofniemy się i tej współpracy będzie więcej.

Krzysztof:
Bardzo ciekawe. To na pewno wymaga zupełnie innych kompetencji, nad którymi pewnie jeszcze musimy popracować. To też zakłada, że w każdym projekcie, albo w większości tych projektów, pod domem tego naszego projektu, będziemy stosowali właśnie to podejście oparte o spec-driven, czy też vibe-coding, zwał jak zwał. Tymczasem na początku powiedziałeś, że to nie wszędzie ma sens. Nie wszędzie ma sens, żeby aplikować właśnie tego typu podejście. No to gdybyś mógł z własnego doświadczenia powiedzieć, kiedy przynajmniej na ten moment, gdzie to się opłaca, gdzie ma swoje gdzieś tam jakiś uzysk,

Krzysztof:
a gdzie absolutnie nie aplikowałbyś tego podejścia.

Maciek:
To pewnie spojrzałbym na jakie różne mamy w ogóle grupy projektów. Jeśli mówimy o przede wszystkim czymś wewnętrznym, co nigdy nie chcemy, żeby wyszło poza nasz komputer, to jak najbardziej vibe coding, spec driven development jest pewnie za ciężki ewentualnie, no nie wiem chcesz sobie stworzyć własny meal planner wiesz, że znasz się na tym masz na to pomysły, nie chcesz wydawać na to pieniądze tutaj bym się zastanowił vibe coding szybko spowoduje, że będziesz marnował czas i tokeny bo w jednym prompcie masz bardzo ograniczoną ilość informacji które możesz przekazać, które rzeczywiście

Maciek:
Technologia zrozumie. Stąd wiemy, że projekty, które były vibe-kodowane, bardzo szybko się osiągały etap, gdzie prawdziwy programista musiał przyjść i to wszystko teraz naprawić. Więc vibe-koding, szybko, brzydko, skrypty, krótkie programy, strona internetowa dla siebie, tak żeby działała na lokal hoście jak najbardziej. Wszystko, co już będzie długotrwale rozwijane, Spec-Driven Development, żebyś mógł się cofnąć, żeby to miało pewne struktury i ręce i nogi. No i tu mówimy o prywatnych rzeczach i tu jest prosto. W momencie, jak nam dochodzi jakiś klient, no to sytuacja się diametralnie zmienia, ponieważ dajemy osobom trzecim informacje,

Maciek:
Do których nie mamy praw się dzielić. I tutaj nie mamy jeszcze odpowiedzi, jak to działa na rynku. Większe korporacje po prostu powiedziały nie i mogą tylko korzystać ze swoich wewnętrznych narzędzi i wtedy trzeba się do tego dostosować i kluczowym staje się zrozumienie tego narzędzia i odpowiednia komunikacja z tym narzędziem. Na pewno słyszałeś, że z Gemini’em warto inaczej rozmawiać niż z OpenAI, troszeczkę inaczej one są, różne prompty dają różne rezultaty. Swoją drogą świetne zadanie na skill dla agenta z tym modelem komunikujesz się tak, z tym komunikujesz się tak. Jeśli mamy jakikolwiek projekt, nawet jeśli powiedzmy mamy klienta, ten klient jest mniejszą firmą, nie jest objęty żadnymi regulacjami i się zgodzi na to, żeby w razie czego informacje kluczowe wypłynęły, mimo że nie powinny, no bo jak mamy komercyjną usługę z OpenAI, to te modele twierdzą, że się nie są na tym uczone. Tak jak mówiłem, musimy poczekać, aż pierwszy raz ktoś zhakuje OpenAI i co się wtedy wydarzy.

Maciek:
To można, ale w momencie, jak klient już ma jakiekolwiek dane wrażliwe, to ja bym się w to nie pałł i bym długo poczekał, aż ktoś inny popełni ten błąd.

Maciek:
Jeśli jakość projektu jest bardzo ważna, no to można iść z vibe codingiem, można iść z spec-driven development, tylko bardzo małe zmiany. W momencie, jak robimy duże zmiany, potęguje się prawdopodobieństwo błędów, potęguje się prawdopodobieństwa kosztów, ryzyk. Wiemy też, że AI jest kiepskie z generowanym kodem, jeśli chodzi o security, więc świadomość, jaki problem próbujemy rozwiązać, jest bardzo ważna. I na pewno jest jeszcze dużo różnych case’ów, ale to już jest taki jakby North Star, gdzie należy natychmiast uważać i trzeba bardzo dokładnie się wczytać w prawne aspekty, a są takie sytuacje, gdzie się nie wygłupiajmy, jest to narzędzie, które ma nas wspierać Zupełnie inaczej wygląda sytuacja, jak instalujesz na przykład OpenClaw i on ma dostęp do całej twojej poczty, gdzie jesteś zalogowany, to już w ogóle byłbym ostrożny i nie bez powodu ludzie stawiają to na Macach mini, żeby było odizolowane i bezpieczne. No i jak już wpuszczamy sztuczną inteligencję na nasz komputer, no to wydaje mi się, że jesteśmy od krok do tego, żeby hakerzy się dostali na nasze komputery. Znowu trzeba uważać.

Krzysztof:
No tak, to jest szeroki temat i faktycznie ten aspekt, ta perspektywa security jest tutaj nie bez znaczenia. Rozmawiamy dzisiaj o wytwarzaniu software’u i takim nieodzownym tematem albo etapem, jeśli chodzi o cykl życia software’u, jest taki etap powiedzmy legacy, i takie trzeba go gdzieś tam utrzymywać. Być może nie dzieje się tam już zbyt wiele, ale mimo wszystko jednak jakieś tam bugi, jakieś tam podbicia bibliotek, jakieś zawsze rzeczy się znajdą i zresztą jest całe mnóstwo projektów, które są już wieloletnie albo dziesięcioletnie i nadal trzeba je w jakiś sposób utrzymywać. W momencie, kiedy tworzenie kodu przez AI jest łatwe, jest szybkie, to jak się tutaj ta perspektywa utrzymania legacji projektów zmienia? Czy ten kod, który nie zawsze jest, idealny, nie mówię, że wytwarzany przez ludzi jest idealny, no ale tak, często ten kod nieco gdzieś tam jakościowo być może odbiega od tego, co ludzcy, deweloperzy by stworzyli, to czy to nie powoduje albo nie będzie powodowało właśnie problemów z utrzymaniem później całego projektu w przyszłości, kiedy to nikt inny poza AI właściwie nie rozumie, co nam się dzieje pod spodem?

Maciek:
Pytanie, czy musimy rozumieć. Dlaczego mieliśmy to jakość kodu i jakości kodu nierówna? Nie mówimy o jakości kodu w rozumieniu security. Tutaj się nic nie zmieniło. Człowiek powinien to sprawdzać, testować i nie chcemy tutaj błędów, ale wszystkie frameworki, które się pojawiły, czy zasady programowania były dla ludzi, bo my mamy ograniczony kontekst. Możemy przeczytać 10 plików, te pliki nie powinny być za długie. Robiliśmy wszystko, żeby sobie ułatwić. AI tych ułatwień nie potrzebuje. Jeśli ktoś doprowadzi te modele do tego, że one rzeczywiście wytwarzają kod, który jest dalej rozwijalny, no to czy oni sobie to w kropkach napiszą, czy napiszą w kodzie, mnie to nie do końca interesuje. Mnie interesuje to, żeby to było deterministyczne i żeby nie było, jeśli nawet 1% jest prawdopodobieństwo, że to skręci w bok, to to jeszcze nie jest gotowe. Jeszcze nie możemy temu zaufać. W momencie, jak będzie to zaufanie, no to się zmienia cała gra.

Maciek:
Jeśli chodzi o pracę z Legacy Codem, trzeba bardzo powoli, bardzo małymi etapami i dokładnie tak, jak to było kiedyś. Tylko zyskujemy możliwość, że jesteśmy w stanie przepisać to Legacy znacznie niższym kosztem.

Maciek:
Więc możemy zacząć od, i tutaj by się dobrze sprawdził Spec-Driven Development, który będzie bardzo powoli budowany, czyli najpierw próbujemy zmapować to legacy, dowiedzieć się, jakie quality ma to legacy, może dołożyć te testy, których do tej pory brakowało, no i potem możemy odpalać inicjatywy, jak powoli z tego legacy wychodzić. No i znacznie łatwiej biznesowi przetłumaczyć, słuchaj, wyprowadzimy to legacy w trzy miesiące, zaangażujemy do tego cały zespół, ale pamiętasz, że te wszystkie problemy nagle przestają istnieć, które mieliśmy do tej pory.

Maciek:
Biznes lubi takie rzeczy, bo to im otwiera, przedtem musieli, wiedzieli, że dłużej będzie trwał development, bo kod jest zły. No to teraz i blokowało ich to, że ktoś chce wydać pół roku na poprawę i oni potrzebują feature’y. Teraz możemy znaleźć albo rozwiązań, albo możemy to napisać całkowicie od nowa, bo koszt nowego rozwiązania jest znikomy w porównaniu do tego, co było wcześniej, no albo możemy zacząć wprowadzać struktury. A dobrze napisany agent może to robić dniami i nocami. Więc o ile programista wie, jak rozwiązać problem legacy i wyprowadzić ten projekt, no to jest potęgowany przez agentów i to ma jak najbardziej sens. Też potęgują się problemy kontekstu, trzeba uważać, czyli ja bym pewnie plik po pliku pracował, a nie próbował nagle milion plików naraz i zmieńmy całą architekturę, to się pewnie źle skończy.

Krzysztof:
Tak, myślę sobie, że to też nie jest tak trochę o tym naszym przywiązaniu do kodu. Kiedy tak wytwarzamy software, to trochę się utożsamiamy z tym, co tworzymy, a tymczasem w przypadku AI nie musimy się o to martwić. To przepisanie wręcz, więc napisanie czegoś od nowa właściwie może niewiele kosztować i wcale nie musimy myśleć o tym kodzie jako o naszym kodzie. To jest po prostu jakaś tam seria bitów i tyle, prawda? Wyrzucamy, tworzymy od nowa i problem, można powiedzieć, utrzymalności po części przynajmniej rozwiązany.

Maciek:
Ładnie napisany kod wcale nie musi być dobrym kodem. Miałem sporo do czynienia w mojej karierze z programistami, którzy napisali test i ten test nic nie testował, ale robimy test driven development. I to samo widać w AI. Programista, który wcześniej nie potrafił zapewnić tej jakości, z AI tym bardziej tej jakości nie jest w stanie zapewnić. Dlatego w branży jest ewidentnie shift na to, że musisz dobry end-to-end test napisać, nie byle jaki, to trzeba przemyśleć, to kosztuje czas. I dalej, dużo pracy pozostaje, która kiedyś była bagatelizowana, spadała na drugi plan, bo development jest drogi. Dla aplikacji na pewno powstanie dużo kiepskich aplikacji i one od razu będą legacy kodem, a dużo aplikacji się wyciągnie z legacy kodu dzięki temu.

Krzysztof:
Mówi się o tym, że AI zmniejsza zapotrzebowanie na juniorów, także tutaj wiele z tych rzeczy często prostszych można spokojnie sobie z swoimi

Krzysztof:
agentami ogarniać, nie ma potrzeby zatrudniania juniorów. A jak to na przykład jest z seniorami w Twojej opinii? Czy to, że mamy możliwość wytwarzania tego kodu dosyć łatwo, czy to też nie spowoduje właśnie takiego efektu, że zapotrzebowanie na seniorów się zmniejsza, będzie zmniejszało, bo ktoś, kto może nie ma takiego doświadczenia, być może nie ma aż takich wymagań finansowych, z wykorzystaniem tych narzędzi będzie w stanie podobne efekty po prostu uzyskiwać.

Maciek:
Myślę, że tutaj zajdzie ten sam fenomen, który widzimy z programistami, którzy jeszcze nie zrobili tego skoku z meet developera na senior developera. Jak w ogóle development się rozwijał? Na początku mieliśmy dużo specjalistów, którzy tak jak wspominałeś o tym assemblerze, Skill zrozumienia Assemblera i poruszanie się Assemblerem a C++ to jest nieboła ziemia. Kto jest Assemblera, bez problemu wykorzysta C++, w drugą stronę już niekoniecznie. Więc z mojej perspektywy era, gdzie my mieliśmy naprawdę dobrych programistów, no to się skończyła, bo oni byli bardzo długo na rynku. Ja sam jestem z rzutu tego bardziej, powiedzmy, już frameworki były, ale podstawy rozumiałem, wiem jak działał PHB, wiem jak JavaScript, wiem jakie były ograniczenia, tak jak mówiłeś, teraz wszystko się dzieje u klienta w browserze,

Maciek:
Wykorzystujemy pamięć przeglądarki trochę jak bazę danych, no to osoby, które na tych technologiach się wychowywały, one rzeczywiście rozumieją jak ta technologia działa. Potem programiści, którzy wyszli z bootcampów, no to oni już się, tak jak my się uczyliśmy na wysoko poziomowym języku programowania, to oni się uczyli już na frameworkach, gdzie security mam. Tak piszę w dokumentacji, tak tworzę endpoint, tak się robi w projekcie. I oni są dobrzy w jednym projekcie. Może zmienili pracę, to potrafią się poruszyć, mają wiedzę z dwóch projektów. To jest zupełnie inna jakość niż senior, który rozumie od podstaw, jak to się składa. No i teraz, jak ta praca jest potęgowana, no to senior widząc, intuicyjnie widzi, AI źle skręciłeś, kręcisz się w kółko, ja cię zatrzymam, dam ci brakującą informację, zachowałem tokeny, nie uderzę w żadny limit albo nie wygeneruję dużych kosztów. Meet developer, i to już widziałem, będzie się kręcił w kółko, bo nie rozumie, że trzeba rozwiązać ten problem, że AI coś zrobiło źle i warto się dowiedzieć, co się wydarzyło. I odpowiadając na twoje pytanie, seniorzy myślę, że będą na wagę złota, zwłaszcza, że nie jesteśmy stworzyć nowych seniorów. Czyli już junior nie będzie w stanie pozyskać tego doświadczenia, które kiedyś.

Krzysztof:
Trochę zjadamy swój ogon, prawda, jako branża?

Maciek:
Tak i dlatego bardzo ważne jest, żebyśmy przestali programować i żeby wyciąć ten problem, co to spowoduje, damy młodszym osobom, bardzo kreatywnym i zaangażowanym na wykorzystywanie tego potencjału. I tutaj nie wiem, co się wydarzy. Na pewno bym nie zwalniał moich seniorów, byłbym ostrożnie z zatrudnianiem juniorów, ale nie bagatelizowałbym tego świeżego spojrzenia, zwłaszcza, że to nowe pokolenie wychowało się zupełnie inaczej niż my i dla nich technologia przechodzi strasznie szybko i oni widzą połączenia, których my nie widzimy, bo jesteśmy dinozaurami w pewnym sensie technologicznymi w porównaniu z nimi.

Krzysztof:
Tak, nie boją się eksperymentować, nie boją się wykorzystywać właśnie tych narzędzi w nieoczywisty sposób. Ta kreatywność, o której wspomniałeś jest pewnie tam na wyższym poziomie. To myślę, że może być ta karta przetargowa za jakiś czas, no bo faktycznie… Pewnej wiedzy czy pewnego doświadczenia nie da się tego etapu gdzieś skrócić, w jakiś sposób uzyskać szybciej, pewnych rzeczy nie przeskoczymy, ale właśnie tutaj myślę, mówiąc do tych osób, które myślą o wejściu do branży albo są na początku, to czymś innym trzeba po prostu grać, inną kartą trzeba w tym przypadku grać, a nie doświadczeniem.

Krzysztof:
Dobrze, rozmawiamy dzisiaj o spec-driven development. Czy według Ciebie to, jak teraz to widzimy, jak to definiujemy, to jest jakaś postać ostateczna, można powiedzieć, tego podejścia? Czy będziemy jeszcze widzieć zmiany, modyfikacje, ewolucja? Jeśli tak, to w jakim kierunku?

Maciek:
Ciężko powiedzieć, bo nawet tego spec driven to jest coś, co dopiero się zaczyna trendować i do tego doszliśmy w ciągu czterech, sześciu miesięcy jest dość spora zmiana na rynku. Na pewno rzeczy łatwe, w cudzysłowie łatwe, czyli coś, co jest przewidywalne, powtarzalne i można zamknąć w jakichś ramach, no to to będzie uciekać z rynku. Więc na przykład aspekty projektowania zostaną zoptymalizowane. Teraz się zastanawiamy ponownie nad tym, jak prowadzić development. No i te rzeczy znowu AI będzie mądrzejsze, będzie przejmować, nie wiem, będziemy mieli wirtualnych PM-ów, wirtualnych programistów lub bardziej atomowe skille. W to nie wątpię. Myślę, że będzie drożej. I to jest gdzieś tutaj, może nas zatrzymać. Nie wiem, jak ten problem zostanie rozwiązany. Jak zapewne wiesz, praktycznie nikt nie korzysta z AI, żyjemy w pewnej bańce. No i jeszcze w tej bańce dość dużo osób nie płaci.

Maciek:
Więc osoby, które płacą, no to są uprzywilejowane, że jeszcze te limity tak bardzo nie bolą. W pewnym momencie nie będę się wymądrzał, może to nie być problemem i wtedy myślę, że na pewno będziemy widzieć nowe wersje i bardziej będziemy się poruszać w samym project managementcie niż w technologii.

Maciek:
Albo będzie blok, bo jest to za drogie I będziemy musieli przez jakiś czas się rozwiązać ten problem. Jeszcze pytanie, czy problemy energetyczne tych wszystkich data centrów nie staną się w pewnym momencie problemem. Ciężko powiedzieć. Na pewno narzędzia będą przypływać teraz masowo. Jest bardzo ciekawy czas na wypuszczanie swojego produktu. Ciekawe, że jest to łatwe i daje dużo możliwości, a zarazem bardzo duża konkurencja. Wszyscy próbują rozpoznać w tym marketingowym sumie prawdziwe informacje. Jest ciężko, dlatego warto samemu sobie to testować. No i tak jak mówię, tutaj cały czas wymyślają te same osoby, jak rozwiązać problem, który mamy od lat. Może te młodsze osoby zakwestionują to status quo i nagle pomyślimy sobie, że idea jest bez sensu. I dało się… Może dobrym przykładem jest to, że odkąd jest czat, to tak naprawdę interfejsy przestały mieć sens.

Maciek:
Jeszcze sasy idą w stronę, że masz tego asystenta, masz tych agentów, możesz coś z nimi zrobić przez czat, ale de facto ja nie chcę wchodzić na Google Drive, ja nie chcę wchodzić na moją pocztę, ja chcę mieć po prostu wirtualnego asystenta, który mi powie, hej, przyszedł mail, pewnie jest ważny, jakie są twoje myśli, to ja odpiszę i tyle chciałbym. I w tą stronę będziemy iść, tak mi się wydaje, jeśli tylko pieniądze i technologia na to pozwoli.

Krzysztof:
Tak, jest wiele zmiany, które faktycznie mogą na to wpływać. Ja tak sobie myślę, czy ten główny problem, może nie problem, ciężar, który teraz gdzieś jest związany właśnie z tym podejściem z Pack Driven Development, czyli konieczność przygotowania dobrego wkładu, żeby uzyskać adekwatne efekty, czy to też nie będzie w jakiś sposób minimalizowane przez te narzędzia? Czyli być może one będą dopytywały, może będą od nas wyciągały te informacje, albo przedstawiały jakieś możliwości. Myślę sobie, że tutaj istnieje jeszcze jakieś tam pole do usprawnień i do jeszcze obniżenia tego progu wejścia. Tak jak powiedziałeś, zobaczymy, bo tutaj ten faktycznie aspekt kosztowy.

Krzysztof:
Energetyczny, środowiskowy też jest nie bez znaczenia. I dotknęliśmy tego dzisiaj, ale świat rzeczywisty też dotyka, jakby nie było tutaj ten świat cyfrowy w ten sposób.

Krzysztof:
Dobrze, Maćku, myślę, że dobrnęliśmy do końca naszej rozmowy. Chciałbym Ci bardzo podziękować za to spotkanie, podzielanie się swoimi przemyśleniami. Słuchaczom przypominamy o konkursie, w którym do wygrania jest książka Andrzeja Dragana, właśnie tutaj ufundowana przez Maćka i Primotli. Trzeba a jedynie we wpisie na Linkedinie, który towarzyszy temu odcinkowi podcastu, napisać jak wykorzystaliście jakąś myśl, jakąś poradę z tej naszej dzisiejszej rozmowy, co to przyniosło, no i dla osoby, która najciekawszy odpowiedzi udzieli, właśnie prześlemy wspomnianą książkę. Maczku, bardzo Ci dziękuję za spotkanie.

Maciek:
Dziękuję bardzo. Super się bawiłem. Bardzo przyjemna rozmowa.

Krzysztof:
Cieszę się bardzo. Powiedz jeszcze na koniec, gdzie Cię można znaleźć w internecie, gdzie możemy słuchaczy odesłać.

Maciek:
Najlepiej na LinkedInie, Maciej Kemnitz lub przez Primodly.

Krzysztof:
Oczywiście te wszystkie linki będą w notatce do odcinka. Jeszcze raz Ci bardzo dziękuję. Udanego dnia i cześć.

Maciek:
Dziękuję. 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 lub mailowo na krzysztof@prozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek Prozmawiajmy.it o Spec-Driven Development. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się backendem aplikacji internetowych i zarządzaniem działami IT. Dodatkowo prowadzę podcast, występuję na konferencjach i jestem autorem książki "Marka osobista w branży IT". Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.

No Comments

Post A Comment