Twój zespół + AI.

Otwieramy szkolenie krótkim wprowadzeniem: pokazujemy, jak wygląda cały program, jaki projekt budujemy razem i czego się nauczysz po drodze. W pierwszej lekcji konfigurujemy środowisko developerskie - omawiamy różne warianty pracy z Claude Code, Codex, GitHub Copilot, VS Code i Cezar oraz pokazujemy, jak to wszystko działa w jednym Sandboxie od pierwszego dnia szkolenia. Wyjaśniamy, czym właściwie jest AI Engineering, i robimy szybkie wyrównanie wiedzy z tematów takich jak worktrees czy skille AI - w tym jak zainstalować potrzebne narzędzia i jak zacząć ich używać. Zakładamy repozytorium na GitHubie, w którym pracujemy przez cały kurs. Mówimy też, dlaczego w szkoleniu opieramy się na samym GitHubie (do zadań, PR-ów i kodu) zamiast na kombinacji GitHub + Linear czy Jira. Taki układ narzędzi też ma sens - jeśli w Twojej firmie z niego korzystacie, dostajesz wszystko, czego potrzebujesz, żeby skonfigurować środowisko także pod niego.

Sesja discovery & define: zaczynamy od uporządkowania wiedzy o produkcie - jaki problem rozwiązujemy, kto go doświadcza i jaką wartość chcemy dostarczyć. Przyglądamy się użytkownikom, interesariuszom, kontekstowi biznesowemu, regułom domenowym i kluczowym przepływom, a także rynkowi i istniejącym rozwiązaniom: co robią dobrze, jakich wzorców używają i gdzie jest miejsce, żeby się wyróżnić. AI pomaga nam uporządkować i sprawdzić wymagania - tworzymy przykładowe persony, rozmawiamy z nimi w symulowanych wywiadach i patrzymy na kluczowe funkcje produktu z perspektywy różnych użytkowników. Dzięki temu, zanim zaczniemy kodować, znajdujemy niejasności, sprzeczności, brakujące przypadki i ryzykowne założenia - zaznaczamy też, które kwestie warto potwierdzić w rozmowie z prawdziwymi użytkownikami.

‍

Następnie opisujemy produkt jednym zdaniem, ustalamy, po czym poznamy jego sukces, co wejdzie do MVP, co zostawiamy na później, a czego świadomie nie budujemy. Na koniec zamieniamy te ustalenia w uporządkowany backlog EPIC → STORY → TASK, z priorytetami i kryteriami akceptacji, gotowy do przeniesienia do GitHub Issues.

Czas zacząć budować. Podejmujemy decyzję o stacku technologicznym projektu i sprawdzamy, jakie elementy ze świata AI na nią wpływają. Definiujemy wstępną architekturę oraz wzorce projektowe, którymi agenty kierują się podczas kodowania. Budujemy szkielet projektu w repozytorium i powstają pierwsze pliki AGENTS.md (do porządku wracamy przy Context Engineeringu). Uruchamiamy też podstawowy safety-net w postaci testów i checków w GitHub CI - rozwijamy go razem z kolejnymi funkcjonalnościami i plikami kontekstu.

Mamy już repozytorium, zarys architektury i wybrane wzorce projektowe. W tej lekcji przeglądamy i modyfikujemy skille dla agentów AI, dopasowując je do naszego stacku i przyjętych wzorców. Pokazujemy, na co zwrócić uwagę przy tworzeniu nowych skilli dla własnego projektu oraz jak wykorzystać je do zwiększenia autonomii agentów - czyli o co chodzi w skillach "auto".

Mamy już pierwsze pliki AGENTS.md i skille - to podstawowe elementy naszego systemu sterowania kontekstem. W tej lekcji robimy z nich porządek, żeby złożyły się w jeden spójny mechanizm, który nazywamy Context Engineeringiem. Rozmawiamy o Task Driven Context Routing i o kluczowym wyzwaniu: jak w dużym projekcie nie przeciążyć kontekstu agenta, dać mu szybką drogę do potrzebnej wiedzy i utrzymać jakość tworzonego kodu.

W tej lekcji skupiamy się na tym, jak przekazać agentom AI, co i jak mają zakodować. Tworzymy dokumenty specyfikacji - pokazujemy, jak je najlepiej konsultować i na co zwrócić uwagę, żeby powstał kod zgodny z tym, czego oczekujemy. Piszemy specyfikacje dla funkcjonalności z naszego backlogu i poddajemy je krytycznej analizie przez AI.

Zaczynamy od rozpoznania generycznego AI look & feel i wypracowania własnego kierunku wizualnego. Przygotowujemy moodboard z referencjami, kolorami, typografią i kompozycją, które mają nadać produktowi charakter, a potem zamieniamy go w skill stylu: zestaw konkretnych zasad i przykładów "stosuj / unikaj", dzięki którym agent konsekwentnie projektuje kolejne ekrany bez wpadania w estetykę AI slopu.

‍

Efektem lekcji jest design system jako wspólne źródło prawdy o produkcie - łączy tokeny, komponenty, wzorce i przykłady implementacji z opisem logiki stojącej za decyzjami projektowymi. Określa, jak produkt organizuje informacje, prowadzi użytkownika i reaguje na jego działania, zachowując przy tym własny charakter. Dzięki temu developer albo agent AI wie nie tylko, czego użyć, ale też dlaczego i w jaki sposób - tak, żeby kolejne ekrany zostawały spójne, użyteczne i rozpoznawalne.

Prototypujemy z AI wygląd aplikacji, zanim powstanie kod: z briefu i backlogu generujemy klikalny prototyp i iterujemy go promptami. Walidujemy go syntetycznymi personami z sesji discovery & define - przechodzimy główne ścieżki ich oczami, a wychwycone tarcia wracają jako poprawki do specyfikacji i backlogu, zanim ruszy development.

W kolejnej lekcji zaczynamy kodować, więc warto się na chwilę zatrzymać i porozmawiać o bezpieczeństwie. Zaczynamy od tego, jak bezpiecznie korzystać z narzędzi do kodowania, jakie konfiguracje stosować i jak zadbać o dane w tym procesie. Przeglądamy używane MCP, analizujemy skille i sprawdzamy, czy nasz setup jest odporny na prompt injection ukryty w opisie zadania, nad którym pracujemy.

Budujemy pierwsze funkcjonalności - na razie w trybie interaktywnym z agentem. Bierzemy specyfikacje i prototyp i wykorzystujemy je do stworzenia działającej funkcjonalności. Mówimy, co jest istotne w samej implementacji, jak dbać o kontekst podczas kodowania, i rozkładamy na czynniki pierwsze skille do implementacji, żeby zobaczyć, jaki workflow jest w nich zaszyty.

Wchodzimy na kolejny poziom. Pokazujemy, co zrobić w swoim projekcie, żeby zwiększyć autonomię pracy agentów: jak zbudować mechanizm pod ephemeral environment i wykorzystać CI oraz testy do dostarczania agentom trafnej informacji zwrotnej. Przechodzimy przez auto-skille do implementacji i sprawdzamy, jaki workflow nadają pracy agentom - jak wykorzystują worktrees i subagentów, żeby dowozić całe funkcjonalności w jednej pętli.

Testy z wykorzystaniem Agent Browser (lub Playwright - wybierzesz sam), które pozwalają automatycznie weryfikować działanie całego systemu. Pokazujemy, jak podchodzimy do generowania testów z AI, jak dbać o pokrycie i co finalnie z tego zostaje. Budujemy zestaw testów dla naszej aplikacji i modyfikujemy SDLC tak, żeby testów integracyjnych nie dało się pomijać.

Wielu agentów pracujących równolegle brzmi kusząco - wydaje się łatwym sposobem na zmultiplikowanie wydajności. W tej lekcji sprawdzamy, gdzie równoległa praca agentów faktycznie przyspiesza wytwarzanie oprogramowania, a gdzie zaczyna się uciążliwa praca dla programisty. Mówimy uczciwie, że człowiek ma swoje granice poznawcze i model pracy, który ma się sprawdzić w dłuższym terminie, musi to uwzględniać. Pokazujemy, jak korzystać z narzędzi takich jak Cezar, i opowiadamy o innych alternatywach.

Testujemy wcześniej zbudowane funkcjonalności, zgłaszamy błędy i naprawiamy je z pomocą agentów. Pokazujemy, dlaczego odpowiedź "fixed" nie zawsze oznacza, że problem faktycznie zniknął, jak szybko weryfikować poprawki przez testy, Playwrighta albo Claude Preview Mode, i jak wykorzystać drugiego agenta do recenzji PR-a i szukania regresji. Wyjaśniamy też, czym jest statyczna analiza kodu i dlaczego przy programowaniu z AI ma większe znaczenie niż wcześniej.

Przejście na tworzenie oprogramowania z agentami AI to proces ciągły - cały czas wyłapujemy błędy w konfiguracji i miejsca do poprawy, dlatego warto zadbać o przestrzeń na pracę nad usprawnieniami. W tej lekcji przechodzimy w zespole przez to, jak wyglądał dotychczasowy proces developmentu: gdzie coś nie zadziałało i jakie poprawki wprowadzić do skilli, CI/CD czy plików kontekstu dla agentów. Opowiadamy też, jak zbieramy dane do takiej rozmowy i jak wprowadzać zmiany, żeby były skuteczne.

Patrzymy na aplikację oczami atakującego. Z pomocą agentów tworzymy prosty model zagrożeń i szukamy miejsc, w których można ominąć uprawnienia, dostać się do danych innego użytkownika lub organizacji, wykorzystać źle zwalidowane dane albo wyciągnąć sekrety. Sprawdzamy IDOR i eskalację uprawnień, a znalezione problemy zamieniamy w poprawki i testy regresyjne. Na koniec dokładamy automatyczne testy bezpieczeństwa do CI/CD.

To jedna z trudniejszych części kursu - proces odbioru pracy agentów. Opowiadamy, jak czytać duże pull requesty i jak wypracować własne podejście do odbioru kodu wygenerowanego przez AI, oraz jak system review, testów i CI wspiera nas w tym procesie. Wyjaśniamy, czym jest skażony kontekst i jak dobór odpowiednich modeli zwiększa liczbę wykrywanych błędów.

Prędkość wytwarzania oprogramowania rośnie, więc nowe funkcjonalności powstają szybciej - ale wciąż muszą zostać przetestowane, zanim trafią do użytkowników. To sprawia, że praca testerów i testerek staje się jeszcze bardziej wymagająca. Mówimy, jak może wyglądać ta nowa rola i jak ułożyć sobie pracę w tym paradygmacie, a także jak odpowiednia konfiguracja pracy agentów wspiera zespół w procesie testowania.

Przez ostatnie lekcje doświadczyliście na własnej skórze, gdzie AI SDLC naprawdę boli: review, odbiór, zaufanie do kodu, którego nikt nie napisał ręcznie. Teraz przekładamy to na Waszą firmę - tam czeka zespół, który mówi "u nas to nie zadziała". Rozbieramy ten opór na cztery główne narracje i pokazujemy, jak na nie odpowiadać. Do tego wzorce wdrożenia: statek piracki zamiast obracania tankowca oraz trzy metody nawracania we właściwej kolejności. Wszystko na aktualnych liczbach i anonimizowanych case'ach z dużych organizacji, z którymi rozmawiam od blisko roku. Wychodzicie z frameworkiem wdrożenia AI w zespole IT i pomysłem, jak zdobyć zaufanie zespołu i zarządu.

‍

Role, docelowy proces i pomiar produktywności celowo zostawiamy na lekcję 20.

Na poprzedniej lekcji rozbrajamy opór - teraz pokazujemy, jak w praktyce wygląda praca zespołu, który już przeszedł na AI SDLC. Przeprojektowujemy proces wytwarzania na prawdziwych przykładach: co się dzieje ze sprintem, gdzie najlepsze zespoły schodzą do sprintu dziennego - agenci pracują w nocy, ludzie w dzień robią review i podejmują decyzje. Pokazujemy, jak zmienia się skład zespołu w kierunku "one-pizza". Za pomocą Matrycy RACI transformacji AI SDLC w prosty sposób mapujecie odpowiedzialności w swoim zespole: kto pisze specyfikację, kto odbiera pracę, kto wydaje - gdy kod piszą agenci. Pokazujemy też, dlaczego QA, Product Manager i UX to zawody przyszłości i jak konkretnie zmieniają się ich zadania. Do tego pomiar realnej produktywności: dlaczego PR-y i liczba linii kodu to vanity metrics, co mierzyć zamiast tego i jak dane konfrontują się z wewnętrznym poczuciem "przecież jest szybciej". Używamy skilla ai-sdlc-score do oceny poziomu wdrożenia AI SDLC w Waszym projekcie. Na koniec anty-wzorzec doklejania AI na siłę i wszędzie - i jak go rozpoznać w Twoim zespole.

Implementujemy kod, korzystając z wielu różnych modeli jednocześnie, z podziałem na role. Pokazujemy, jak dobierać modele i dlaczego teoretycznie słabsze modele potrafią znaleźć błędy w rozumowaniu tych droższych, oraz jak ustrukturyzować przebieg "specyfikacja → implementacja → review". Zastanawiamy się, dlaczego przyszłość może zamienić zespoły developerów w zespoły "developer + agenci", i wyjaśniamy, czym są context contamination, correlated errors i confirmation bias w pracy modeli LLM.

W tej lekcji zajmujemy się wydaniem wersji 1.0.0 budowanej aplikacji: tworzeniem i zarządzaniem changelogiem, mergowaniem otwartych PR-ów z pomocą skilli AI, przygotowaniem wydania i szybkim deployem. Nie skupiamy się tu na devopsie, tylko na samym zamykaniu wersji, generowaniu changelogów, dbaniu o kompatybilność wsteczną i tym, jak AI pomaga zautomatyzować te zadania.

Nie żyjemy w próżni. Projekty w Waszej firmie wciąż powstają w tradycyjny sposób, a Wy po kursie chcecie wrócić do organizacji i pracować dalej w AI SDLC. Jak to zrobić? Czasem najprościej jest zacząć od nowa i przyjąć w projekcie zupełnie nowy sposób pracy, tak jak w naszym kursie - ale w większości przypadków tego komfortu nie mamy. Częściej wygląda to tak: "mamy istniejący projekt i w nim chcemy zacząć pracę w AI SDLC". Pokazujemy konkretne przykłady projektów, które przeszły taką transformację - jaki mieli tech stack, ile linii kodu, jak duży zespół, jakich narzędzi użyli - i oceniamy każdy z nich skillem ai-sdlc-score. Pokazujemy też, jak korzystać z matrycy decyzyjnej, która pozwala szybko ocenić Wasz projekt pod kątem przejścia na AI SDLC w trybie "green field" albo "brown field".

Robimy demo portalu, który udało nam się zbudować, i pokazujemy stan repozytorium - jak na koniec wygląda nasz zestaw skilli i plików dbających o kontekst dla agentów. Podsumowujemy, czego nauczyliśmy się przez ostatnie pięć tygodni, i podpowiadamy, gdzie dalej szukać wiedzy i inspiracji do usprawniania Waszych procesów wytwarzania oprogramowania.

W ostatniej lekcji pokazujemy, jak radzić sobie z projektem po wydaniu pierwszej wersji: jak dodawać nowe wymagania i tworzyć specyfikacje do już istniejących funkcjonalności, jak dbać o aktualność skilli i kontekstu, żeby nie rozjeżdżały się z kodem w czasie. Opowiadamy też, na jakie problemy sami trafiliśmy i jak je rozwiązywaliśmy, rozwijając ten produkt od ponad roku w pełni z AI.