Czego nauczysz się w Developer Jutra?
Poniżej agenda 1. edycji
Materiały publikujemy w poniedziałki od 27.10.2025 do 26.01.2026
Po tym module:
- „Odmagiczniasz” modele i agenty - rozumiesz, jak działają.
- Wiesz, kiedy AI pomaga, a kiedy przeszkadza.
- Umiesz rozmawiać z agentem jak z „aplikacją”.
- Agenty i LLM‑y: Architektura i DziałaniePrzyglądamy się wysoko-poziomowej architekturze systemów agentowych, aby „odmagicznić” ich działanie. Spojrzenie na agenty jak na „aplikacje” pomaga zrozumieć ich mocne strony, ograniczenia, potencjalne zastosowania, szanse - oraz kierunki, w jakich ekosystem będzie się rozwijał.
- Szczypta Machine Learning: Sieci NeuronoweSeria lekcji „Szczypta Machine Learning” ma na celu dać podstawy do zrozumienia, jak działają modele językowe. LLM‑y również chcemy „odmagicznić”. Rozpoczynamy od sieci neuronowych - ich zastosowania, budowy, i celu, jaki pełnią w kontekście LLM‑ów.
- Szczypta Machine Learning: Algebra LiniowaWchodzimy w „just enough” matematyki, potrzebnej podczas „wnioskowania” modelu. Nie bój się matematyki - będą wzory, ale prowadzę za rączkę. Celem jest umiejętność czytania white papers bez odruchów wymiotnych ;)
- Szczypta Machine Learning: Anatomia LLM‑ów i Architektura TransformersUzbrojeni w podstawy sieci neuronowych i algebry liniowej, przyglądamy się architekturze transformers. Stanowi ona absolutnie fundamentalny punkt odniesienia dla praktycznie wszystkich współczesnych modeli językowych. Nie da się przecenić, jak dużą przewagę w skuteczności wykorzystania LLM‑ów daje zrozumienie, jak działają „pod maską”.
- KwantyzacjaKwantyzacja to temat, którego wszyscy użytkownicy LLM‑ów doświadczają, a niewielu rozumie. Biznesowo - technika korzystna jest dla vendora, ale dla użytkowników już niekoniecznie - i na odwrót. Poznajemy mechanizm od środka - i jakie niesie konsekwencje.
- Ekosystem LLM‑owyPo „odmagicznieniu” agentów i modeli, przychodzi czas, aby zanurkować w ekosystem. Poznajemy tooling, jego możliwości i specyfikę.
- Modele Lokalne„Brudzimy sobie ręce”, uruchamiając kilka przykładowych modeli lokalnie. Organoleptycznie doświadczamy ograniczeń i wyzwań stojących przed „małymi” modelami.
- Case Study: Architektura BielikaSyntezujemy wiedzę z poprzednich lekcji, przyglądając się architekturze Bielika - polskiego modelu językowego. Analizujemy jego strukturę i charakterystykę, podsumowując jednocześnie zdobytą wiedzę.
- Budujemy agentyBudujemy aplikację orkiestrującą LLM. Przyglądamy się wzorcom, ale i wyzwaniom, które przed nami stoją.
Po tym module:
- Budujesz kontekst i modelujesz odpowiedzi.
- Minimalizujesz halucynacje w praktyce.
- Uczysz się 3× szybciej z AI (audio/STT, wzorce).
- Budowanie KontekstuBudowanie kontekstu jest fundamentem przy „rozwiązywaniu tasków”, które zajmą więcej, niż 1 prompt. Robi dużą różnicę, jak do tego w praktyce podejdziemy.
- Redukowanie halucynacjiHalucynacje to zmora LLM‑ów - ale także coś, co można redukować. Niestety - ostatecznie wyeliminować się ich - przy obecnej architekturze - nie da. Garść praktycznych przykładów.
- Modelowanie OdpowiedziModele Językowe mają jedną świetną umiejętność - umieją w „przetwarzanie języka naturalnego”. To oznacza, że możemy bardzo istotnie dostosować odpowiedź do potrzeb, jednocześnie będąc świadomym kontekstu w całym procesie.
- Wzorce Promptów„Prompt engineering” jako termin był mocno nadużywany - ale faktycznie istnieją pewne wzorce, które mogą znacząco zmienić jakość odpowiedzi - w szczególności, jeśli „idą w parze” z architekturą LLM‑ów (którą poznaliśmy w poprzednim module). Garść praktycznych przykładów.
- Speech To Text w praktyceAI to nie tylko LLM‑y - modele wyspecjalizowane w rozpoznawaniu mowy pozwalają drastycznie przyspieszyć nam przelewanie myśli na papier... lub na monitor. Poznajemy tooling, możliwości - i zastosowanie.
- Unknown UnknownsAbsolutnie kluczową umiejętnością Developera Jutra jest efektywna nauka, a w szczególności w stylu just-in-time. Żeby to miało sens, trzeba najpierw zidentyfikować swoje unknown unknowns.
- Supermoce NaukiLLM‑y to potężne narzędzie, które możemy wykorzystać do nauki. Efekty mogą być naprawdę spektakularne - ale jesteśmy też narażeni na liczne ryzyka, pułapki (o halucynacjach nie wspominając). Garść praktycznych przykładów. Jestem absolutnie przekonany, że to będzie standardowa praktyka, która nota bene zrewolucjonizuje rynek szkoleniowy (którego częścią sam przecież jestem).
Po tym module:
- Odróżniasz „vibe coding” od profesjonalnej pracy.
- Wybierasz i personalizujesz narzędzia/agentów.
- Budujesz swój ruleset i workflow i jesteś mistrzem MCP.
- Zapomnij o Vibe Codingu!„Vibe Coding” to być może najbardziej kontrowersyjne hasło związane z LLM‑ami - zaraz po słowie „inteligencja” :). Zanim przejdziemy do kodowania z LLM‑ami na potęgę, uświadommy sobie, że „human in the loop” to często absolutna konieczność dla profesjonalnych developerów. I o ile „vibe coding” znajduje „jakieś” zastosowanie - to twarde rozgraniczenie między „LLM‑assisted coding” - a „vibe codingiem” jest kluczowe.
- Platforms & Agent-Assisted DevelopmentNa tym etapie kodujących agentów jest więcej niż frameworków JavaScriptowych :). Czy to dobrze - nie mnie oceniać ;) Ważne, że narzędzia te są de facto bardzo do siebie podobne - i na tym się koncentrujemy.
- Personalizacja narzędziEfektywne wykorzystanie kodujących agentów bezwzględnie wymaga zaawansowanej personalizacji. Temat jest obszerny, a narzędzia różnią się między sobą. I tym zajmujemy się w tej lekcji.
- PricingPricing to długoterminowo najważniejszy temat, który może „wywrócić stolik” związany z szeroko pojętym światkiem „AI”. Zamiast udawać, że go nie ma, i że wszystko jest pięknie i AI czeka tylko świetlana przyszłość - zderzamy się z rzeczywistością. Zaglądamy vendorom tam, gdzie by tego nie chcieli - i wyciągamy wnioski.
- OptymalizacjaOmawianie optymalizacji jest niejako konsekwencją poprzedniej lekcji. To kolejny temat, który developerzy zdają się ignorować, a który wcale nie wymaga wiele wysiłku, aby go stosować. No chyba że uznamy, że „istotna zmiana podejścia” wymaga wysiłku - to owszem ;)
- Multi-tool FlowWykorzystywanie jednocześnie wielu narzędzi może dać ciekawe efekty: nie tylko poprawić jakość, odblokować nowe możliwości, ale także zredukować koszty. Przyglądamy się kilku praktycznym przykładom.
- MCP: Model Context ProtocolNowoczesne systemy agentowe bez RAG/MCP miałyby bardzo ograniczone zastosowanie. Protokół MCP wyewoluował z chaotycznego światka przeróżnych technik RAG - i jest systemem typu plug-and-play, który pozwala na mega elastyczną integrację modeli językowych z przeróżnymi usługami. Serwery MCP karmią model kontekstem - czego? - praktycznie dowolnej usługi, z jaką jesteśmy się w stanie komunikować - a także rozmaitych źródeł danych. Istnieją serwery które już są użyteczne, niemniej, warto umieć stworzyć swój własny - co również robimy. Skupiamy się też na efektywnym wykorzystywaniu MCP (w zależności od ich specyfiki). Oczywiście zaglądamy też pod maskę - bo jakżeby inaczej :)
- PRD & Działający Prototyp ProduktuCoś dla fanów tworzenia produktów - od pomysłu, przez PRD, aż do działającego prototypu. Oczywiście z LLM‑ami/agentami w roli pierwszoplanowej.
- Subagents & Spec-DrivenZawsze marzyłeś o swojej armii agentów? Nie, no, żartuję :P Tak na poważnie - możesz stworzyć i nadać (sub)agentom konkretne role, a następnie zlecać im zadania - i patrzeć, jak marchew rośnie :)
Po tym module:
- Ustawiasz priorytety - produkt > technologia.
- Rozpoznajesz interesariuszy, zdolności, procesy i ich wpływ na architekturę.
- AI pomaga w decyzjach - nie decyduje za Ciebie.
- Inżynieria ProduktowaMówiąc brutalnie, chciałbym, abyś przestał(a) być „klepaczem kodu”, o ile nim jesteś. Lekcja (i cały moduł) ma na celu trochę wyrwać Cię z butów i zmienić fokus znacząco. Być może wejdziesz do (pod)świata IT, w którym jeszcze nie byłeś(aś).
- Eksploracja Nieznanej DomenyPunktem wyjścia do tworzenia dobrego produktu jest zrozumienie domeny, w której działamy. Na pewnym etapie dostęp do eksperta domenowego jest krytyczny - ale jesteśmy w stanie szeroko (i niekoniecznie tylko „wstępnie”) rozpoznać problematykę domeny przy użyciu... LLM‑ów. Jestem przekonany, że to będzie standardowa praktyka w niedalekiej przyszłości.
- Architektura BiznesowaTo nie ta architektura, w której się mówi o mikroserwisach i monolitach :) Biznes też ma swoje aspekty, które są dla niego budulcem, osią i fundamentem. Poznajemy je - i uczymy się, jak je identyfikować.
- Identyfikacja Interesariuszy ProduktuRozpoznajemy osoby i/lub instytucje, bez których produkt ani biznes nie miałby racji bytu. Uczymy się, jak ich identyfikować - i dlaczego w ogóle to jest ważne.
- Identyfikacja Zdolności BiznesowychZdolności biznesowe są z jednej strony budulcem biznesu, z drugiej - z naszej programistycznej perspektywy - są punktem wyjścia do projektowania architektury systemów IT. Bez zagłębienia się w temat, może się on wydawać abstrakcyjny... ale po tej lekcji projektowanie architektury już nigdy nie będzie takie samo.
- Identyfikacja Procesów BiznesowychJeśli zdolności są „budulcem” biznesu, to procesy są jego „ruchomymi częściami”. One też będą miały absolutnie kluczowe przełożenie na architekturę. Nie wspominając, że lwia część taktycznego DDD dotyczy właśnie procesów.
- Identyfikacja Strumieni WartościRozumienie Twojego biznesu nie może być kompletne bez uwzględnienia strumieni wartości. Czy to ma przełożenie na programowanie? Oczywiście. A jakie - tego dowiesz się w tej lekcji.
Po tym module:
- Podejmujesz lepsze decyzje grupowe.
- Stosujesz Impact/Story/Wardley Mapping w praktyce.
- Używasz AI do usprawnienia współpracy.
- Warsztatowe Narzędzia WspółpracyRozumiemy już strukturę, więc przyszedł czas na wydobycie od ekspertów domenowych informacji o biznesie... lub może raczej na „twórczą i konstruktywną konfrontację”, mającą na celu ujednolicenie rozumienia mechaniki naszego biznesu? Istnieje masa technik i narzędzi, które Developer Jutra powinien mieć w swoim arsenale.
- Example MappingRozpoczynamy od poziomu blisko kodu i idziemy w kierunku strategii. Example Mapping jest relatywnie prostym i mega przydatnym narzędziem służącym do doprecyzowania, zilustrowania i ustrukturyzowania wymagań. Poprzez - jak sama nazwa wskazuje - przykłady.
- User Story MappingUser Story Mapping to narzędzie, które pozwala spojrzeć na produkt z perspektywy użytkownika - i zrozumieć, jak jego potrzeby przekładają się na funkcjonalności. To także świetne narzędzie do planowania rozwoju produktu.
- Domain StorytellingDomain Storytelling, stanowiący swoistą alternatywę do Event Stormingu, pozwala wizualizować procesy biznesowe. Ma mocne zalety i mocne wady - jak wszystko. Jeśli nie jesteś „ze światka Event Stormingu”, to być może właśnie to narzędzie najprędzej wykorzystasz w praktyce.
- Impact MappingPrzechodząc na piętro zdecydowanie strategiczne, szukamy, w jaki sposób możemy wpłynąć na poszczególnych interesariuszy. Chcemy osiągać cele biznesowe - ale „CZYM” i „W JAKI SPOSÓB” wcale nie musi być oczywiste. Impact Mapping to narzędzie, które pomaga w tym procesie.
- Wardley MappingOstatnie na naszej liście to wysoko-poziomowe strategiczne narzędzie, którego „przyswojenie” może - nie przesadzam - zmienić Twój sposób postrzegania rzeczywistości - ale i tego jak się ona zmienia. A co kluczowe - zmieniająca się rzeczywistość wpływa również na Ciebie i Twoją wartość. I to dotyczy tak samo Ciebie, jak i biznesu. Przyglądamy się temu narzędziu z obu perspektyw :)
- Opowiedz o swoim produkcie!Na koniec, dla rozluźnienia atmosfery, nurkujemy z powrotem w „narzędziówkę” AI-ową. Patrzymy, jak może pomóc nam w opowiadaniu o naszym produkcie.
Po tym module:
- Rozumiesz, co naprawdę daje konteneryzacja.
- Ogarniasz Dockera, obrazy, optymalizacje, Compose, TestContainers.
- Umiesz w local development i MCP w praktyce - bez bólu i mitów.
- Development + OperationsGdybyśmy zrobili konkurs na najbardziej wypaczone hasło w IT, to „DevOps” byłoby mocnym kandydatem na podium. W tej lekcji przyglądamy się ewolucji procesu wytwórczego i o co tak naprawdę chodzi w DevOps, Team Topologies i DORA. Ale, przede wszystkim „why should you care?”.
- KonteneryzacjaW tej lekcji robimy mały „łomot” - bierzemy obiegowe hasła dot. konteneryzacji i punktujemy, że czym innym są buzzwordy i „myślenie życzeniowe”, a czym innym zrozumienie, gdzie tkwi sedno danego zagadnienia. W tej lekcji dajemy LLM‑om odpocząć - bo w następnych będą miały dużo roboty :)
- Docker EngineKiedy mówisz „docker”, to co konkretnie masz tak naprawdę na myśli? Bo z tym to baaardzo różnie bywa :) W tej lekcji poznajemy nie tylko anatomię dockera - ale i ekosystem wokół. LLM‑y mają co robić :)
- WirtualizacjaFajnie wiedzieć, że kontenery sobie hulają w chmurze. Fajnie wiedzieć, że „security jest ważne”. Ale Developer Jutra drąży (poeta napisałby, że „plwa na skorupę i zstępuje do głębi!”) - bo jeszcze fajniej jest namacalnie przekonać się o zaletach i wadach „lekkości” kontenerów. Podróż w głąb OS sponsorują LLM‑y :)
- Infrastruktura i ChmuraTeraz skaczemy z jednej skrajności (mechaniki wirtualzacji) do drugiej (infrastruktury chmurowej). Przyglądamy się, jak kontenery wpisują się w ekosystem chmurowy - na przykładzie k8s.
- Zarządzanie obrazamiObrazy - praktycznie - od A do Z. Spuszczamy LLM‑y z łańcucha i nie bierzemy jeńców :)
- OptymalizacjePrzyjemna lekcja toolingowa - bierzemy na warsztat rozmaite aspekty związane z optymalizacją obrazów kontenerowych. Oczywiście, ręka w rękę z LLM‑ami. To nie tylko kwestia „mniejszego obrazu” - ale także bezpieczeństwa, wydajności, i wielu innych aspektów.
- Docker Compose„Komponujemy” infrastrukturę ze współpracujących ze sobą kontenerów. Poznajemy możliwości narzędzia - i zajeżdżamy LLM‑y na maksa...
- Docker MCPStricte techniczna lekcja, podczas której ustawiamy serwery MCP dla dockera w „5 smakach”. Rozwiązujemy ewentualne problemy, związane z kontenerami, z poziomu agenta.
- Lokalny Development z KonteneramiŻeby pracować efektywnie, to musimy mieć wygodny tooling. W tej lekcji bierzemy na warsztat DevContainers oraz Docker Compose Watch.
- Test ContainersKonteneryzacja umożliwia nam nie tylko wykorzystanie infrastruktury chmurowej - ale także, poniekąd, rewolucjonizuje kwestie testowania systemów. W tej lekcji zaprzęgamy LLM‑y do testowania środowiska wielo-komponentowego.
Po tym module:
- Znasz priorytety weryfikacji kodu AI (co sprawdzać, a co nie).
- Projektujesz moduły, stan, heurystyki.
- Poznajesz Vertical Slices Architecture na froncie.
- Problematyka FrontenduW tym module NIE „kopiujemy ANF”, tylko zaprzęgamy agenty/LLM‑y do tworzenia frontendu. Najpierw jednak dekomponujemy problematykę frontendową na poszczególne składowe (zarządzanie stanem, type safety, testowalność, itp itd) - aby potem móc maksymalnie delegować robotę agentom.
- Tworzenie UI z AI - PriorytetyWszyscy mówią - i powszechnie wiadomo - że output z AI trzeba „weryfikować”. Zgoda. Ale czy chcesz weryfikować wszystko (w kodzie wyplutym przez agenta)? Nie szkoda Ci czasu? Co warto weryfikować, a co niekoniecznie?
- Frontendowy Tooling okiem ArchitektaDowcipasy dotyczące „frameworków JS przybywających z każdym tygodniem” na szczęście straciły na aktualności. Ale w zależności od stosu, w którym pracujesz, wybór może być nadal mglisty. Wykorzystujemy sprytnie LLM‑y, aby powiedziały nam nie o tym, jak frameworki twierdzą, że są „blazing fast”, tylko jakie faktycznie plusy, minusy i specyfika za nimi stoją. A przy trochę pokodują.
- Frontendowe Prompty i Reguły dla AIMontujemy „pliki rules” z uwzględnieniem rzeczy „ważnych”, ale także odpowiednio dobieramy prompty - aby agenty/LLM‑y jak najszybciej robiły to, co chcemy.
- Modularyzacja i Projektowanie Stanu - oraz HeurystykiZa chwilę będziemy „cięli” aplikację na kawałki. Ale zanim to zrobimy, musimy przemyśleć, jakim kluczem naszą aplikację „pokroić”. W tej lekcji wykonujemy fazę koncepcyjną, podczas której LLM‑y odpoczywają - a już zaraz będą miały co robić.
- VSA na froncieBrudzimy sobie ręce na maksa. Przebudowujemy aplikację z chaotycznego vibe-nie-wiadomo-czego w przemyślany styl Vertical Slices Architecture. Oczywiście - nie my - tylko agent/LLM pod naszym nadzorem.
- TestowanieLLM‑y świetnie się nadają do zaprzęgnięcia ich do pisania testów automatycznych. Co też w tej lekcji robimy.
Po tym module:
- Modelujesz (ER/SQL) i świadomie projektujesz restrykcje.
- Optymalizujesz: indeksy, widoki, EXPLAIN; spójność i transakcje.
- Rozumiesz, kiedy użyć bazy relacyjnej, a kiedy dokumentowej.
- Problematyka Baz DanychNawet jeśli na co dzień piszesz SQLe, to daj się zaskoczyć! W tej lekcji przyglądamy się zaawansowanym zagadnieniom bazodanowym - aby zdiagnozować nasze unknown unknowns.
- Modelowanie bazy z LLMDla wybranego obszaru, wykorzystując wiedzę o biznesie (z poprzednich modułów), zaprzęgamy LLM‑y do zaprojektowania bazy danych w oparciu o ER/SQL. Ogólnie - to robota mocno iteracyjna - gdzie my szczególnie musimy nadzorować proces: albo samodzielnie kierunek narzucać (a LLM‑owi tylko zlecać czarną robotę) - albo kwestionować, jeśli zlecasz LLM‑owi rozwiązanie.
- Ile restrykcji w bazie - a ile poza?Nie tylko jakie restrykcje możemy nałożyć na dane w bazie - ale także - czy w ogóle powinniśmy to robić w bazie?
- Integracja z MCPIntegracja agenta z Postgresem poprzez MCP będzie mega przydatna. Garść praktycznych przykładów.
- Techniki optymalizacjiTechniczna lekcja, w której bierzemy na warsztat zagadnienia takie jak: indeksy, zmaterializowane widoki czy EXPLAIN. My wiemy, co chcemy osiągnąć - a agent/LLM dostaje robotę do wykonania.
- Współbieżność, Spójność i TransakcjeJeden z najważniejszych obszarów bazodanowych, ogólnie. W tej lekcji przyglądamy się różnym modelom spójności, stopniom izolacji i problemami jakie się wiążą ze współbieżnością (być może nawet bardziej, niż chcemy). Bo jeśli mamy weryfikować kod wypluty z LLM‑a, to chyba my jesteśmy tymi, co „mają wiedzieć, jak ma być”, prawda?
- Bazy DokumentoweNie każda baza musi być relacyjna, prawda? A kiedy, na dobrą sprawę, powinna być relacyjna? W tej lekcji na warsztat bierzemy Mongo - i każemy agentowi/LLM‑owi zakodować to i owo.
- JSONB: nie w pełni ustrukturyzowane daneW sumie to po co używać Mongo, skoro można mieć Mongo w postgresie? :) Zaprzęgamy agenta/LLM‑a aby nie tylko oprowadził nas po świecie JSONB i zakodował co nieco.
Po tym module:
- Rozumiesz kiedy i po co inwestować w observability i jak mierzyć efekty.
- Wchodzisz w instrumentację: metryki, logi, trace'y; OpenTelemetry.
- Przeprowadzasz stress‑testy i inspekcję na żywo.
- Monitoring i obserwowalnośćNiektórzy developerzy mawiają: „Dobrze, jeśli (w projekcie) w ogóle jest jakikolwiek monitoring”. Z jednej strony coś w tym jest, niestety (z reguły, jak mamy awarię, to na kolana i do Częstochowy)... ale skoro mamy brać temat na warsztat, to rozpocznijmy od „po co” - i co nam taka inwestycja może dać. Uzbrojeni w wiedzę/skille infrastrukturalne wiemy, jaki setup/infrę ma wygenerować LLM.
- InstrumentacjaŻeby słowo stało się ciałem, nasze serwisy trzeba dość intensywnie „okablować”. I to pod konkretny stos. Dużo kodowania, oj dużo. Wiadomo kto ;) W tej lekcji wchodzimy w temat metryk, logów i trace'ów - od strony kodu. A LLM oprowadza po toolingu.
- Open TelemetryTooling wokół observability nieco przypomina ten javascriptowy... trochę ;) na szczęście powołano do życia standard Open Telemetry, który ma na celu ujednolicenie podejścia. Kodujemy - choć wiadomo, że nie my :) Ale my mamy umieć to zweryfikować.
- MetrykiNurkujemy w pierwszy z „3 filarów” observability - metryki. Przyglądamy się, co można mierzyć, jak i po co. Wiadomo kto koduje.
- LogiPrzechodzimy do logów - drugiego filaru. Co logować - to niby każdy wie - byle nie za dużo, bo to nie są tanie rzeczy. Tak czy siak, po pierwsze trzeba wyklikać w Grafanie dashboardy - a po drugie - okablować odpowiednio kod. Wiadomo kto.
- TracingKto robi to mówić nie trzeba :) Trzeci filar observability - tracing. Obserwujemy, w jaki sposób „ślad” requestu rozciąga się pomiędzy różnymi serwisami.
- Stress Testy: dawaj, wytrzymaNa koniec modułu - konfigurujemy stress testy, aby mierzyć, jak nasz system radzi sobie pod obciążeniem. Jak zwykle - my musimy wiedzieć co, i po co - a kto koduje to też wiadomo.
Po tym module:
- Masz szeroki ogląd: od CRUDa po bounded contexts i archetypy.
- Wiesz, jak użyć AI z DDD w praktyce (bez „strzału w skroń”).
- Znasz HTTP/REST/RPC, OpenAPI, testy kontraktowe (Pact).
- Problematyka BackendowaW tej lekcji przyglądamy się wybranym zagadnieniom backendowym, czyli: domena, modularyzacja, model danych, integracje. Zarysowujemy klucze, wg których będziemy weryfikowali implementację wygenerowaną przez agenta/LLM‑a.
- Moduły CRUDoweJaki CRUD jest - każdy widzi - ale nawet i CRUDa można „zepsuć”. Poza kilkoma wskazówkami - w tej lekcji głównie skupiamy się na zaprzęgnięciu agenta/LLM‑a do skutecznego generowania CRUDów - bo tu weryfikacja jest relatywnie najprostsza.
- Modelowanie Bounded ContextówNie wszystko jednak może (czy powinno) być CRUDem. Nie wszystko można „dzielić rzeczownikami”. Nawiązujemy do wiedzy z architektury biznesowej (i nie tylko) - i projektujemy granice odpowiedzialności modułów. Są miejsca, gdzie obecne LLM‑y NIE są pomocne - lub wręcz, przeciwskuteczne. I temu też się przyjrzymy.
- Przemodelowanie modułu z archetypamiNawet jeśli wydaje się, że „problematyka” modułu została poprawnie pokrojona - to programiści często operują na niewłaściwym poziomie abstrakcji. Archetypów jest dużo (i jest nim też poświęcone inne szkolenie z Kubą, Bartkiem i Sławkiem - które mega polecam). W tej lekcji jednak bierzemy na warsztat przykładowy archetyp, przemodelowujemy to, co mamy. I weryfikujemy - na ile LLM może tu pomóc (czy nie lepiej zrobić to samemu) - lub, precyzyjniej: na jakim poziomie szczegółowości LLM jest „znowu przydatny”.
- Agregaty, Sagi i reszta zoo DDDW tej lekcji przyglądamy się wybranym wzorcom DDD, które mogą pomóc w modelowaniu bardziej złożonych problemów biznesowych. Spuszczenie LLM‑ów z łańcucha - w tym przypadku - to totalny strzał, już nawet nie w stopę, a w skroń. Ale, znowu - wykorzystywanie LLM‑ów to nie kwestia 0-1 (binarne tak lub nie). Tę tematykę omawiamy w tej lekcji + oczywiście, kodujemy.
- Style APIKażdy zna HTTP. Ale każdy na innym poziomie :) Dodatkowo - twórcy wielu API z rozpędu mówią, że ich API jest RESTowe. Mhm :) Ilustrujemy mniej znane zagadnienia związane z HTTP, REST i RPC - aby później je zakodować.
- OpenAPI: kontrakty dla HTTPZaprzęgamy LLM‑y do roboty z OpenAPI/Swagger. Automatyzujemy generowanie interfejsów i dbamy o type-safety. Każdy pracuje nad inną częścią - my nad koncepcją, LLM - nad realizacją.
- Pact: testy kontraktowe„Nasz klient, nasz pan”: przyglądamy się konceptowi CDC. Implementujemy testy kontraktowe w Pact.
- Testowanie endpointówGarść praktycznych technik, narzędzi i przykładów - aby wygodnie testować endpointy. Wiadomo kto robi brudną robotę :)
