Marcin Wierzbiński - Vibe coding. Serio?

Cześć, witam was w kolejnym odcinku podcastu Stacja IT. Dzisiaj rozmawiamy o vibe codingu, a z nami jest Marcin Wierzbiński. Cześć Marcin.

Marcin jest ekspertem uczenia maszynowego, sztucznej inteligencji. Zajmuje się od pewnego czasu również programowaniem, właśnie z wykorzystaniem sztucznej inteligencji. A więc tym tematem, o którym chcemy dzisiaj porozmawiać.

Może na początek powiedz Marcin właśnie parę słów o sobie. Jak doszło do tego, że zająłeś się vibe codingiem?

Więc witam. Bardzo się cieszę. Dzięki Łukaszu za zaproszenie do tego podcastu. Ja jestem programistą właściwie od już 10 lat. I w międzyczasie pojawił się deep learning w moim życiu. Zacząłem się tym zajmować tak naukowo, bo też pracuję jako asystent naukowy na Uniwersytecie Warszawskim. I miałem też przyjemność tworzenia swojej pracy magisterskiej już w deep learningu, jeszcze kiedy to nie było modne, tak bardzo jak teraz. Takie pojęcie generatywne AI wtedy jeszcze nie istniało. I od tego czasu pomyślałem, że połączę tak naprawdę dwie swoje pasje. Czyli głębokie uczenie maszynowe i programowanie. I okazuje się, że modele sztucznej inteligencji, duże modele językowe, pomagają nam wytwarzać to programowanie, tworzyć kod. Też opowiemy sobie o pewnych wyzwaniach i szansach związanych z wykorzystaniem tych narzędzi. Jestem bardzo ciekawy, tak szczególnie naukowo, jak ta perspektywa się będzie rozwijała w przyszłości. Do jakiego momentu te modele będą faktycznie dobre, czyli będą w stanie przezwyciężać ten tak zwany problem alignementu. Czyli będą dobre co do naszych oczekiwań. I to też szczególnie w kontekście tworzenia kodu, tworzenia oprogramowania. Na ile to AI będzie w pełni wystarczalne, jeśli chodzi o tworzenie takiego kodu, który nas jak najbardziej satysfakcjonuje.

To może właśnie zacznijmy od tych kwestii takich pojęciowych. Tutaj właśnie mówimy o vie codingu. To jest takie pojęcie, które najpierw się kojarzyło jakoś tak właśnie bardzo pozytywnie, że to można szybko tworzyć kod, szybko tworzyć aplikację, że sztuczna inteligencja właśnie wszystko nam tutaj załatwia.
Później pojawił się trochę taki wydźwięk pejoratywny w zasadzie. Co to jest ten vibe coding? To jest tworzenie jakichś potworków, którymi potem trudno zarządzać.
Jak ty na to patrzysz? Czy właśnie też dla ciebie to jest pojęcie właśnie jakoś tam nacechowane w którąś stronę? Czy niekoniecznie, czy po prostu tak nazywasz tworzenie kodu właśnie z wykorzystaniem sztucznej inteligencji?

Faktycznie w ogóle vibe coding to dla mnie na ten moment jakiś pewnego rodzaju taki buzzword, który niekoniecznie jest idealnie wytłumaczony. Więc może tak na samym początku powiem taką definicję tego, czyli jest to pewnego rodzaju styl kodowania, gdzie z użyciem poleceń w języku naturalnym, na przykład w języku polskim, wykorzystujemy duży model językowy do generowania kodu i później naszym głównym, główną naszą ważną tutaj cechą programisty jest to, żeby monitorować to, w jaki sposób ten kod jest stworzony, jaką ma jakość, testować i ewentualnie debugować. I z tym pojęciem, tak jak wspomniałeś, na samym początku wiązały się bardzo duże oczekiwania, że właściwie ten vibe coding to zrobi za nas robotę i tak dalej.
Ale tutaj warto wspomnieć, że tworzenie oprogramowania to coś więcej niż stricte pisanie kodu. To przede wszystkim analiza dokumentacji, analiza różnych wymagań technologicznych, to myślenie o architekturze, to rozwijanie później tego oprogramowania, to pisanie testów, to cały czas tak naprawdę praca nad kodem, bo kod jest cały czas ulepszany, przychodzą nowe funkcjonalności, klienci od nas też wymagają tego, żeby, żeby ten kod był utrzymywany, czyli wszelkiego rodzaju ułatwienie bugów. I tak naprawdę w tym przypadku vibe coding bardzo dobrze sprawdza się do wytwarzania oprogramowania takiego prototypowego, takiego MVP, czy na hackathonach, czy do aplikacji pod jakieś pitche inwestorskie, czyli kiedy chcemy zbudować faktycznie przez weekend, siedząc sobie w swoim domu jakąś aplikację, która, która będzie prototypem, ale jeszcze oczywiście daleko jej do takiej pełnej wersji stabilnej produkcyjnej, bo też często jest tak, że w kontekście takiego wytwarzania oprogramowania, to wyróżniamy tutaj kilka etapów. Na samym początku to jest ta kwestia planowania odpowiedniego, czyli budowania architektury, zbierania domeny, myślenia o tym jak ta aplikacja, co ona ma robić, jakie ma mieć komponenty, też technologicznie, z czego ma się składać. I dopiero tak naprawdę po tym etapie zaczynamy pracę ze stworzeniem kodu do tej aplikacji i później jest proces testowania, wdrażania i utrzymywania.
I na tym procesie stricte tworzenia kodu, jak najbardziej ten vibe coding może zostać wykorzystany, aczkolwiek są pewne ograniczenia też tego vibe codingu, więc przede wszystkim taką podstawową rzeczą jest oczywiście kwestia halucynacji, która sprawia, że modele generują odpowiedzi niekoniecznie zgodne z prawdą, czyli może to być wygenerowanie jakiegoś fragmentu kodu, który jest niedostępny w danej bibliotece, jakiejś funkcji na przykład, której nie ma w tej bibliotece. Mogą to być zmyślane jakieś parametry do danej funkcji.
Niestety też na ten moment sztuczna inteligencja nie do końca dobrze radzi sobie z tym, że w świecie wytwarzania oprogramowania, kiedy korzystamy z jakichś bibliotek, to właściwie cały czas musimy te biblioteki utrzymywać i łatać ich takie krytyczne błędy, na przykład security. To jest kolejny problem, który na ten moment jest, że trenując takie modele językowe, trenujemy na korpusach, tak naprawdę na całym internecie trenujemy dostępnym w różnych książkach i tak dalej, ale trenujemy na pewnym momencie zastanej tej wiedzy. Więc jeśli te modele są trenowane, to też przeglądają one takie biblioteki, które są w odpowiednich wersjach i to też jest pewne wyzwanie, czyli modele językowe na ten moment stosunkowo słabo radzą sobie z takimi skrajnościami, czyli albo z nowymi bibliotekami, na przykład wychodzi jakaś nowa wersja Reacta i model językowy ma z tej wersji korzystać, takie mamy oczekiwania wobec niego, albo taka druga wersja, czyli mamy jakiś bardzo archaiczny kod w języku, który jest mało reprezentowany na przykład w internecie, ale nie tylko, może to być jakaś po prostu starsza biblioteka, która już też nie jest rozwijana i gdzieś tam też nie ma takiej tak naprawdę do niej dokumentacji albo dostępu, to wtedy tak naprawdę faktycznie te narzędzia, te modele językowe sobie tutaj trochę słabiej radzą.

To może tutaj jeszcze właśnie wtrąćmy, żeby wszyscy znali ten sposób, w jaki te modele powstają, czyli taki model, z którego korzystamy do programowania, w takiej podstawowej wersji ma jakąś swoją wiedzę, kiedyś tam wyuczoną w jakimś punkcie czasu i to jest właśnie to, co mówisz, czyli że widział dokumentację iluś tam bibliotek, w iluś tam wersjach, ale być może nie widział wszystkiego, bo nie istnieje coś w internecie albo z kolei potem pojawiła się nowa wersja.

Czy to oznacza, że właśnie, czy w jakiś sposób można to obejść, czy tutaj są jakieś podejścia, które stosują tutaj te narzędzia do tego, żeby właśnie dopasować się do wersji jakiejś biblioteki czy właśnie skorzystać z dodatkowych źródeł informacji, które mogą w tym programowaniu pomóc, bo gdybyśmy byli zamknięci tylko w tym takim pojedynczym bąbelku wiedzy, to wtedy by to nam nie uniemożliwiało albo korzystanie na przykład z jakichś tam nowszych elementów, które powstają w przyszłości?

Tak, jest takie otwarte źródło na GitHubie, gdzie są wrzucane najnowsze dokumentacje różnych bibliotek i dzięki temu możemy dołączyć ten kontekst do naszego narzędzia. Więc jest to jedno z takich rozwiązań, czyli tak naprawdę zbudowanie tak zwanego RAGa, tak, czyli że mamy jakieś nowe źródło wiedzy, nie musimy trenować na nowo tego modelu na tej dokumentacji, ale możemy sobie zrobić taką wyszukiwarkę wiedzy w tej dokumentacji i ta wyszukiwarka nam tę wiedzę z tej dokumentacji wyciąga, następnie idzie do modelu językowego, dołącza tę wiedzę, i model językowy już wykorzystuje tę wiedzę, żeby wygenerować odpowiedź. To jest jedno z takich, takich rozwiązań. Kolejne rozwiązanie, które już w niektórych agentach jest, jest, jest, jest przygotowane, to jest wyszukiwanie w internecie.
Czyli faktycznie też znowu RAG, tylko taki, że mamy wyszukiwarkę, dostęp do internetu, model wyszukuje sobie na przykład tam 10 najbardziej pasujących wyników w oparciu o nasze zapytanie i wykorzystuje to jako kontekst, tak żeby wygenerować nam też odpowiedź. To ogranicza halucynacje, czyli takie zmyślanie rzeczy, które niestety ta technologia ma i to będzie ciężko, że tak powiem uniknąć, czyli takie przekonanie, że to, co on generuje, jest prawdziwe. Ten model ma takie przekonanie. Nie zawsze je wyeliminujemy całkowicie, bo to znowu jakby popatrzeć na technologię takiego modelu językowego, to model językowy ma na zadanie generować nam najbardziej prawdopodobne słowa, które się tam w logiczną jakoś całość składają. Znaczy, to jest duże uproszczenie, bo to chodzi o tokeny, a nie słowa, ale powiedzmy, możemy tutaj sobie uprosić, że, że chodzi o słowa. Więc mimo wszystko i tak to słowo może być błędnie wygenerowane.

To może jeszcze właśnie, jak jesteśmy przy tym kontekście, o dołączaniu kontekstu, to jedna sytuacja jest taka, że właśnie chcemy tam mieć dostęp do szerszej dokumentacji, do jakichś bibliotek i tak dalej, ale też mamy ten nasz własny kod, który chcemy analizować i być może jakieś nasze własne biblioteki, które, które nie są dostępne w szerokim internecie. Czy to wszystko możemy dołączyć do tego modelu? Czy tutaj są jakieś ograniczenia?
Właśnie tak, żeby mógł rozumować też na podstawie tego, co my mamy dostępne tutaj wewnętrznie, lokalnie, tak?
Tak i tutaj faktycznie warto wspomnieć o kilku technikach pracy i wydaje mi się, że to też jest jedno z takich problemów z tym, czym nam się kojarzy vibe coding, że raczej myślimy sobie tak, odpalam sobie chat GPT, przecież każdy umie promptować, wpisuję sobie prompt i on mi generuje kod. Okazuje się, że ten kod jest na przykład zbugowany albo jest jakoś niekoniecznie dobrze napisany i tak dalej. Właśnie wszystko jest takim problemem, że właściwie te modele, główna ich idea, taki dobry model jest dobry w czymś takim, że powinien być dobry w tak zwanym zero shot learningu, czyli nie ma danych w treningu, ale dobrze uogólnia tę wiedzę.

Czyli na przykład nie ma takiego zadania prostego matematycznego, a 4 plus 4 równa się 8, ale on generatywnie jest w stanie to zadanie rozwiązać. I tutaj ważną sprawą to jest to odpowiednie dołączenie kontekstu. I są takie narzędzia, które są stricte dedykowane już do tego, że to narzędzie przegląda nasz codebase, zaczyna rozumować zależności między danymi modułami, na przykład tutaj weźmy sobie jakiś tam framework taki Django, pythonowy do tworzenia aplikacji webowych, to jest ten framework tak zorganizowany, że mamy różne fragmenty aplikacji w różnych folderach i takie narzędzie na przykład jak Cursor czy Windsurf, które jest jak naprawdę zintegrowane z agentem, czyli mamy znowu zbudowany takiego technologicznego RAGa, który z jednej strony korzysta z naszego codebase, patrzy na nasz kod, przegląda te zależności i odpowiednio wyszukuje, co jest dla niego ważne i wykorzystuje ten kontekst do tego, żeby później wygenerować nam odpowiedź.
Tutaj jako ciekawostka mogę powiedzieć, że jeżeli na przykład chcemy załatać jakiś prosty błąd, to ten prosty błąd, nie wiadomo czy jest on konkretnie w tym miejscu, czy jest to jakaś tam głębsza zależność z innymi rzeczami. Jeśli taki edytor chciałby taki błąd rozwiązać, czyli dać wynik co jest błędne, to on przegląda różne pliki, poszukując pewnych zależności z tym plikiem, w którym ten błąd jest i wysyła to do API. Takie API kosztuje nas stosunkowo sporo, bo tutaj my płacimy za to, ile tokenów jest przesłanych do tego API.
Tak w okolicach to jest na przykład 400 tysięcy, 100 tysięcy tokenów. Czyli to pokazuje, że narzędzie takie jak Cursor czy Windsurf, on gromadzi bardzo duży, szeroki kontekst, uderza do na przykład czata GPT-5 teraz, czy Cloda 2.5, czy jakichś innych, czy Gemini. Cloude, przepraszam, to chyba jest Sonnet ten Cloude, ale wykorzystuje po prostu te najnowsze modele, które mają bardzo szeroki kontekst, ale tutaj kolejny problem jest taki, że oczywiście nie mamy nieskończonego tego kontekstu.
Czyli ten model może generować, przyjmować skończoną liczbę tekstu i generować skończoną liczbę tekstu. Więc to też pewnego rodzaju jest minus tego podejścia, wykorzystując modele językowe do generowania kodu.

To może właśnie jeszcze powiedzmy parę słów o narzędziach, bo tutaj już o tym wspomniałeś, natomiast dla tych, którzy korzystali do tej pory tylko z takiego okienka webowego w czat GPT, to tutaj tym dodatkiem, który dostajemy od narzędzia, jest właśnie takie sprytne zarządzanie tym kontekstem, tym co przekazujemy do modelu, że właśnie jak najmniej zapewne chcemy przekazać do tego modelu, żeby ograniczyć koszty, ale żeby to były te rzeczy, które są relewantne do rozwiązania jakiegoś problemu. Czyli taka podstawowa opcja to jest korzystanie właśnie z modelu poprzez okienko webowe, a tym bardziej zaawansowanym sposobem jakieś narzędzi typu klot, przepraszam, czy klucz też, ale Windsurf czy Cursor. I tutaj tych narzędzi mamy trochę do wyboru.

To jest bardzo ciekawe. Właściwie Cursor czy Windsurf bazuje na Visual Studio Code jako tako, że Visual Studio Code jest open source, więc też szybko udało mi się to ID zintegrować z agentem. I tak naprawdę polecany jest bardziej Cursor.
Okazuje się, że on właśnie stosunkowo lepiej sobie radzi z przyglądaniem codebase’u, aczkolwiek Windsurf ma swój model, do którego możemy uderzać. A w przypadku innych narzędzi, to mamy też taki stack technologiczny, bardzo, bardzo dobry, takie ID bardzo zaawansowane, tak jak PyCharm czy IntelliJ. I w tych narzędziach też już pojawiają się takie dodatkowe wtyczki, pluginy, takie jak Juni, który jest też takim agentem, czyli też wykorzystuje codebase, odpowiednio go przegląda, odpowiednio indeksuje te pliki, jakoś chunkując je i tak dalej i wykorzystuje ten kontekst do tego, żeby później uderzyć do modelu językowego, żeby ten model językowy nam ten dany problem rozwiązał.

Też mamy inne takie narzędzia, np. jeśli chcemy generować sobie aplikacje webowe, jakieś landing page’owe, z użyciem np. jakichś Reactowych komponentów, to jest teraz Replit, dosyć, dosyć fajne narzędzie, gdzie można w bardzo prosty sposób stworzyć sobie stronę opartą o Reacta i zrobić taką fajną, dynamiczną stronę wczytującą jakieś kafelki, animacje, odpowiednio też bazując na designie, który sobie tutaj zapragniemy.
Więc faktycznie tych narzędzi jest coraz więcej i one coraz to są lepsze. Ja np. też korzystam z Cursora wersji Pro i to jest koszt właściwie 20 dolarów miesięcznie, więc stosunkowo nie taki duży.
Mamy tak około 350 strzałów do API z tym konkretnie kontekstem. Też można kupić jakieś wyższe plany standardowo też czy bazując na zwykłym 3GPT, czy też mamy Copilota, który z kolei kosztuje 10 dolarów, ale Copilot ma bardzo fajną integrację z takimi rzeczami bardzo podstawowymi, ale np. jest w stanie pracować jako reviewer do pull request’ów na GitHub’ie, może robić nam podsumowania commit’ów, bo to są takie podstawowe rzeczy, czy np. jakieś podstawowe błędy też jest w stanie rozwiązywać bezpośrednio w naszym narzędziu, ale on się nie tak dobrze integruje z codebase’em. Też mamy takie narzędzia command line’owe, Gemini command line, które można też wykorzystywać do przeglądania codebase’u, ale też do takiego współpracy bezpośrednio swoim terminalu z AI.

Dobrze, to mamy spojrzenie, co to w ogóle są za narzędzia, czy właśnie co te modele, jakie mogą mieć ograniczenia, natomiast jak wygląda zwykle sam proces, znaczy że już właśnie chcemy też sami tym vibe codingiem się zająć, czy spróbować, właśnie jak to działa, czy działa to w taki sposób, że napiszę tutaj modelowi, zrób mi aplikację do np. zarządzania moimi zbiorem książek i to wystarczy jedno zdanie napisać i wtedy wygeneruje mi się piękna aplikacja dokładnie taka, jaką tutaj sobie wymarzył, czy ten proces jest jakiś bardziej tutaj wymagający, czy składający się z jakichś kroków.

Tak i tutaj faktycznie to jest coś, co bym powiedział, sprawia, że trochę mamy irytację na to AI, czyli mamy zbyt dużo oczekiwania wobec tej technologii. Myślę, że to też trochę bazuje na takim, takim skrócie myślowym, że tak fajnie ktoś tutaj coś takiego stworzył, właśnie jakiś wierszyk umie napisać i tak dalej i to tak nas trochę pociągnęło, ale to faktycznie nie jest tak. Tutaj potrzebujemy tej wiedzy domenowej, żeby być w stanie to zweryfikować, co ten model nam wypluwa.
Na przykład właśnie ta kwestia związana z jakością kodu, z halucynacjami, z dostępem do ograniczonych dokumentacji, nie tak świeżych. Oczywiście my możemy w jakiś sposób to ograniczać, tak jak już troszkę wspomnieliśmy, na przykład bazując na codebase, bazując na tym, że możemy sobie robić jakieś predefiniowane rule do tego, że ma korzystać z jakichś konkretnych wersji i tak dalej bibliotek, czy w jakiś sposób ma pisać testy, czy na przykład możemy dołączyć mu kontekst związany z opisem tego, czym ta aplikacja się zajmuje i tak dalej, ale tak, najważniejsza sprawa to jest skorzystanie, znaczy jest kilka rzeczy, które mogą ograniczyć trochę te problemy, o których mówiliśmy, między innymi korzystanie z możliwie najlepszych modeli, najświeższych modeli językowych, czyli te, które, które są trenowane na aktualnych danych i są dostępne w takich najwyższych wersjach, to te modele przede wszystkim, są testowane na nowych benchmarkach, mają nowe testy sprawdzające, czy na przykład mało halucynują, czy mają sykofonację małą, tak, czyli taki sposób tego, że model jest, że jesteśmy w stanie go, można delikatnie mówiąc, oszukać i on będzie mówił, że to faktycznie jest prawda i mamy rację i tak dalej, czy też, ważna sprawa, to odpowiedni ten prompt, mimo wszystko inżynieria tworzenia tych promptów, czy tych pytań do modelu językowego i to są takie rzeczy, które, które sprawiają, że faktycznie trochę lepiej jesteśmy w stanie sobie z tym modelem współpracować, czyli niestety tutaj potrzebna jest nam wiedza, nawet taka programistyczna, żeby być w stanie później zweryfikować to, czy, czy ten model faktycznie wygenerował nam to, co trzeba i oczywiście wykorzystywanie tego odpowiedniego kontekstu, czyli na przykład w Cursorze możemy sobie pracować na zaznaczeniu, możemy zaznaczyć sobie fragment kodu, który chcemy, który, który chcemy zmodyfikować, możemy też pisać sobie testy, możemy też wykorzystywać takie narzędzia, które były kiedyś wykorzystywane, nadal oczywiście też w wytwarzaniu oprogramowania, które mają za zadanie zminimalizować ryzyko wypuszczenia jakiegoś błędu krytycznego na, na produkcję, czyli continuous integration, continuous delivery, wszelkiego rodzaju rollbacki.
Mamy teraz świetnie zintegrowane z repozytoriami automatyczny deploy na środowiska produkcyjne, testowe, jakieś release’owe, więc to wszystko faktycznie można wykorzystać do tego, żeby, żeby pomimo tego, że korzystamy z tego, z tych AI-owych rozwiązań, żeby właśnie ograniczyć ewentualnie problemy z generowaniem błędów. Też jest jakaś analiza kodu, lintery na przykład, tak, można, można je, można je oczywiście też wykorzystywać do tego, żeby sprawdzać tę jakość kodu, ale pisanie wszelkiego rodzaju testów jednostkowych, integracyjnych, systemowych, jak najbardziej tutaj problemy związane z generowaniem tego kodu i tak, można po prostu te problemy ograniczyć.

Tutaj już testy, czy właśnie dalsze modyfikacje kodu, to są te elementy, które wymagają wiedzy programistycznej, natomiast jeszcze na poziomie właśnie takiego, powiedzmy, prawdziwego vibe kodera, w tym sensie,że osoba, która niekoniecznie się zna na programowaniu, ale chce sobie wytworzyć jakąś tam fajną aplikację czy rozwiązanie, nie to, czy to możemy jakoś wpłynąć na ten model, żeby, wytworzył faktycznie to, co byśmy chcieli, bo ja tutaj trochę specjalnie powiedziałem wcześniej, że tak jednym zdaniem określam to, co bym chciał, tak, nie wiem, tam właśnie aplikacja do katalogowania książek, czy, nie wiem, zarządzania tym, kto tam tę książkę ode mnie wypożyczył.

Natomiast, być może ja mam w głowie jakąś wizję tej aplikacji i wydaje mi się, że ja tym jednym zdaniem to wyraziłem, co bym chciał, natomiast ten biedny model to tak naprawdę nie wie, co ja chcę, tak, czy to w ogóle ma być aplikacja webowa, czy to ma mieć te aspekty właśnie, nie wiem, zarządzania w tym sensie, że ktoś ode mnie wypożyczył książkę, czy ja chcę po prostu sobie zapisać, co mam, a może chcę sobie zapisać, że mam coś na półce, albo, albo w którym pokoju i tak dalej. Czyli, że tutaj to doprecyzowanie w ogóle, o co mi chodzi, chyba jest też ważne na tym początku drogi, prawda?

Tak, czyli odpowiednio dookreślenie, co konkretnie ta aplikacja ma robić, czyli czy ma zajmować się stricte właśnie, tak jak mówiłeś, tylko jako wypożyczalnia książek, czy ma jakiś szerszy kontekst. Niestety testując trochę te narzędzia do generowania takich aplikacji, faktycznie one mają taką tendencję, można powiedzieć, dorzucania też swoich jakichś rzeczy, czyli takich, można powiedzieć, że znacząco więcej jakby taki model wypluł, niż może od niego oczekujemy. Co, właśnie, bo lubi generować znacząco więcej niż od niego oczekujemy.
Ten problem alignementu, czyli tego dopasowania naszych oczekiwań z tym, co model generuje, jest, jest jeszcze faktycznie tutaj, tak, i jasność też tak naprawdę tego, co od niego chcemy, czyli w jakiej technologii, w jakich konkretnie, w jakich wersjach, ale też problem jest trochę z tym kontekstem, że nie możemy mu dać za dużo, bo wtedy też zaczyna przesadzać, więc takie iterowanie się tym modelem poprzez tworzenie kolejnych jakichś modułów sprawia, że faktycznie ten efekt końcowy jest coraz bardziej zgodny z naszymi oczekiwaniami.
Modułów, czyli tutaj jakby rozumiesz to podzielenie sobie na jakieś etapy, tak, tworzenia tej aplikacji i tworzenia takich specyfikacji do poszczególnych etapów, tak, i proszenia o to, żeby, żeby one zostały wytworzone, tak.

Tutaj à propos też weryfikacji tego, czy jakby ten kod, który powstał, robi to, co miał robić, to tutaj też podobało mi się to, co jest chyba w tym narzędziu replit, nie wiem, czy w tej chwili nie, nie oszukuję, ale w każdym razie jakby model tworzy kod i ta aplikacja się uruchamia i ma, skoro ma jakiś interfejs graficzny, ten interfejs graficzny się renderuje, jest robiony screenshot tego, co się wygenerowało i ten model sprawdza, czyto, co się wygenerowało, jest faktycznie tym, co się miało wygenerować. Także to już jest takie agentowe bardziej podejście. Oczywiście, że to nie jest jeden strzał, że tam wygeneruje kod i do widzenia, tylko jeszcze jest jakby taka weryfikacja, tak jak my piszemy jako programiści jakieś testy powiedzmy w interfejsu użytkownika, to tak ten model, prawda, może to sobie sprawdzić, więc to są fajne takie dodatkowe możliwości tutaj jeszcze uodpornienia się pewnie na te błędy.

Tak, tak. Na przykład właśnie w Cursorze jest też tak, że jak stawiamy sobie aplikację webową, to ten proponuje nam kod, komendy uruchomienia, sprawdzenia checkiem, na przykład w Django można sprawdzić checkiem, czy są jakieś błędy w tej aplikacji. Jeżeli te błędy są, to on je po prostu tak iteracyjnie poprawia aż do momentu, kiedy faktycznie ta aplikacja będzie bez błędów, tak jak powiedziałeś też w Replicie.
Czyli już coraz bardziej te, te narzędzia idą w taką stronę, żeby faktycznie robić też, testować czy to, co zostało wygenerowane, jest poprawne, a jeżeli nie jest, to robimy kolejną iterację i takie poprawki i tak do momentu, aż to faktycznie wszystko będzie poprawione.

To trochę już mówiliśmy właśnie o dokumentacji, o testach, ale właśnie też jeszcze tutaj to podsumowując to, w jakich aspektach te modele mogą nam się przydać, tak? Znaczy, bo oczywiście w generowaniu kodu doszliśmy nawet do tego, że do weryfikacji, tak, czy ten kod działa, ale właśnie, tak by przy tworzeniu rozwiązań informatycznych, jest wiele tych aspektów właśnie, jak dokumentacja, czy testy, czy tutaj też to się sprawdza, czy są jakieś problemy, czy z twojego doświadczenia, gdzie to dobrze, fajnie działa, gdzie są jakieś ograniczenia.

Tak, więc ta pierwsza faza, czyli tak naprawdę tworzenie wymagań, czyli dokumentacji, w takim podejściu scrumowym to chcemy tę dokumentację skroić na story konkretne. Czyli przerzucić to faktycznie na zadania dla programistów, właściwie takie większe zadania, które później już będą jakimiś konkretnymi technicznymi rzeczami. Więc tutaj model językowy może nam pomóc do tego, żeby rozbić ten cały zbiór wymagań od klienta na przykład na poszczególne story. Też stworzyć te historyjki do story, stworzyć kryteria akceptacji. Trzeba to weryfikować, bo czasami jest tak, że wrzuca do tego story znacząco więcej niż, niż byśmy chcieli, czyli wrzuci jeszcze na przykład wysyłanie powiadomień mailowych i tak dalej. Nagle się okazuje, że ta zależność sprawia, że to story się stało właściwie czymś więcej, niż byśmy chcieli, czyli ma tę zdolność trochę do generowania jeszcze dodatkowych rzeczy.
Kolejna kwestia to też współpraca z takim modelem do ewentualnego prototypowania, wyszukiwania jakichś, jakichś technologii, ale też tak naprawdę uczenia się technologii, na przykład jak ktoś jest backend developerem i programuje w Javie albo w Pythonie, a chciałby się nauczyć Reacta czy TypeScriptu, czy jakichś innych narzędzi, to faktycznie tutaj myślę, że będzie miał po prostu szybszą ścieżkę do nauczenia się, bo po prostu łatwiej będzie mu zrozumieć dzięki takiemu agentowi.

Ja też przepraszam się, wtrącę, mam wrażenie, że te modele mają też bardzo zróżnicowany poziom wiedzy na temat różnych technologii, to znaczy, no, właśnie jak tam się tworzy taką typową aplikację webową, to one najczęściej chcą tam to robić w Reakcie i czymś tam jeszcze, w jakichś popularnych technologiach tam CSS-owych bibliotekach. Natomiast jeśli poprosić o zrobienie tej samej aplikacji, ale w czymś bardziej niszowym np. ja lubię bibliotekę Jekyll do generowania estetycznych stron.

Właśnie te modele, które testowałem jakiś czas temu, więc może to się zmieniło, ale wtedy z tym Jekyllem nie mogły poradzić, nawet zsetupować środowiska, żeby to się kompilowało. A także to chyba też właśnie wynika z tego, ile tych danych treningowych było na świecie, tak? Oczywiście im bardziej niszowa technologia, to było ich mniej i w związku z tym będą się najczęściej na tym wykładały po prostu, więc to też jest jakiś taki bajas, że pewnie będą próbowały w tych najbardziej popularnych i być może jakieś dołączenie dodatkowego kontekstu jest wtedy potrzebne, tak?

Tak i to jest też, też taka kolejna kwestia, którą zauważam, że tak, można właśnie jakoś tam douczać się tej technologii, czy tworzyć sobie modele. Ja też oprócz tego, że programuję, jestem też wykładowcą, między innymi w Sages, wcześniej w innej firmie pracowałem i widziałem, jak ta technologia generatywna dosłownie weszła w moją pracę. Był to moment taki, że kiedyś, bardzo tak klasycznie uczyłem programować, później pojawiły się te pierwsze modele, tak jak GPT, 3.5 i tak dalej, i właściwie wszyscy zaczęli z tego korzystać w trakcie kursów programowania i faktycznie ma to pewne plusy i pewne minusy. Na pewno jeśli ktoś ma jakąś już wiedzę domenową, to jest mu znacząco łatwiej się douczyć z użyciem AI, ale jeżeli faktycznie ktoś nie, nie programował wcześniej, zupełnie i będzie chciał się przesiąść, to tutaj zaczynają się schody. Więc faktycznie takie podstawowe pojęcia związane na przykład z jakąś biblioteką, czy nawet w ogóle z językiem programowania jeszcze wcześniej, są tutaj kluczowe, żeby jakoś zdobyć i na tym etapie nie polecam się uczyć bezpośrednio, generując sobie kod. Raczej wspierając się jako taki pair programming, żeby ten model nam pomagał po prostu weryfikować i to jest bardzo miłe, na przykład przygotowując się nawet na jakąś rozmowę o pracę, gdzie jest jakiś coding session, to jest fajne, żeby popisać sobie kod i później poprosić kod, żeby ten kod na przykład nam napisał jakieś testy, zobaczył jakieś błędy i tak dalej.

Tak, czy powiedział, że coś można tam zrobić lepiej, tak? Czyli jakby taka nauka języka, czy jakiejś technologii programistycznej można powiedzieć w stylu klasycznym, czyli że od początku do końca, ale wspomagana AI w takim sensie, że jest naszym takim jakimś tutorem, pomagającym, który patrzy na to, co robimy i coś nam wyjaśnia, tak?

Rzeczywiście, jeśli sobie wyobrazić, e spróbujemy się nauczyć czegoś z takiego wygenerowanego kodu, prawda, pełnej aplikacji, w której jest tysiąc technologii i jakieś dodatkowe tutaj podpięte, biblioteki rozwiązania, to trudno coś z tego zrozumieć. To czy w takim razie byś się zgodził z taką wizją, że z jednej strony mamy narzędzie, które pozwala coś generować czasami nawet działającego dla osób, które się nie znają na programowaniu, ale to jest taki właśnie taki czysty vibe coding, w tym oryginalnym sensie, że nic o tym nie wiemy, tylko mówimy, co ma się wydarzyć i to się dzieje i czasem działa, ale to właśnie jest dla nas wtedy niedostępne, nie wiemy, co tam w środku siedzi i trudno się tym zarządza?

A z drugiej strony jest tu jakieś narzędzie, wspomagające pracę programisty, który rozumie, co robi i robi to krok po kroku, a z trzeciej strony dla osoby uczącej się może być takim, tutorem, tak? Ale nie można pomieszać tych podejść, w sensie właśnie na przykład uznawać, że w tej chwili tutaj programista jest mi niepotrzebny zupełnie, bo mogę sobie wszystko wygenerować, bo tak to pewnie nie zadziała, tak?

Tak, tak i tutaj kolejny taki etap okazuje się, że właśnie oczywiście to nie zupełnie automatyzuje nam pracę, ale trochę nam kradnie. Tego czasu, mamy trochę więcej, więc pamiętam 10 lat temu, jak zaczynałem pracę, to nie było czasu na pisanie testów, na przykład jakichś integracyjnych, po prostu tak to wszystko pędziło. Tutaj się okazuje, że możemy wykorzystać trochę AI do tego, żeby właśnie też nam te testy tworzyło. Jeśli chodzi o testy takie na poziomie funkcji, czyli takie testy jednostkowe, to AI sobie tutaj stosunkowo dobrze z tym radzi, czyli dajemy mu po prostu funkcję, prosimy go, żeby napisał nam testy, jakieś konkretne asercje.
Możemy też wymyślać jakieś przypadki, ale on też sobie stosunkowo dobrze radzi z jakimiś takimi przypadkami brzegowymi, które chcemy przetestować i tak dalej i to jest jak najbardziej ok. Jeśli mamy bardziej zaawansowane narzędzia, takie jak Windsurf czy Cursor, to możemy pisać sobie testy integracyjne, czyli on faktycznie będzie przeglądał ten cały nasz codebase, i generował nam jakieś tam testy integracyjne. Czasami jakość tych testów nie jest idealna i to też w inżynierii oprogramowania jest tak, że jeśli mamy na przykład duże pokrycie testami kodu, to też zawsze warto zadać sobie pytanie o jakość tych testów.
Nie jest to zawsze takie jeden do jeden, że to znaczy, że mam świetne, oprogramowanie, bo duże jest pokrycie testów i tak dalej. Więc tutaj w tym przypadku też ta wiedza związana jak pisać testy, co testować tak naprawdę w tej integracji, bo na przykład nie wiem, jeżeli będziemy testować, że nasz moduł tworzy jakiś plik i że go faktycznie stworzył, to jeszcze nie jest wszystko, ale jeżeli będziemy testować, co w tym pliku jest i czy faktycznie ten plik, znak w znak zgadza się z tym, co od niego wymagamy, żeby było w tym pliku, to wtedy to jest zupełnie inaczej.
Więc to też na tym etapie samego tworzenia oprogramowania to jest jedno, ale później już przy testowaniu, przy pisaniu testów to jest drugie. I tak naprawdę okazuje się, że te wszystkie techniki, które kiedyś były jeszcze przed erą AI wykorzystywane w inżynierii programowania, teraz mogą mieć nawet większe znaczenie, bo okazuje się, że można powiedzieć, że mamy tutaj zatrudnionego takiego agenta, który siedzi koło nas, tworzy nam to oprogramowanie. My tak jakby z nim trochę współpracujemy, przeglądamy ten kod, ale nie zawsze go rozumiemy i klikamy „akceptuj”, bo gonią nas terminy.
Później oczywiście w tym całym procesie wytwarzania oprogramowania to przechodzimy przez te kolejne etapy. Jakieś mamy tutaj flow, że robimy merge z feature branchy do developa. Później jakieś jest CICD, który wyrzuca to na, na środowisko testowe, odpala tę całą aplikację i tak dalej.
Dopiero na samym końcu gdzieś tam ten release wychodzi. I tutaj warto wspomnieć, że jak się popatrzy nawet na stricte na GitHuba i wyszuka się w git.ignore ile jest takich folderów .cursor, czyli folderu stricte, który jest, widać, że ktoś korzysta już z tego Cursora w projekcie, czy w ogóle w jakichś innych miejscach, gdzie ten folder się znajduje w jakichś innych plikach, to już jest około stu tysięcy takich plików. Czyli okazuje się, że faktycznie bardzo spora część już kontrybucji nawet na samego GitHuba jest już wykorzystana, ten kod już jest gdzieś tam przeglądany przez narzędzia agentowe, takie zintegrowane z IDE, które, które sprawiają, że po prostu wytwarzanie tego oprogramowania jest już przy wsparciu AI.
Tu warto też wspomnieć o jednej problematycznej rzeczy, która, która sprawia, że to też tak nie do końca jest. Oczywiście o prywatności danych. Prywatność danych w tym przypadku, ten model przegląda kod, jakoś go indeksuje i wykorzystuje ten kod później jako kontekst, czyli przerzuca to do chmury, tak żeby później ten model na tej chmurze odpalić, tak i żeby ta odpowiedź nam wróciła do tego naszego narzędzia.
To jest jedno z takich z dużych minusów, które na przykład w niektórych organizacjach, to właściwie wyklucza to, że nie możemy korzystać z Cursora, bo jednak ten, ten wyciek kodu do innej organizacji może być. Oczywiście tutaj są wewnętrzne takie polityki, bo na przykład ten kod i tak jest na githubie. Czasami organizacje mają tego Enterprise Githuba u siebie postawionego, więc to też zależy od poziomu, ale czasami jest tak, że ten kod mimo wszystko już i tak jest gdzieś tam w cloudzie.
Czy wykorzystujemy na przykład jakieś inne, jakieś slacki, nie slacki, wrzucamy gdzieś ten kod, więc to też można powiedzieć, ta prywatność danych jest problemem na ten moment, bo nie jesteśmy w stanie lokalnie postawić sobie takiego modelu?

Znaczy, możemy mniejszy.

Albo mniejszy, ale to oczywiście jest zupełnie inny poziom jakości. Właściwie brak jakości, tak to bym powiedział. I tak może tam jakieś proste generatywne teksty nam generować, ale na pewno nie jakość kodu.

Jeszcze zainteresowało mnie to, co mówiłeś też właśnie o testach integracyjnych, bo to wymaga od modelu, żeby wiedział w ogóle, jakie systemy są wykorzystywane przez daną aplikację, jakie są połączenia między modułami. Być może nasza aplikacja korzysta z jakiejś bazy danych, tak, może korzysta z jakiegoś systemu kolejkowego, jakichś zewnętrznych systemów i wydaje się, że czasem trudno przekazać w tym kontekście, tak, albo może stanowić za dużą ilość informacji. Z twojego doświadczenia właśnie te połączenia takie zewnętrzne naszego kodu z różnymi innymi systemami są problemem, czy już tam współcześnie nie korzystając właśnie z tych narzędzi najnowszych modeli?

Tak, to jest jeszcze problematyczne stosunkowo, bo faktycznie, mamy taki interfejs jakichś endpointów na przykład, czyli jakąś aplikację mobilną, webową, która, która, która gdzieś tam z naszym backendem się łączy. Oczywiście ten model nie tak do końca sobie radzi dobrze z tym, co te endpointy przyjmują, co zwracają. I tutaj jest kilka, można powiedzieć, delikatnie pomysłów: albo zarządzanie odpowiednio tym kontekstem, czyli faktycznie wrzucamy mu jakoś tam napisaną dokumentację do tych endpointów i on to zaczyna po prostu lepiej rozumieć, albo nawet na poziomie samego codebase’u stosunkowo okej sobie radzi, czyli jeśli widzi na przykład, że wykorzystujemy sobie jakiś Django, jakiś Rest framework, który jest w tym Django zaimplementowany, to faktycznie w tej technologii akurat sobie stosunkowo dobrze, dobrze radzi, wymyślając sobie na przykład jakieś testy integracyjne pod te konkretne modele, czy takie serializery, które mamy napisane w tym Django Rest.
Więc, ale to jest takie bardzo specyficzne, bo jednak Django jest bardzo popularnym frameworkiem takim webowym, w Pythonie, właściwie chyba najpopularniejszym, Flask jest też takim popularnym, ale to mniej popularnym jak Django, więc tutaj pewnie to jest jednak mocno związane z tą technologią. Dlatego też to umiejętne zarządzanie faktycznie kontekstem jest tutaj kluczowe, żeby właśnie odpowiednio te endpointy on rozumiał, co przyjmują, co zwracają, tak żeby, żeby jakieś testy integracyjne tych endpointów pisać.

To jeszcze może porozmawiajmy o takim kontekście, jak w ogóle wdrożyć w organizacji właśnie taką pracę nad kodem wspieraną przez modele, tak? Czy, czy uważasz, że to jest możliwe na takim poziomie, że każdy robi, jak uważa i jeden korzysta, drugi nie korzysta, czy to bardziej takie powinno być wdrożenie zespołowe, że jak już ustalamy, że w zespole korzystamy, to mamy jakąś wspólną politykę, czy jakiś wspólny sposób zarządzania tą pracą? Krótko mówiąc, czy można podejść do tego tak, jak gdyby po partyzancku, czy tutaj są potrzebne jakieś polityki i zasady współpracy właśnie w zespole, jeśli korzystamy z modeli AI, tak?

Tak, tutaj jest kilka, poziomów. Na pewno pierwsza rzecz, która jest ciekawa to, znaczy też problematyczna to, że te modele trochę nie pamiętają, co generowały wcześniej. Czyli nie tak idealnie sobie z tym radzą, więc cały czas gdzieś ten codebase muszą przeglądać.
Za każdym razem, jak na kursorze widzę, ile tokenów one zużywają z każdym uderzeniem to widać, że one przeglądają ten kod za każdym razem. Więc to jest na pewno problematyczne, jeśli chodzi o zespół, że trochę tracimy tę historię. Ten Cursor tam tak naprawdę oczywiście na jakimś systemie kontroli wersji typu git i tak dalej, trochę tam widzimy to, co model wygenerował. Możemy to zaakceptować, odrzucić i możemy tak naprawdę to później zacommitować, wysłać to na GitHuba czy na jakieś inne, inne repozytorium. To, co jest interesujące to, że możemy tworzyć takie wspólne biblioteki promptów, czyli na przykład jeżeli mamy jakiś sposób kodowania, na przykład tworzymy oprogramowanie, takim starszym, znaczy kiedyś to się pojawiło, szczególnie w kontekście aplikacji webowych, czyli TDD, Test Driven Development, to możemy sobie przygotować specjalne rule do naszego Cursora, żeby on właśnie w takim stylu nam tworzył to oprogramowanie. Czyli pierw pisał testy, dopiero później, żebyśmy przygotowywali tak naprawdę tę funkcjonalność.
Można sobie zbudować takie biblioteki promptów, czy w ogóle takie zasady jak współpracować z tym AI, tak żeby faktycznie było to w standardzie. Kolejna rzecz, to zarządzanie tym kontekstem. Jeżeli korzystamy z jakiegoś stacku technologicznego, czyli właśnie Context 7 na przykład, to można z tego Context 7 wyciągnąć jakąś taką dokumentację i dołączyć do naszego edytora, tak żeby po prostu to było wykorzystywane.
Ja też jestem takim programistą jeszcze sprzed tego Gen AI, gdzie bardzo mocno oczywiście pracowaliśmy z takimi rzeczami jak odpowiednie zarządzanie zadaniami, tworzenie kryteriów akceptacji, później review, pull requesty, cały git workflow, czy git flow, odpowiednie wersjonowanie oprogramowania, continuous integration też dodatkowe. Teraz jest też to continuous delivery, więc mamy tak naprawdę później możliwość reagowania szybko, rollbackując na przykład jakiś błąd, który wyszedł na produkcję, ale też w takich zespołach zazwyczaj już o o stabilnej strukturze, czyli nie jest to startup, który po prostu cały czas musi gdzieś te funkcjonalności wytwarzać, można powiedzieć ten Scrum to tak naprawdę nie jest Scrum, tylko jest taki waterfall, gdzie po prostu cały czas dużo się dzieje i wrzucamy po prostu jak najszybciej, bo po prostu czas się liczy, to jeśli mamy taką stabilną strukturę, że faktycznie planujemy sobie to i tak dalej, to mamy trochę większą kontrolę nad tym, co wychodzi. I to może nie musimy generować tak dużo kodu jak na przykład w tym startupie, więc to też pewnie zależy od tego, jaki to jest zespół, czy jest to startup, gdzie musimy tworzyć szybko ten MVP i trochę nie dbamy o jakość kodu, trochę nie robimy testów i to też w pewnym sensie jest OKna takim etapie versus jakiś stabilny zespół, gdzie mamy już działające oprogramowanie, gdzie mamy też jakiś duży codebase.
To, co jest interesujące to, że taki AI faktycznie z dużym codebase sobie stosunkowo będzie słabiej radził, bo będzie musiał przeglądać trochę większy kontekst. Można powiedzieć, że ma takie same zdolności jak programista, że nam też jest trudniej po prostu w większy codebase zaglądać, ale tu też jest rozwiązanie, na przykład w Cursorze możemy sobie wybierać moduły, z jakich on ma korzystać, czyli tu wiedza domenowa nasza o projekcie się przydaje w tym przypadku, że mówimy, tutaj jest na przykład system rejestracji i logowania użytkowników, chcę tylko z niego korzystać, żeby napisać jakąś tę funkcjonalność typu wysyłanie jakichś push notyfikacji czy coś takiego.

To co mówiłeś tak, że właśnie czy to jest startup, czy to jest jakiś tam zespół, złożony z doświadczonych programistów, którzy chcą budować coś stabilnego, to jest chyba to, o czym mówiliśmy na początku, czyli znowu powrót do tej definicji czym jest vibe coding, czy myślimy o tym jako czymś do zrobienia czegoś szybkiego, być może nawet nie znając się na programowaniu, tylko poprosić model i wygenerować i się nie przejmować co tam siedzi w środku, czy próbujemy użyć tych modeli do wspomagania naszej pracy jako programisty i to mi się wydaje, że to są dwa zupełnie różne nurty, nawet być może te narzędzia się różnią, bo myślę, że taka osoba, która się nie zna na programowaniu, to nawet nie włączy Cursora, nie będzie wiedziała,co tam się dzieje, tylko właśnie użyje takich generatorów, gdzie się tam promptuje, więc to są chyba niezależne ścieżki, natomiast tutaj wracając do programistów, to jak z twojego oglądu sytuacji, jak ty widzisz w ogóle nastawienie do modeli, do sztucznej inteligencji, czy programiści są raczej przychylni, czy raczej właśnie odrzucają jako coś, co jest potencjalnie tylko przeszkadzajką w pracy?

Tutaj warto wspomnieć o takiej ankiecie, która jest stworzona na potrzeby właśnie weryfikacji różnej popularności technologii, ale nie tylko i teraz też w tej ankiecie ze Stack Overflow pojawiły się testy związane z adaptacją AI, takich opinii korzyści, i takie ogólne nastawienie jest takie, że w tej ankiecie aż 76% deweloperów używa lub planuje używać narzędzia AI w swoim workflow, czyli w pracy faktycznie. Jest to delikatny wzrost w stosunku do poprzedniego roku i też miało to, 72% miało pozytywny stosunek do AI, ale jest to na przykład już spadek z 77%, więc takie główne korzyści, to tutaj programiści twierdzą, że jest to zwiększona produktywność. To pewnie niekoniecznie chodzi o generowanie kodu, to też są jakieś pewnie opisywanie commitów, tak jak powiedziałem, można tego copilota dołączyć jako takiego reviewera pull requestów i okazuje się, że on może naprawdę dosyć trafnie niektóre jakieś problemy znajdywać, które potencjalnie ktoś by mógł przeoczyć i też to automatyzuje pracę, bo później mamy dwóch reviewerów, jeden taki AI, drugi programista. Czy na przykład generowanie jakichś podsumowań zadań, czy jakichś changelogów, czy w ogóle widzę bardzo popularne generowanie readme, jak postawić aplikacje, to są takie rzeczy, nad którymi nie musimy spędzać i tracić czasu, więc ta automatyzacja się pojawia, czy też pisanie jakichś testów właśnie jednostkowych, to szczególnie, ale też integracyjnych, jak już wspomnieliśmy. To są faktycznie takie rzeczy, które są tą korzyścią. Tutaj też przy okazji w tej ankiecie pojawiły się takie kluczowe rzeczy, jak na przykład przyspieszenie uczenia nowych technologii, poprawa właśnie tej produktywności, ale też mamy obawy, więc na przykład, czyli aż 35% profesjonalistów uważa, że AI ma problemy z radzeniem sobie ze złożonymi zadaniami i to faktycznie się pojawia.
Czyli jeśli mamy jakiś bardzo specyficzny problem, który bazuje na jakimś module, który właśnie nie jest jakimś prostym widokiem, czy prostym kontrolerem, czy jakimś modelem, tylko coś bardziej to jest złożone, to faktycznie tutaj już AI stosunkowo sobie z tym gorzej radzi, albo w ogóle nie radzi. Też mamy niestety brak zaufania i to jest akurat dobre. Wydaje mi się, że to, że ludzie nie ufają temu, dokładności tych wyników AI jest rzeczą tutaj kluczową, bo można przyjąć takie porównanie, że to jest taki kalkulator i żeby go używać, to trzeba się znać na matematyce, ale ten kalkulator niestety czasami daje wyniki, można powiedzieć statystycznie najbardziej prawdopodobne, a to nie zawsze jest prawda.
Więc to też jest coś, co potrzeba weryfikacji, co jest też taką mam szansą dla IT, dla programistów, że nie zastąpi to w pełni tej pracy. Na pewno zautomatyzuje wiele rzeczy powtarzalnych, tak jak mówiłem, pisanie changelogów, opisywanie commitów, czy nawet takie review, czy przeglądanie w ogóle całego Codebase’u i wyszukiwanie jakichś problematycznych miejsc, to te modele sobie stosunkowo dobrze z tym radzą i nie musimy liniowo przeglądać każdego pliku i spędzać na to czasu, tylko faktycznie mamy taką semantyczną wyszukiwarkę, która nam przegląda cały CodeBase i wyszukuje jakieś takie momenty, gdzie jest coś do poprawy. Niestety tutaj też pojawiają się takie problemy z generowaniem tego kodu, że nie zawsze ten kod jest możliwie jak najlepiej optymalnie napisany, czyli mogą to być takie redundantne fragmenty, coś się nam powtarza, moglibyśmy to zawrzeć w jednej funkcji, a nie po prostu w kilku krokach, albo też jakieś takie nie optymalności, które można byłoby troszkę lepiej napisać. Czyli można powiedzieć, że mimo wszystko dochodzimy do pewnego poziomu programisty, bym tak to powiedział, takiego MIDa, ale to już to nie jest taki Senior, który jest w stanie popatrzeć na kod i powiedzieć nie, to jest nieefektywne, to działa wolno, jestem w stanie to zrobić lepiej, bo na przykład znam jakąś tam technikę w tym frameworku, jakąś bardzo ważną, która jest w stanie poprawić efektywność tego kodu.

Czyli tak patrząc na programistów jako właśnie osoby, które obecnie się stykają właśnie z tymi modelami sztucznej inteligencji, to myślisz, że jakie mogą być postawy wobec tej zmieniającej się rzeczywistości, że jest to coś, co odrzucam, bo denerwują mnie nowinki, może to być coś, co wspiera moją pracę, a może też jeśli lubię nowinki, to z kolei jest coś takiego na nowo angażującego, że widzę w tym jakąś nową radość i nową ścieżkę do sprawdzania rzeczy, których wcześniej nie mogłem robić, a teraz mogę. Czyli myślisz, że to też mogą być jakieś takie właśnie kierunki, które spowodują, że osoby, które się do tej pory zajmowały programowaniem, ale utknęły w jakimś tam punkcie, dadzą nowe bodźce do tego, żeby spróbować czegoś nowego.

Tak, przede wszystkim wydaje mi się, że takie kompetencje, które są związane na przykład z wytwarzaniem i w ogóle, weryfikacją tego, co ten model generuje, będą miały większe znaczenie, czyli pisanie dobrego czystego kodu, pisanie dobrych testów, czy w ogóle myślenie o architekturze aplikacji, czy znanie właśnie bardziej takich rozwiązań związanych w ogóle z bezpieczeństwem, czy to tworzenie oprogramowania z użyciem AI faktycznie sprawdza się, jeżeli mamy bardzo powtarzalne rzeczy. Potrzebujemy w analizie danych nawet zrobić jakieś wykres i jesteśmy w stanie, może poszukać dokumentacji, jak taki wykres się robi i tak dalej, ale możemy sobie wykorzystać takie narzędzie do tego, żeby ten wykres zrobić po prostu 50 razy szybciej.
Nie musimy wyszukiwać dokumentacji, jakie parametry, ta metoda, w jakiej i tak dalej, więc to można powiedzieć, że to jest takie hybrydowe, że z jednej strony możemy podnosić te kwalifikacje, na przykład takie AI jest bardzo dobre w tak zwanym competitive programingu, czyli takim, gdzie rozwiązujemy jakieś takie zagadki programistyczne. to tutaj sobie w tym bardzo świetnie radzi, więc te kompetencje na przykład algorytmiczne, czy nawet takiego krytycznego myślenia jest w stanie faktycznie to AI troszkę podnosić, ale na przykład w tym, że mamy jakąś bardzo dużą aplikację, wiele zależności i tak dalej, to tutaj już nie jesteśmy w stanie tego wykorzystać i czasami nawet błąd, który byśmy po prostu jako doświadczeni programiści potrafili załatać w kilkanaście sekund, dla niego to jest za dużo, bo przegląda ten codebase, zaczyna się mylić, a w sumie nie wie, z czego to może wynikać i tak dalej, więc są takie, można powiedzieć pewne ograniczenia i pewne szanse, które stoją za wykorzystaniem tej technologii.
Ja patrząc na to, jak współpracuję z kursantami, jak prowadzę kursy właśnie z różnych technologii, z bardziej zaawansowanych i z takich podstawowych, to zauważam, że faktycznie ludzie korzystają z tego, ja im tego nie zabraniam. Uważam, że takie rozsądne korzystanie z tych narzędzi może pomóc też, właśnie generuje ten kod, nie wiem, jeśli ktoś ma wygenerować sobie wykres, to nie musi go jakoś tam bardzo znać, jak wygenerować ten wykres, ale jeżeli ma napisać jakąś tam pętlę i zrozumieć, co w niej się dzieje, to faktycznie fajnie, żeby znał te podstawy tego języka. Czyli są takie podstawowe rzeczy, które są kluczowe, żeby właśnie ktoś był w stanie tym zarządzać, to obsługiwać.

Czy widzisz to jako szansę, natomiast zagrożenia też są bardzo istotne, o których mówiliśmy. Jak to obecnie oceniasz jeszcze od strony właśnie takich osób, które w przyszłości będą zajmować się programowaniem? Bo mówiliśmy o tym, że coraz ważniejszy jest ten kontekst ogólny, architektura, czyli tak naprawdę to, co trzeba wiedzieć, to mieć szerokie spojrzenie na te wszystkie aspekty, łącznie z aspektami właśnie architektonicznymi, bezpieczeństwa i integracji z różnymi systemami.

Więc tak naprawdę chyba wiedzowo sytuacja się nie upraszcza, tylko jedynie, co się upraszcza, to tempo pracy bieżącej, że można automatyzować jakieś pojedyncze zadania.

Tak. I można powiedzieć, że tak, teraz się obserwuje taką tendencję, że właśnie takie powtarzalne rzeczy, takie sklejanie kodu ze Stack Overflow, jak ja to kiedyś nazywałem, czyli że właśnie ktoś wchodził na ten Stack Overflow, wyszukiwał pojedynczo ten kod, kopiował go i jakoś tam modyfikował. Już teraz to nie jest nam potrzebne, bo faktycznie to AI jest w stanie faktycznie ten sam kod wygenerować, można powiedzieć, i też jakoś go zmodyfikować jeszcze odpowiednio pod nasze wymagania.
Ale to, co widzę jako szansę, to tę naukę technologii, że trochę mniej będziemy się frustrować w przypadku tego, że coś nam nie działa, a to pamiętam na tych kursach, na samym początku jeszcze bez AI było takim dużym blokerem dla osób, które zaczynały. Teraz mam wrażenie, że po prostu te moje kursy są takie przyjemniejsze i że ludzie po prostu przychodzą i mają zawsze takie, a mam obok siebie AI, to on mi podpowie, co nie działa i będę w stanie to załatać. Oczywiście to do pewnego momentu działa, bo im bardziej zaawansowane rzeczy generujemy, to mamy większą szansę, że jest z nich błąd. i te błędy już później tak łatwo się tym AI nie da rozwiązać, więc coraz bardziej nam potrzebna jest już taka właśnie wiedza domenowa, ale na przykład wiemy, jak jest zorganizowany system plików Django i gdzie zaglądnąć i tak dalej, co dany plik robi. Jeśli się na tym nie znamy, to faktycznie jest to trudniejsze. Ale też to AI nam pomaga trochę debugować niektóre rzeczy nawet, ale jest też taka pułapka, że im więcej generujemy z użyciem AI, to mamy mniejszą kontrolę nad jakością kodu, ale też w ogóle nad tym, co się w tym kodzie dzieje i coraz bardziej potrzebujemy, tak bym to powiedział, pisać testy do tego, żeby być w pełni przekonanym, że to, co wchodzi z tego naszego programu, faktycznie jest tym, co oczekujemy. Więc takie kompetencje programistyczne, które nawet nie są związane stricte z pisaniem kodu, jak system kontroli wersji, jak flow na przykład przy wytwarzaniu kolejnych funkcjonalności czy łataniu jakichś błędów jest tutaj kluczowe, żeby mieć większą kontrolę nad tym, jak wychodzi ten kod spod naszej ręki, czy właściwie ręki AI, tak, ale zarządzaną w jakiś sposób też przez nas.

Czyli podsumowując to, wiedza, jaką mamy jako programiści, architekci, wiedza inżynierska nadal jest potrzebna i wydaje się, że jeszcze będzie. Dobrze, to dzięki wielkie w takim razie za to spojrzenie na to, co się dzieje właśnie w sferze wykorzystania sztucznej inteligencji do programowania. Pewnie to się tak szybko zmienia, że za jakiś czas będziemy musieli się spotkać i jeszcze powiedzieć co nowego, ale myślę, że na razie mamy ten stan bieżący.

Także dzięki, do usłyszenia, do zobaczenia.