Twój zespół + AI.

Konfigurujemy wspólny warsztat: Claude Code, Codex, GitHub Copilot, VS Code, CEZAR i sandboxy – jedno środowisko dla całej grupy od pierwszego dnia. Ustalamy też, czym AI Engineering różni się od dopisywania kodu z podpowiedziami.

Jak przeprowadzić zespół przez zmianę: nowe role i kompetencje, opór i obawy, przeprojektowanie procesu zamiast doklejania AI do istniejącego oraz mierzenie realnej produktywności – dane zamiast poczucia, że jest szybciej. Na koniec odpowiadamy, dlaczego QA, Scrum Master i UX to zawody przyszłości.

Zespół siada do wspólnego kickoffu: czym Customer Portal jest, a czym nie jest - nie sklepem, bo zamiast koszyka mamy wniosek - jakie ma typy użytkowników i jak wygląda zakres E01-E20 z podziałem na MVP i F2. Ustalamy cel, którym jest Demo Day, zasady współpracy i wstępny podział odpowiedzialności.

Przechodzimy proces, którego efektem jest dokument wymagań: analiza z AI, typy użytkowników, "usługa" jako abstrakcja, wniosek zamiast koszyka, priorytetyzacja MVP wobec F2 i struktura EPIC - STORY - TASK ze stałymi identyfikatorami. Na tej podstawie budujemy syntetyczne persony: karta persony jako prompt, symulowane wywiady, przejście kluczowych przepływów ich oczami i walidacja priorytetów oraz luk w wymaganiach.

Stawiamy projekt od podstaw: repozytorium, strategia branch-y, tablica z epikami, DoD i podział ról, a następnie stack, monorepo, środowiska, docker-compose i skrypt bootstrap. Każdą decyzję uzasadniamy pod kątem tego, co realnie ułatwi później pracę agentom.

Dobieramy i adaptujemy skille pod wzorce powtarzające się w portalu: lista z filtrami, sortowaniem i paginacją, CRUD z testem uprawnień, migracje, generowanie testów dostępu. Do tego techniki prompt engineeringu - bo realnie opłacają się tam, gdzie prompt piszemy raz i używamy wielokrotnie: w skillach, definicjach agentów i promptach zaszytych w kodzie łączącym się z API.

Budujemy kontekst pracy: plik zasad projektu, szablon specyfikacji taska z wyraźnym zakresem i tym, co poza zakresem, definicja gotowości taska dla agenta oraz konwencja commitów i pull requestów. Zasady egzekwujemy dwutorowo - hookami działającymi w trakcie pracy agenta i bramkami w pipelinie (lint, typecheck, testy, build, blokada merge przy zmianach poza zakresem) - bo zasada, której nic nie pilnuje, jest tylko sugestią.

Hardening warsztatu: sandbox z listą dozwolonych operacji, zasada najmniejszych uprawnień, sekrety poza repozytorium i MCP, przegląd używanych MCP i skilli oraz reguły dla CEZAR-a czytającego zgłoszenia - rozbicie lethal trifecta i człowiek przed merge. Na demo przeprowadzamy prompt injection treścią zgłoszenia od klienta.

Piszemy speckę: model danych (Organization → User → Role, Service → ServicePoint, UsageRecord, Invoice, Ticket, Request → RequestType, Document, AuditEvent), konwencje API - odpowiedzi, paginacja, idempotencja, strefy czasowe - adapter źródła z mockiem i rejestr ADR. Decyzja numer jeden: wielodostępność egzekwowana w warstwie zapytań, nie w kontrolerach.

Tokeny z trybem ciemnym, komponenty bazowe (tabela, panel filtrów, formularz, karta, badge statusu, stan pusty), wzorzec "lista z filtrami" jako jeden komponent wielokrotnego użytku i Storybook. Do tego powłoka aplikacji: layout, nawigacja i przełącznik organizacji.

Prototyp: pulpit z kaflami i osią czasu, karta usługi z powiązanymi obiektami, pełne flow wniosku od prewypełnienia po decyzję oraz warianty widoku zależne od roli. Prototyp walidujemy syntetycznymi personami - tarcia wychwycone w tym przejściu wracają jako poprawki do specki, zanim ruszy development.

Pierwszy pionowy przekrój budowany w parze z agentem: organizacje z hierarchią centrala-oddziały, użytkownicy z rolami, macierz uprawnień z middleware, logowanie z sesją niosącą użytkownika, organizację i rolę, zaproszenia mailem, seed trzech organizacji i słowniki startowe. To jedyny fragment, który każdy musi rozumieć w stu procentach - na uprawnieniach opiera się cała reszta systemu.

Flagowa funkcja budowana autonomicznie ze specki: generyczny silnik wniosków - typy z własnym schematem pól i ścieżką akceptacji, renderer formularza z definicji, walidacja z jednego źródła, reguły akceptacji, kolejka "do akceptacji" i cykl życia wniosku. Tu weryfikujemy, ile z jakości wyniku wynika wprost z jakości specki.

Pełna retrospektywa zespołowa po pracy interaktywnej i autonomicznej: co zadziałało w parze z agentem i w pracy ze specki, gdzie agent schodził z torów, jak sprawdziły się skille w praktyce i jakie korekty procesu wprowadzamy przed wejściem w pracę równoległą. Przy okazji uczymy się prowadzić retro w zespole pracującym z agentami - co mierzyć: jakość specek, skuteczność skilli, koszty inferencji.

Trzy strumienie prowadzone jednocześnie: usługi i umowy z wykresami zużycia i limitami, faktury z saldem i płatnością mockowaną oraz zgłoszenia z konwersacją i SLA liczonym w godzinach roboczych. Sprawdzamy, gdzie równoległość naprawdę przyspiesza, a gdzie zaczyna kosztować więcej, niż daje.

Testujemy efekt poprzedniej lekcji, błędy zgłaszamy jako issues, a naprawia je CEZAR działający na regułach z lekcji siódmej - z testem-perełką: zgłoszenie założone w piątek wieczorem, ze świętem w środku okresu SLA. Równolegle rusza drugi przebieg: dokumenty, powiadomienia i backoffice.

Proces odbioru pracy agentów: jak czytać duże pull requesty, czego wymagać i kiedy odrzucać, a w portalu B2B - uprawnienia i izolacja organizacji sprawdzane w każdym PR, automatem i przez człowieka. Odpowiadamy też na pytanie, dlaczego recenzji nie może zrobić ten sam agent, który pisał kod: skażony kontekst sprawia, że recenzent zna własne uzasadnienia zamiast patrzeć na kod świeżym okiem, a confirmation bias domyka pętlę - dlatego review uruchamiamy na czystym kontekście.

Scenariusze end-to-end trzech ścieżek krytycznych - logowanie, wniosek z akceptacją, opłacenie faktury - projektowane przez testera, a wykonywane przez agentów. Do tego dane testowe i izolacja uruchomień.

Testy wykorzystujące Playwright, które pozwalają na automatyczną weryfikację całego systemu: jak podchodzimy do generowania testów z AI, jak dbać o pokrycie i co finalnie dostajemy jako rezultat. Efektem lekcji jest utworzenie zestawu testów dla naszej aplikacji.

Realizacja epików bezpieczeństwa: sesja i nagłówki (CSP, HSTS, CSRF), ochrona kont, walidacja wejścia i upload (podpisane linki, ochrona CSV), sekrety i skan zależności; threat model trzech przepływów, testy IDOR i eskalacji, test pokrycia uprawnień, test dostępu organizacja A → organizacja B; przegląd danych osobowych. Domknięcie klamry z lekcji siódmej.

Prowadzimy jedno zadanie przez pełny flow z modelami w rolach: specyfikacja, trzy niezależne recenzje specki, implementacja, trzy sesje code review - każda rola na modelu dobranym do tego, co ma robić. Pokazujemy, że jednostką pracy staje się "developer i jego zespół AI", i dlaczego różnorodność modeli podnosi jakość: modele popełniają skorelowane błędy, więc trzy recenzje tym samym modelem to nie są trzy niezależne recenzje.

Wydanie 1.0: automatyczny deploy środowiska demo, migracje z możliwością wycofania, feature flags per organizacja pozwalające włączać moduły wybranym klientom. Changelog powstaje agentowo.

Cała ścieżka wdrożenia: wybór zespołu pilotażowego, polityki użycia narzędzi AI wraz z kwestią shadow AI i danych firmowych, governance i budżet z kosztami inferencji, metryki wdrożenia oraz moment, w którym pilota należy przerwać. Na dowodach z portalu budowanego w kursie - liczba pull requestów od agentów, lead time, koszt inferencji na funkcję, wynik testu pokrycia uprawnień - składamy z tego playbook przejścia na standard.

‍

Pełne demo portalu: logowanie jako buyer-admin, pulpit z osią czasu, karta usługi ze zużyciem, opłacenie faktury, zgłoszenie z SLA, wniosek przechodzący przez akceptację i tryb podglądu backoffice z zapisem w audycie. Na koniec retrospektywa całego procesu.

Co dzieje się z portalem po wydaniu: nowe wymagania dopisywane do istniejącej specki, aktualizacja kontekstu i skilli, żeby nie rozjechały się z kodem, zmiany łamiące kontrakt API, obsługa zgłoszeń produkcyjnych i dług technologiczny widziany oczami agenta. Pokazujemy też, jak wprowadzić do dojrzałego repozytorium nową osobę i nowego agenta oraz ile realnie kosztuje utrzymanie takiego systemu.