Kurs AI_devs 4 Builders (2026)

Back-end pisany w Python. Front-end pisany w Angular, TypeScript.

Kod w całości generowany przez AI. Przygotowywałem odpowiednie reguły do kursu, prompty dla każdego zadania i komunikowałem się z modelami AI, by te zadania rozwiązać i zwizualizować rozwiązania.

s01e01

Zadanie polegało na pobraniu zewnętrznego zbioru danych zawierającego listę osób współpracujących z systemem, a następnie przeanalizowaniu rekordów w celu wytypowania kandydatów spełniających określone kryteria demograficzne i zawodowe. Dane zostały przefiltrowane pod kątem płci, wieku wyliczonego na podstawie roku urodzenia oraz miejsca pochodzenia, a następnie opisy stanowisk pracy zostały sklasyfikowane przy użyciu modelu językowego poprzez przypisanie im zestawu zdefiniowanych kategorii zawodowych. Kluczowym elementem zadania było wykorzystanie mechanizmu strukturalnej odpowiedzi modelu (Structured Output), aby wymusić poprawny format JSON podczas tagowania zawodów. Po przypisaniu tagów wybrano wyłącznie osoby związane z branżą transportową i przygotowano wynikową listę rekordów w wymaganym schemacie danych, którą następnie przesłano do systemu weryfikacyjnego.

s01e02

Zadanie polegało na zidentyfikowaniu jednej z wcześniej wytypowanych osób podejrzanych, która przebywała w pobliżu elektrowni atomowej, oraz ustaleniu jej poziomu dostępu i kodu powiązanej elektrowni. W tym celu dla każdej osoby z poprzedniego etapu pobrano historię lokalizacji z dedykowanego API, a następnie porównano otrzymane współrzędne z listą elektrowni i ich pozycji geograficznych, wyznaczając rzeczywistą bliskość na podstawie obliczeń odległości. Po wskazaniu najlepszego kandydata pobrano z drugiego endpointu jego poziom dostępu, korzystając także z danych identyfikacyjnych zachowanych z wcześniejszego zadania. Kluczowym wyzwaniem było połączenie wyników z kilku źródeł, poprawne dopasowanie danych wejściowych między etapami oraz przygotowanie końcowego raportu w ściśle wymaganym formacie JSON do systemu weryfikacyjnego.

s01e03

Zadanie polegało na zbudowaniu i publicznym udostępnieniu endpointu HTTP działającego jako konwersacyjny asystent pośredniczący między operatorem a zewnętrznym API paczek. Rozwiązanie musiało obsługiwać wiele niezależnych sesji, zapamiętywać kontekst rozmowy dla każdego sessionID oraz odpowiadać w naturalny sposób na kolejne wiadomości użytkownika. Kluczowym elementem było połączenie modelu językowego z mechanizmem wywoływania narzędzi, dzięki czemu asystent potrafił samodzielnie sprawdzać status przesyłek i wykonywać operacje przekierowania na podstawie danych podawanych w rozmowie. Istotnym wyzwaniem było poprawne zarządzanie historią konwersacji, niezawodna obsługa zewnętrznego API, zabezpieczenie pętli wywołań narzędzi oraz przygotowanie stabilnego, publicznie dostępnego interfejsu gotowego do testów przez system weryfikacyjny.

s01e04

Zadanie polegało na przygotowaniu poprawnie wypełnionej deklaracji transportowej zgodnej z wymaganiami Systemu Przesyłek Konduktorskich oraz przesłaniu jej w ściśle określonym formacie do systemu weryfikacyjnego. Należało przeanalizować pełną dokumentację, w tym powiązane pliki tekstowe i graficzne, aby odnaleźć właściwy wzór formularza, ustalić poprawny kod trasy między wskazanymi punktami, dobrać kategorię przesyłki zgodną z regulaminem oraz tak wypełnić dane, by transport został zakwalifikowany jako bezpłatny lub finansowany przez system. Kluczowym wyzwaniem było jednoczesne zachowanie zgodności formalnej dokumentu, poprawne odwzorowanie wszystkich wymaganych pól, uwzględnienie ograniczeń budżetowych i logistycznych oraz utrzymanie dokładnego formatowania deklaracji, ponieważ sprawdzana była nie tylko treść, ale również struktura całego dokumentu.

s01e05

Zadanie polegało na aktywowaniu wskazanej trasy kolejowej poprzez słabo udokumentowane API, którego zasady działania należało najpierw samodzielnie pozyskać z wbudowanej akcji zwracającej dokumentację. Następnie, zgodnie z uzyskanymi instrukcjami, trzeba było przeprowadzić właściwą sekwencję wywołań prowadzących do aktywacji trasy, bez zgadywania nazw operacji ani parametrów. Kluczowym wyzwaniem była odporność rozwiązania na celowo generowane błędy przeciążenia, konieczność stosowania automatycznych ponowień z kontrolowanym opóźnieniem oraz ścisłe pilnowanie limitów zapytań na podstawie nagłówków odpowiedzi. Istotna była także precyzyjna analiza komunikatów zwracanych przez API i takie prowadzenie całego procesu, aby przy minimalnej liczbie wywołań doprowadzić do uzyskania końcowego potwierdzenia wykonania zadania.

s02e01

Zadanie polegało na zaprojektowaniu wyjątkowo krótkiego promptu klasyfikującego, który mieścił się w bardzo małym limicie kontekstowym archaicznego modelu językowego, a jednocześnie poprawnie rozróżniał towary niebezpieczne i neutralne. Rozwiązanie wymagało pobierania aktualnej listy produktów z pliku CSV, przesyłania osobnego zapytania dla każdego rekordu oraz takiego sformułowania instrukcji, aby model zwracał wyłącznie jeden z dwóch dozwolonych wyników. Kluczowym wyzwaniem było pogodzenie skuteczności klasyfikacji z rygorystycznym limitem tokenów i budżetem kosztowym, a także uwzględnienie wyjątków dla określonej grupy przedmiotów, które mimo potencjalnie niebezpiecznego opisu musiały zostać oznaczone jako neutralne. Istotna była również iteracyjna optymalizacja promptu na podstawie odpowiedzi systemu, tak aby zminimalizować liczbę prób i doprowadzić do poprawnej klasyfikacji całego zestawu danych.

s02e02

Zadanie polegało na rozwiązaniu logicznej układanki przedstawionej jako plansza 3×3 z elementami sieci elektrycznej, w której należało doprowadzić zasilanie ze źródła awaryjnego do trzech wskazanych elektrowni poprzez odpowiednie obracanie pól z kablami. Kluczowym etapem było odczytanie aktualnego układu planszy z obrazu, porównanie go ze schematem docelowym oraz ustalenie, które elementy różniły się orientacją i ile obrotów wymagało każde z nich. Ponieważ każda pojedyncza rotacja była osobnym wywołaniem API, rozwiązanie musiało minimalizować liczbę operacji i uwzględniać dokładną mechanikę obrotów o 90 stopni w prawo. Istotnym wyzwaniem było także przekształcenie informacji wizualnej w postać nadającą się do analizy, zweryfikowanie poprawności kolejnych ruchów oraz doprowadzenie planszy do konfiguracji zgodnej z wymaganym układem połączeń.

s02e03

Zadanie polegało na przeanalizowaniu bardzo dużego pliku logów systemowych z dnia awarii i przygotowaniu jego skondensowanej wersji zawierającej wyłącznie wpisy istotne dla diagnozy problemu. Należało odfiltrować zdarzenia związane z kluczowymi obszarami działania elektrowni, takimi jak zasilanie, chłodzenie, pompy, sterowanie i oprogramowanie, a następnie skrócić lub sparafrazować je w taki sposób, by zachować znaczniki czasu, poziomy ważności i identyfikatory podzespołów przy jednoczesnym zmieszczeniu całości w ścisłym limicie tokenów. Kluczowym wyzwaniem było dobranie takiego zestawu wpisów, który mimo silnej kompresji nadal pozwalał technikom odtworzyć przebieg awarii i wskazać jej przyczynę.

s02e04

Zadanie polegało na przeszukaniu aktywnej skrzynki mailowej poprzez dedykowane API w celu odnalezienia trzech kluczowych informacji ukrytych w korespondencji: daty planowanego działania, hasła oraz kodu potwierdzenia w określonym formacie. Wymagało to wykorzystania mechanizmu wyszukiwania wiadomości z użyciem operatorów logicznych, iteracyjnego pobierania wyników oraz dwuetapowego dostępu do danych — najpierw listy maili, a następnie pełnej treści wybranych wiadomości. Kluczowym wyzwaniem było skuteczne zawężanie zapytań, analiza zawartości maili w zmieniającym się środowisku (napływ nowych wiadomości) oraz stopniowe kompletowanie brakujących informacji na podstawie odpowiedzi systemu weryfikacyjnego.

s02e05

Zadanie polegało na zaprogramowaniu drona poprzez odpowiednią sekwencję instrukcji tak, aby formalnie realizował misję ataku na wskazany obiekt, lecz faktycznie skierował ładunek w inne, strategiczne miejsce na mapie. Wymagało to analizy obrazu przedstawiającego podzielony na sektory teren, identyfikacji właściwej lokalizacji celu na podstawie cech wizualnych oraz przełożenia tej informacji na współrzędne zgodne z systemem sterowania drona. Następnie należało zapoznać się z niejednoznaczną dokumentacją API, dobrać minimalny zestaw poprawnych komend i iteracyjnie dostosowywać je na podstawie komunikatów błędów zwracanych przez system. Kluczowym wyzwaniem było precyzyjne powiązanie danych wizualnych z logiką sterowania oraz uzyskanie poprawnej sekwencji instrukcji prowadzącej do osiągnięcia zamierzonego efektu.

s03e01

Zadanie polegało na przeanalizowaniu dużego zbioru plików z odczytami sensorów i wskazaniu tych rekordów, które zawierały anomalie w danych pomiarowych lub niespójności między odczytem a notatką operatora. Należało sprawdzić, czy aktywne sensory zwracały wyłącznie właściwe dla siebie typy pomiarów, czy wartości mieściły się w dopuszczalnych zakresach oraz czy komentarz operatora poprawnie opisywał rzeczywisty stan danych. Kluczowym wyzwaniem było rozdzielenie części problemu, którą można było rozwiązać deterministycznie w kodzie, od tej wymagającej analizy językowej treści notatek, a także zoptymalizowanie całego procesu pod kątem kosztu i skali, ponieważ do weryfikacji było bardzo wiele plików, a liczne wpisy miały powtarzalny charakter.

s03e02

Zadanie polegało na uruchomieniu binarnego programu sterownika w ograniczonym środowisku linuksowym udostępnionym przez zdalne API powłoki oraz doprowadzeniu go do poprawnego działania mimo błędnej konfiguracji i ograniczonych uprawnień. Wymagało to najpierw rozpoznania dostępnych komend i zasad pracy w niestandardowym systemie, następnie odnalezienia wymaganych informacji uwierzytelniających zapisanych w dozwolonych obszarach systemu oraz przeanalizowania i poprawienia konfiguracji aplikacji w zapisywalnym wolumenie. Kluczowym wyzwaniem było ostrożne poruszanie się po środowisku z zachowaniem narzuconych reguł bezpieczeństwa, unikanie niedozwolonych ścieżek i respektowanie ograniczeń systemu plików, a także iteracyjne diagnozowanie przyczyny, dla której program nie startował poprawnie, aż do uzyskania kodu potwierdzającego poprawne uruchomienie.

s03e03

Zadanie polegało na stworzeniu algorytmu sterującego robotem poruszającym się po dolnym poziomie reaktora w taki sposób, aby bezpiecznie doprowadzić go z pola startowego do punktu docelowego mimo ruchomych przeszkód zmieniających pozycję w czasie. Rozwiązanie musiało korzystać z prostego API przyjmującego pojedyncze komendy i po każdym ruchu analizować aktualny stan planszy, uwzględniając położenie oraz kierunek poruszania się bloków reaktora. Kluczowym wyzwaniem było podejmowanie decyzji w trybie reaktywnym — kiedy wykonać ruch do przodu, kiedy przeczekać zmianę układu, a kiedy wycofać się, aby uniknąć kolizji. Istotna była więc synchronizacja ruchów robota z cyklicznym ruchem przeszkód oraz ciągła adaptacja strategii na podstawie bieżącej sytuacji na mapie.

s03e04

Zadanie polegało na przygotowaniu jednego lub dwóch publicznie dostępnych narzędzi HTTP, z których zewnętrzny agent mógł korzystać do ustalenia, które miasta oferują jednocześnie wszystkie potrzebne przedmioty. Rozwiązanie wymagało najpierw przeanalizowania dostarczonych plików danych, a następnie zaprojektowania endpointów przyjmujących zapytania w języku naturalnym i zwracających krótkie, ściśle ograniczone odpowiedzi nadające się do dalszego wykorzystania przez automat. Kluczowym wyzwaniem było takie opisanie funkcji narzędzi, aby agent potrafił samodzielnie dobrać właściwy endpoint i poprawnie sformułować parametry, a także tak zorganizować wyszukiwanie informacji, by w ograniczonej liczbie kroków umożliwić wskazanie miast spełniających jednocześnie wszystkie warunki zakupowe.

s03e05

Zadanie polegało na zbudowaniu agenta, który samodzielnie pozyskiwał wiedzę o dostępnych narzędziach, zasadach poruszania się, typach terenu oraz parametrach pojazdów, a następnie na tej podstawie wyznaczał optymalną trasę do miasta docelowego. Rozwiązanie wymagało najpierw odnalezienia właściwych źródeł informacji przez wyszukiwarkę narzędzi, potem zebrania danych o mapie, kosztach ruchu i ograniczeniach zasobów, a na końcu zaplanowania sekwencji ruchów wraz z wyborem środka transportu tak, by zmieścić się w dostępnej ilości paliwa i prowiantu. Kluczowym wyzwaniem było pogodzenie sprzecznych czynników — szybszy przejazd zmniejszał zużycie jedzenia, ale zwiększał spalanie paliwa, podczas gdy wolniejsze przemieszczanie działało odwrotnie — dlatego agent musiał znaleźć trasę optymalną kosztowo, a nie tylko najkrótszą geometrycznie.

s04e01

Zadanie polegało na zdalnym wprowadzeniu określonych zmian w systemie operacyjnym OKO wyłącznie za pośrednictwem udostępnionego API, bez ręcznej ingerencji w panel operatora. Wymagało to najpierw rozpoznania dostępnych akcji i struktury interfejsu na podstawie odpowiedzi mechanizmu pomocy, a następnie odnalezienia właściwych obiektów w systemie i wykonania na nich precyzyjnych modyfikacji: zmiany klasyfikacji wskazanego raportu, aktualizacji treści i statusu odpowiedniego zadania oraz dodania nowego incydentu kierującego uwagę operatorów na inną lokalizację. Kluczowym wyzwaniem było poprawne odwzorowanie logiki działania zaplecza administracyjnego, zachowanie właściwej kolejności operacji oraz doprowadzenie systemu do stanu zgodnego z wymaganiami przed wysłaniem końcowego potwierdzenia wykonania zadania.

s04e02

Zadanie polegało na przygotowaniu harmonogramu pracy turbiny wiatrowej w taki sposób, aby w ograniczonym czasie poprawnie zabezpieczyć ją przed zbyt silnym wiatrem i jednocześnie wyznaczyć moment oraz parametry niezbędne do wygenerowania brakującej energii dla elektrowni. Wymagało to skorzystania z asynchronicznego API do pozyskania raportów o pogodzie, stanie turbiny i wymaganiach systemu, a następnie zsynchronizowania ich wyników mimo losowej kolejności odpowiedzi i ograniczenia czasowego. Kluczowym wyzwaniem było równoległe planowanie działań, poprawne podpisanie każdej konfiguracji kodem wygenerowanym przez dedykowaną funkcję, dobranie właściwego kąta łopat i trybu pracy dla różnych warunków oraz zapisanie kompletnej konfiguracji zakończonej testem technicznym i finalną walidacją całego ustawienia.

s04e03

Zadanie polegało na zaplanowaniu i przeprowadzeniu operacji poszukiwawczo-ratunkowej na siatce miasta przy ograniczonym budżecie punktów akcji, z wykorzystaniem transporterów i zwiadowców. Wymagało to analizy mapy terenu, optymalnego rozmieszczenia jednostek oraz połączenia szybkiego przemieszczania się pojazdami z dokładnym przeszukiwaniem kluczowych obszarów pieszo. Kluczowym wyzwaniem było zarządzanie kosztami akcji — wybór, gdzie użyć transportera, a gdzie zwiadowcy, kiedy przeprowadzić inspekcję pola oraz jak skrócić czas dotarcia do potencjalnych lokalizacji celu. Po odnalezieniu właściwego miejsca należało natychmiast przeprowadzić ewakuację, wskazując dokładną pozycję dla śmigłowca i kończąc operację w ramach dostępnych zasobów.

s04e04

Zadanie polegało na przeanalizowaniu nieuporządkowanych notatek i przekształceniu ich w logiczną strukturę wirtualnego systemu plików, odzwierciedlającą zależności między miastami, osobami odpowiedzialnymi za handel oraz oferowanymi towarami. Wymagało to wyodrębnienia z materiałów źródłowych nazw miast, przypisanych im potrzeb zakupowych, identyfikacji osób zarządzających handlem w poszczególnych lokalizacjach oraz ustalenia, które miasta wystawiały konkretne towary na sprzedaż. Kluczowym wyzwaniem było nie tylko poprawne odczytanie i ujednolicenie informacji z notatek, ale także zapisanie ich w ściśle wymaganej strukturze katalogów i plików, z zachowaniem odpowiedniego nazewnictwa, formatu JSON i linkowania między elementami systemu.

s04e05

Zadanie polegało na przygotowaniu poprawnych zamówień magazynowych dla wszystkich wskazanych miast na podstawie dostarczonego pliku z zapotrzebowaniem oraz danych pobranych z udostępnionego API i bazy SQLite działającej wyłącznie w trybie odczytu. Wymagało to najpierw ustalenia, które miasta uczestniczyły w operacji, jakie miały kody docelowe oraz jakie dokładnie towary i ilości należało dla nich zamówić, a następnie utworzenia osobnych zamówień z prawidłowymi danymi autoryzacyjnymi, w tym odpowiednim identyfikatorem twórcy i podpisem bezpieczeństwa wygenerowanym na podstawie danych z bazy. Kluczowym wyzwaniem było połączenie informacji z kilku źródeł, zachowanie pełnej zgodności ilościowej bez braków i nadmiarów oraz poprawne zbudowanie każdego zamówienia tak, aby końcowa weryfikacja zaakceptowała cały zestaw operacji.

s05e01

Zadanie polegało na przechwyceniu i przeanalizowaniu strumienia danych z nasłuchu radiowego, a następnie wyodrębnieniu kluczowych informacji o wskazanym mieście na podstawie niejednorodnych materiałów wejściowych. W trakcie pracy należało iteracyjnie pobierać kolejne komunikaty, rozróżniać ich typ (tekst, szum lub dane binarne), selekcjonować wartościowe fragmenty oraz decydować, które dane analizować programistycznie, a które przekazać do modelu językowego. Kluczowym wyzwaniem było efektywne zarządzanie dużą ilością danych, w tym dekodowanie i filtrowanie binarnych załączników bez generowania zbędnych kosztów, a następnie złożenie rozproszonych informacji w spójny raport zawierający nazwę miasta, jego powierzchnię, liczbę magazynów oraz dane kontaktowe.

s05e02

Zadanie polegało na przeprowadzeniu wieloetapowej rozmowy głosowej z operatorem systemu w taki sposób, aby uzyskać informację o przejezdności wskazanych dróg oraz doprowadzić do wyłączenia monitoringu na właściwej trasie, nie wzbudzając przy tym podejrzeń. Wymagało to utrzymania spójnej narracji, zachowania odpowiedniej kolejności wypowiedzi oraz przekazywania informacji w formie nagrań audio zakodowanych w Base64. Kluczowym wyzwaniem było precyzyjne prowadzenie dialogu zgodnie ze scenariuszem — od przedstawienia się, przez uzyskanie statusu dróg, aż po przekonanie operatora do wykonania konkretnej akcji — przy jednoczesnym dopasowaniu treści komunikatów do kontekstu rozmowy i reagowaniu na odpowiedzi rozmówcy.

s05e03

Zadanie polegało na eksploracji zdalnego serwera za pomocą poleceń powłoki w celu odnalezienia w archiwalnych logach informacji o dacie, miejscu i współrzędnych związanych z odnalezieniem Rafała. Należało przeszukać udostępniony katalog z danymi, zidentyfikować właściwe pliki i powiązać rozproszone informacje tak, aby ustalić, kiedy i gdzie doszło do zdarzenia, a następnie wyznaczyć poprawną datę pojawienia się o jeden dzień wcześniej. Kluczowym wyzwaniem było sprawne poruszanie się po strukturze plików, wykorzystanie standardowych narzędzi linuksowych do filtrowania i analizy danych oraz przygotowanie końcowego wyniku dokładnie w wymaganym formacie JSON, który system weryfikował automatycznie.

s05e04

Zadanie polegało na bezpiecznym przeprowadzeniu rakiety przez wąską trasę podzieloną na kolumny, przy jednoczesnym omijaniu skał i neutralizowaniu ukrytych pułapek radarowych systemu OKO. Wymagało to iteracyjnego sterowania lotem na podstawie niepewnych, radiowych wskazówek opisujących położenie przeszkody w kolejnej kolumnie oraz ciągłego sprawdzania, czy aktualna pozycja nie znajduje się w zasięgu aktywnego skanera. Kluczowym wyzwaniem była odporność rozwiązania na zakłócone komunikaty, uszkodzone odpowiedzi API i losowe błędy, ponieważ zarówno dane o przeszkodach, jak i informacje potrzebne do rozbrojenia radaru mogły być częściowo zniekształcone i wymagały ponawiania prób oraz ostrożnego parsowania. Cały algorytm musiał więc łączyć analizę wskazówek, kontrolę pozycji na planszy, dynamiczne podejmowanie decyzji o ruchu i poprawne obliczanie kodów neutralizujących pułapki przed każdym kolejnym krokiem.

s05e05

Zadanie polegało na przygotowaniu asystenta wspierającego obsługę maszyny czasu, który na podstawie dokumentacji i komunikacji z API pomagał poprawnie skonfigurować urządzenie do wykonania dwóch kolejnych skoków czasowych. Wymagało to wyliczania parametrów synchronizacji dla wskazanych dat, pobierania aktualnego stanu konfiguracji, dobierania właściwych ustawień stabilizacji oraz informowania operatora, które elementy należało ręcznie zmienić w interfejsie webowym, aby urządzenie mogło bezpiecznie przejść do kolejnych etapów podróży. Kluczowym wyzwaniem było skoordynowanie ustawień rozdzielonych między API i panel WWW, uwzględnienie ograniczeń energetycznych, dopasowanie trybu pracy urządzenia do docelowego roku oraz przeprowadzenie całej sekwencji w odpowiedniej kolejności, tak aby ostatecznie otworzyć tunel do wymaganej daty.