Od doraźnego używania AI do świadomego budowania z LLM.

Przechodzimy przez bilans ostatnich dwóch lat: które zapowiedzi się nie zmaterializowały, które technologie realnie weszły do produkcji i na czym koncentruje się dziś rynek. Omawiamy m.in. AI-assisted coding, RAG na własnych danych, tool calling, agentów i MCP, modele rozumujące oraz modele otwarte, które można uruchomić we własnej infrastrukturze. To ostatnie przesądza o tym, czy dane muszą wyjść poza Waszą organizację.

Osobno omawiamy ekonomię korzystania z modeli: dlaczego spadająca cena za token nie zawsze przekłada się na niższy rachunek i jak liczyć koszt per efekt, a nie per token.

EfektRozróżniacie, co jest dziś realne, a co nadal obietnicą, i potraficie to uzasadnić przed zespołem i zarządem.

Ustawiamy trzy intuicje, które wystarczą do dalszej pracy:

• dlaczego model przewiduje najbardziej prawdopodobną kontynuację zamiast prawdy i skąd biorą się halucynacje
• dlaczego nie dysponuje pamięcią poza bieżącym kontekstem
• na czym polega jego niedeterminizm

Najwięcej czasu poświęcamy kontekstowi: czym jest, jak się go utrzymuje i dlaczego zarządzanie nim przesądza o jakości wszystkiego, co dalej. Świadomie nie wchodzimy w architekturę transformerów ani w mechanikę atencji, bo nie są kluczowe dla codziennej pracy.

EfektRozumiecie, dlaczego model zachowuje się tak, a nie inaczej, bez zaglądania pod maskę.

Pokazujemy, w których miejscach odruchy z klasycznego wytwarzania oprogramowania zawodzą: determinizm, powtarzalność, testowalność. Omawiamy między innymi:

• dlaczego większe okno kontekstu nie zawsze oznacza większą trafność
• jak nadmiar nieistotnych treści pogarsza odpowiedź
• dlaczego model to niestabilna zależność zewnętrzna, a nie stały element infrastruktury

EfektWiecie, czego nie wolno założyć, projektując system z LLM, i dlaczego ktoś musi go świadomie zaprojektować oraz pilnować.

Na żywo bierzemy realny przypadek: klasyfikację tekstu pisanego przez ludzi. Najpierw obsługuje go router oparty na słowach kluczowych, potem ten sam przypadek dostaje model.

Na tej podstawie rozmawiamy o różnicy między wypisaniem z góry wszystkich możliwych sformułowań a rozpoznawaniem sensu oraz o tym, gdzie kończy się dopasowanie wzorca, a zaczyna rozumowanie. O ten sam mur rozbiły się kiedyś systemy eksperckie. Omawiamy też przypadek odwrotny: kiedy model powinien tylko rozpoznać, o co chodzi, a resztę robi zwykły, przewidywalny kod.

Porządkujemy kryteria oceny i każdy uczestnik może je przyłożyć do własnego przypadku: deweloper do fragmentu kodu, product manager do funkcjonalności, menedżer IT do procesu.

Przykładowe kryteria:

• charakter wejścia: czy dane mają stałą strukturę, czy pisze je swobodnie człowiek?
• koszt pomyłki: ile kosztuje błędna odpowiedź i kto ją wychwyci?
• dostępność kontekstu: czy w Waszych systemach jest to, czego model potrzebuje do decyzji?
• tolerancja zmienności: czy dopuszczacie różne odpowiedzi na to samo pytanie?

EfektWychodzicie z kryteriami, które przykładacie do kolejnych pomysłów, oraz z decyzją dla przypadku omówionego na sali.

Zaczynamy od tego, dlaczego model realizuje to, co napisaliście, a nie to, co mieliście na myśli, i dlaczego wąsko postawione zadanie dostaje odpowiedź załatwiającą jeden przypadek. Omawiamy też, dlaczego nie mija to z kolejnymi generacjami modeli.

Pokazujemy, jak zamiast szukać lepszego sformułowania, opisać klasę problemu.

Rozkładamy takie zadanie na części, które da się ocenić osobno:

• zakres: co jeszcze jest tym samym problemem, a co już potraktować jako osobny przypadek
• kontekst: co model musi wiedzieć, żeby sobie z nimi poradzić
• format odpowiedzi: w jakiej postaci wynik trafia do kolejnego kroku
• przypadki brzegowe: co zrobić, gdy brakuje danych albo pytanie jest spoza zakresu

EfektRozpoznajecie, kiedy dostaliście rozwiązanie klasy problemu, a kiedy łatkę na jeden przykład.

Kontekst to całość informacji, które LLM otrzymuje razem z zadaniem. Omawiamy, co powinno się w nim znaleźć, żeby zadanie dało się wykonać, i jakie są konsekwencje źle zaplanowanej struktury kontekstu.

W praktyce sprowadza się to do kilku decyzji:

• dobór informacji: co jest niezbędne do wykonania zadania, a co dokładamy na wszelki wypadek
• długa sesja: kiedy skompresować, kiedy odciąć wątek, a kiedy zacząć od nowa
• reguły projektu: co zapisać raz na stałe, żeby nie wklejać tego przy każdym zadaniu
• rachunek: ile kosztuje trzymanie tego wszystkiego w kontekście

EfektWiecie, co z kontekstu wyrzucić, a nie tylko co do niego dodać.

Przechodzimy przez techniki, które realnie zmieniają wynik, i pokazujemy, na czym polega ich działanie.

• przykłady: kiedy dwa dobrze dobrane przykłady robią więcej niż akapit opisu
• format odpowiedzi: wymuszenie struktury, którą da się sprawdzić maszynowo
• podział zadania: co zyskujecie, rozbijając je na kroki, a co tracicie
• samosprawdzenie: kiedy prośba o weryfikację pomaga, a kiedy tylko wydłuża rachunek

Osobno omawiamy rady, które straciły aktualność, i te, które działają tylko przy niektórych modelach. Omawiamy, dlaczego „myśl krok po kroku” przestało być dźwignią przy modelach rozumujących, a przy mniejszych i wewnątrz pętli narzędziowych nadal się liczy.

EfektWiecie, która technika ma sens przy modelu, którego używacie, zamiast stosować wszystkie naraz.

Omawiamy, jak zebrać zestaw realnych przypadków, ustalić dla każdego, co znaczy dobra odpowiedź, i przepuścić przez nie kolejne wersje instrukcji.

• dobór przypadków: przypadki z realnego użycia, w tym te zakończone błędem
• kryterium oceny: jednoznaczna definicja dobrej odpowiedzi, niezależna od tego, kto ocenia
• liczebność zestawu: ile przypadków potrzeba, żeby pojedynczy wyjątek nie przesądzał o ocenie
• porównanie wersji: jak odróżnić rzeczywistą poprawę od przypadku

Osobno omawiamy pułapkę, w którą łatwo wpaść: zestaw, pod który zaczynacie nieświadomie dostrajać instrukcję, przestaje cokolwiek mierzyć.

EfektPo zmianie instrukcji wiecie, czy wynik jest lepszy, czy tylko inny.

Dajemy przygotowane zadanie razem z kilkunastoma przypadkami i oczekiwanymi odpowiedziami. Pracujecie w parach, a na koniec porównujemy wyniki.

• zakres: które przypadki instrukcja ma obsłużyć, a które odrzucić
• kontekst: co dołożyć do polecenia, a czego nie
• pierwsza wersja: uruchomiona na przygotowanym zestawie
• poprawka: druga wersja porównana na tym samym zestawie

Na koniec zestawiamy wyniki par. Na jednym zadaniu widać wtedy, jak bardzo rozjeżdżają się rozwiązania i które sformułowania wypadły lepiej.

EfektMacie przećwiczony cykl od instrukcji do porównania wersji i widzicie, jak różne sformułowania wypadają na tym samym zestawie.

Pokazujemy, czym te narzędzia różnią się w praktyce: co działa w edytorze, co w terminalu, a co dostaje dostęp do całego repozytorium i uruchamia polecenia.

• zakres dostępu: jeden plik, projekt czy cała maszyna
• tryb pracy: podpowiedź w locie kontra zadanie zlecone i wykonane w tle
• efekt pracy agenta: diff, zapis decyzji, czy sam kod bez kontekstu

Nie porównujemy ich na punkty, bo układ sił zmienia się co kwartał. Pokazujemy kryteria, którymi sami je ocenicie, gdy pojawi się następne.

EfektWiecie, które narzędzie pasuje do której pracy i czego wymagać od kolejnego, które wejdzie na rynek.

Każdą pułapkę pokazujemy tak samo: po czym poznać ją w diffie, skąd się bierze i co z nią zrobić.

• hardcoding: agent gasi konkretny błąd zamiast rozwiązać klasę problemu, a przypadków szczególnych przybywa
• context rot: w długiej sesji jakość spada, a wcześniejsze ustalenia mieszają się ze sobą
• sykofancja: model potwierdza Waszą błędną tezę, zamiast ją zakwestionować
• ciche założenia: dopowiada wymagania, których nikt nie podał

Przy hardcodingu omawiamy też, dlaczego nie mija z kolejnymi generacjami modeli. Dwa lata temu był prymitywny i widoczny gołym okiem, dziś bywa subtelniejszy, a mechanizm został ten sam.

EfektRozpoznajecie te zachowania w kodzie, zanim trafią do gałęzi głównej.

Kod od asystenta czyta się inaczej niż kod kolegi: nie ma kogo zapytać, dlaczego tak został zaimplementowany, a całość wygląda na dopracowaną niezależnie od tego, czy jest poprawna.

Omawiamy, na co patrzeć najpierw i jakie pytania kontrolne zadawać, żeby wychwycić to, co wygląda dobrze, a nie zadziała poza przykładem, na którym powstało.

EfektCzytacie taki kod szybciej i celniej, zamiast przeglądać wszystko albo ufać, że skoro testy przechodzą, to jest dobrze.

Przechodzimy przez to, co asystent przestawia w pracy zespołu, a nie tylko pojedynczego programisty.

• estymacje: pierwsze osiemdziesiąt procent przyspiesza, ostatnie dwadzieścia zwykle nie
• review: z wąskiego gardła staje się głównym punktem kontroli jakości
• onboarding: asystent wytłumaczy system dokładniej niż zajęty kolega, tylko że pisanie kodu ręcznie wymuszało zrozumienie, a generowanie już nie
• własność kodu: kto odpowiada za fragment, którego nikt nie napisał ręcznie

EfektWiecie, które miary i rytuały zespołu przestają działać po wejściu asystentów, i czym je zastąpić.

Bierzemy zadanie z prawdziwego repozytorium i prowadzimy je z asystentem od opisu do gotowego diffa.

EfektWidzicie cały cykl na żywo, razem z miejscami, w których zwykle się urywa.

Trzy rzeczy, które w rozmowach nazywa się tym samym słowem. Ustawiamy granice: co decyduje o kolejnym kroku, kto ma dostęp do systemów i co się dzieje, gdy coś pójdzie nie tak.

• czat: odpowiada, a działanie zostaje po Waszej stronie
• automatyzacja: wykonuje kroki, które ktoś wcześniej ustalił
• agent: sam wybiera kolejny krok w granicach, które mu wyznaczono

EfektRozpoznajecie, co dostawca naprawdę oferuje, kiedy mówi „agent”.

Rozkładamy agenta na składowe i pokazujemy przebieg jednego okrążenia: model dostaje kontekst, wybiera narzędzie, dostaje wynik i decyduje, czy kończyć.

• pętla decyzyjna: co ją zatrzymuje i co się dzieje, gdy nic jej nie zatrzyma
• narzędzia: skąd model wie, że istnieją, i jak wybiera między nimi
• pamięć: co zostaje między krokami, a co znika
• stan systemu: co trzeba zapisać poza modelem, żeby wznowić przerwaną pracę, także po awarii

EfektPotraficie wskazać, w którym miejscu agent podejmuje decyzję i gdzie da się go zatrzymać.

Omawiamy mechanizm, którym model wywołuje kod: jak opisuje się narzędzie, co model dostaje z powrotem i dlaczego opis narzędzia bywa ważniejszy od jego implementacji.

MCP bierzemy jako standard porządkujący tę wymianę między dostawcami. Pokazujemy, co realnie daje, a czego nie rozwiązuje.

EfektWiecie, jak wystawić własny system agentowi i o co dopytać dostawcę, który deklaruje obsługę MCP.

Rozbicie zadania na kilku wyspecjalizowanych agentów brzmi porządkująco, a często zwiększa tylko liczbę miejsc, w których coś może pójść nie tak.

Omawiamy kryterium, które to rozstrzyga: nie liczba agentów, tylko to, co między nimi przechodzi. Części, które idą równolegle i nie czekają na siebie, dzielą się dobrze, bo każdy agent pracuje na własnym kontekście. Kroki następujące po sobie mają sens wtedy, gdy przekazują sobie kompletny wynik, na przykład dokument albo zestaw danych, a nie streszczenie rozmowy, której następny agent nie odtworzy. Tam, gdzie takiego czystego przekazania nie da się zapewnić, jeden agent z dobrze opisanymi narzędziami wypada lepiej.

Na tym tle przeglądamy konkretne architektury: te, które mają za sobą wdrożenia, te, o których mówi się więcej, niż widać w praktyce, i te, które już się nie obroniły.

• stała ścieżka z krokami modelu: to z niej pochodzi większość działających wdrożeń, bo kolejność kroków i obsługa błędów zostają w kodzie, a model odpowiada za pojedyncze fragmenty
• agent prowadzący z pomocniczymi: sprawdza się tam, gdzie części zadania są od siebie niezależne i nic nie zapisują, jak szukanie i porównywanie informacji
• jeden agent wykonuje, drugi sprawdza: działa, gdy sprawdzający ma czym zweryfikować wynik, na przykład testami, a nie tylko opinią tego samego modelu
• agenci z przypisanymi rolami: ten sam model z kilkoma promptami systemowymi i tym samym dostępem do narzędzi, podczas gdy realny podział wymaga rozdzielenia narzędzi, uprawnień albo samego modelu
• długi łańcuch przekazań bez wspólnego stanu: każdy krok dostaje tylko streszczenie poprzedniego, więc gdy pojedynczy wychodzi w dziewięćdziesięciu pięciu procentach, po dziesięciu całość wychodzi w sześćdziesięciu

Osobno liczymy rachunek: każdy agent to osobne płatne wywołanie modelu, a kroki wykonywane po kolei wydłużają czas odpowiedzi.

EfektUmiecie uzasadnić, dlaczego w Waszym przypadku jeden agent wystarczy albo dlaczego nie.

Ustalamy, gdzie agent działa sam, a gdzie czeka na człowieka. Kryterium nie jest techniczne: wynika z tego, co da się cofnąć, a czego nie.

• operacje nieodwracalne: wysłanie, płatność, usunięcie, zmiana uprawnień
• zakres uprawnień: co agent widzi i co może zrobić w czyimś imieniu
• treść z zewnątrz: co się dzieje, gdy w pobranym dokumencie siedzi instrukcja dla modelu
• zatrzymanie awaryjne: jak zatrzymać agenta w trakcie, co zrobić z krokami, które zdążyły przejść, i co musi zostać w logu, żeby odtworzyć przebieg

EfektMacie listę miejsc, w których trzeba postawić zatwierdzenie, zanim agent wejdzie do systemów produkcyjnych.

Budujemy na żywo agenta z kilkoma prostymi narzędziami i obserwujemy, po czym wybiera jedno z nich i jak prowadzi zadanie dalej.

EfektWidzicie mechanizm od środka, a nie z opisu w dokumentacji dostawcy.

RAG bywa pierwszą odpowiedzią na każde pytanie o dane firmowe, choć część przypadków rozwiązuje się prościej i taniej.

Omawiamy, przy jakiej skali i zmienności danych RAG zaczyna się opłacać, i co dziś jest jego realną alternatywą.

• cały zbiór w kontekście: gdy dokumentów jest niewiele i rzadko się zmieniają, taniej wychodzi podać je w całości i korzystać z buforowania, niż utrzymywać indeks
• wyszukiwanie agentowe: agent przeszukuje system źródłowy tak, jak zrobiłby to człowiek, więc dane nigdzie się nie duplikują, a uprawnienia zostają po stronie systemu
• wyszukiwanie po słowach: wystarcza, gdy pytania są powtarzalne, a dokumenty dobrze opisane
• RAG: uzasadniony tam, gdzie zbiór jest duży, często się zmienia, a pytań nie da się z góry przewidzieć

EfektRozstrzygacie, czy Wasz przypadek w ogóle wymaga RAG, zanim ktoś zacznie go budować.

Przechodzimy drogę dokumentu od źródła do odpowiedzi i zatrzymujemy się tam, gdzie zapadają decyzje.

• podział dokumentów: co jest jedną porcją treści i dlaczego to przesądza o reszcie
• wyszukiwanie: po znaczeniu, po słowach, czy jedno i drugie
• ranking wyników: co decyduje, które fragmenty trafią do modelu, gdy wyszukiwanie zwróci ich kilkanaście
• aktualność: co się dzieje, gdy dokument źródłowy się zmienia
• odpowiedź: jak model ma wskazać źródło każdego twierdzenia

EfektCzytacie architekturę cudzego rozwiązania i wiecie, o co dopytać.

Najczęstsza diagnoza brzmi „model jest słaby”, a najczęstsza przyczyna leży wcześniej: dokument nie został znaleziony albo znaleziono nie ten fragment.

Pokazujemy, jak rozdzielić te dwa przypadki, bo naprawia się je zupełnie inaczej.

EfektUmiecie wskazać, czy problem siedzi w wyszukiwaniu, czy w modelu, zamiast wymieniać model na większy.

Wyszukiwanie po dokumentach firmowych zderza się z tym, że nie każdy może zobaczyć wszystko. Omawiamy, co trzeba ustalić, zanim pierwszy dokument trafi do indeksu.

• uprawnienia: czy odpowiedź respektuje to, do czego pytający ma dostęp
• dane wrażliwe: co nie powinno wejść do indeksu w ogóle
• gdzie to stoi: co zostaje u Was, a co wychodzi na zewnątrz
• zmiany uprawnień: co dzieje się z indeksem, gdy ktoś traci dostęp do dokumentu, który został już zaindeksowany
• rejestr zapytań: kto o co pytał i co dostał w odpowiedzi

EfektMacie listę ustaleń, bez których projekt RAG nie przejdzie przez bezpieczeństwo.

Bierzemy przygotowany zbiór dokumentów i pokazujemy, jak zachowuje się wyszukiwanie przy różnych pytaniach.

Zbiór jest dobrany tak, żeby pokazać konkretne awarie na żądanie, zamiast czekać, aż wydarzą się przypadkiem. Wasze przypadki omawiamy na tym tle, bez potrzeby wnoszenia danych na salę.

EfektWidzicie, gdzie w tym łańcuchu najczęściej gubi się trafność.

Rozszerzamy to, co przy pracy z modelem robiliśmy na jednej instrukcji, na całe rozwiązanie.

• zestaw ewaluacyjny: przypadki z oczekiwaną odpowiedzią, utrzymywane razem z systemem
• ocena automatyczna: kiedy model może oceniać model i gdzie to zawodzi
• bramka: próg, poniżej którego zmiana nie wchodzi na produkcję

EfektWiecie, czego wymagać od dostawcy, który twierdzi, że jego rozwiązanie działa dobrze.

Rachunek rzadko rośnie od liczby użytkowników. Rośnie od tego, ile kontekstu wędruje przy każdym wywołaniu i ile razy system wywołuje model, żeby odpowiedzieć raz.

• wielkość kontekstu: co dokładacie przy każdym zapytaniu
• liczba wywołań: ile kroków robi agent, zanim odpowie
• ponowne próby: co się dzieje przy błędach i czy ktoś to liczy
• dobór modelu: gdzie potrzebny jest najmocniejszy model, a gdzie wystarczy tańszy i szybszy

EfektUmiecie oszacować koszt rozwiązania przed wdrożeniem i wskazać, co podnosi go najbardziej.

System, który działał w dniu uruchomienia, nie musi działać za kwartał. Zmienia się ruch, zmieniają się dane, a dostawca podmienia wersję modelu.

• jakość w czasie: czy odpowiedzi nadal przechodzą zestaw ewaluacyjny
• zmiana modelu: co robicie, gdy dostawca wypuszcza nową wersję
• koszt i czas odpowiedzi: czy rosną szybciej niż ruch
• sygnał od użytkownika: jak zgłasza, że odpowiedź była zła

EfektMacie wskaźniki, po których poznacie, że coś się psuje, zanim zgłosi to klient.

Każdy zapisuje kryteria dla jednego rozwiązania ze swojej organizacji: co musi być spełnione, żeby dało się je wypuścić, i co oznacza, że trzeba je wycofać.

EfektWychodzicie z kryteriami, które da się wpisać do umowy albo do definicji ukończenia.

Po kilku miesiącach od wejścia asystentów w zespole istnieje zwykle tyle sposobów pracy, ile osób. Każdy ma własne instrukcje, własne ustawienia i własne przekonania o tym, co działa.

Omawiamy, co warto ustalić wspólnie, a co spokojnie zostaje indywidualne. Osobno szukamy miejsca na te ustalenia, żeby nie skończyły jako kolejny dokument, którego nikt nie czyta.

EfektWiecie, które decyzje muszą być zespołowe, i macie miejsce, w którym żyją.

Funkcja, która w środku ma model, wymaga innego opisu niż deterministyczna. Nie da się zapisać, co ma zwrócić, więc zapisuje się, co jest akceptowalne.

• zakres: co funkcja obsługuje, co odrzuca i jak to komunikuje
• akceptowalny wynik: kiedy odpowiedź jest dobra, a kiedy tylko prawdopodobna
• zachowanie przy porażce: co widzi użytkownik, gdy model nie daje rady
• sposób odbioru: co uruchamiacie i jaki wynik uznajecie za wystarczający

EfektPiszecie specyfikację, na podstawie której da się odebrać pracę.

Demo powstaje w kilka dni, a wdrożenie trwa kwartał. Ta różnica nie bierze się z opieszałości zespołu, tylko stąd, że ostatnie dwadzieścia procent to integracja, przypadki brzegowe i uzgodnienia, których na demie nie widać.

Pokazujemy, jak planować pracę, w której nie wiadomo z góry, ile iteracji będzie potrzebnych, i jak rozmawiać o tym z biznesem, zanim padnie data.

EfektUmiecie uzasadnić harmonogram, zamiast bronić terminu, który powstał po obejrzeniu dema.

Omawiamy, co w tej zmianie należy do lidera, a nie do zespołu: dobór narzędzi i granice ich użycia, standard review oraz rozwój ludzi, których praca przesuwa się z pisania na ocenianie.

Omawiamy też pytanie, które pada najczęściej i najrzadziej doczekuje się odpowiedzi: co zrobić z osobą, która nie chce z tego korzystać.

EfektWychodzicie z listą decyzji do podjęcia i wiecie, które z nich nie mogą czekać.

Dajemy opis gotowej funkcjonalności, w której ma się znaleźć komponent AI. Przepisujecie go, pracując w zespołach: zakres, akceptowalny wynik, zachowanie przy porażce i sposób odbioru.

EfektMacie wzorzec, który przykładacie do kolejnych funkcji.

Przechodzimy przez rzeczy, których brak wychodzi dopiero po uruchomieniu, a wtedy kosztuje najwięcej.

• pomiar jakości: zestaw ewaluacyjny i próg, poniżej którego nie wypuszczacie
• zabezpieczenia: co system robi z treścią, której nie powinien wykonać
• nadzór: kto patrzy na wskaźniki i jak często
• rollback: jak wrócić do poprzedniej wersji w godzinę

EfektMacie listę kontrolną, którą przechodzicie przed każdym uruchomieniem.

Rozmawiamy o tym, co warto budować samemu, a co kupić, oraz o tym, że granica przesuwa się tu szybciej niż w innych obszarach.

• wyróżnik: czy to rzecz, która Was odróżnia, czy infrastruktura
• dane: co musiałoby wyjść poza organizację
• utrzymanie: kto to rozwija za rok
• wyjście: co się stanie, gdy dostawca zmieni warunki

EfektUmiecie uzasadnić decyzję przed zarządem i wiecie, kiedy ją zrewidować.

Ostatnia część dnia jest na porządkowanie: każdy wypisuje, co chce zrobić po powrocie, a my mówimy, co zwykle udaje się w pierwszym miesiącu, a co wymaga dłuższego przygotowania.

EfektWiecie, od czego zacząć i co odłożyć, żeby nie zaczynać od najtrudniejszego.