Agenci AI w zespole: co daje szkolenie i kto jest na nie gotowy

Agenci AI to nie pierwszy krok wdrożenia AI, tylko jeden z ostatnich, a szkolenie z nich zakłada, że zespół dowozi kod również bez nich. Ma proces, który ktoś potrafi opisać w trzech zdaniach. Ma testy, którym ufa. Ma recenzję kodu, która naprawdę się odbywa. Agent wzmacnia to, co już działa, i rozsadza to, co ledwo się trzyma.

Kolejność kosztuje. Dwa dni całego zespołu kosztują więcej niż sama faktura za warsztat, bo do niej dochodzi zatrzymana dostawa. Jeśli po szkoleniu nikt nie ma gdzie wpiąć agenta, cała ta suma przepada. Patrzę na to z dwóch stron. Prowadzę takie warsztaty, a wcześniej sam kupowałem szkolenia dla własnego zespołu jako CTO.

Dalej idzie konkret. Czym warsztat z agentów różni się od zwykłego kursu i jakie warunki musi spełnić zespół. Co dzieje się na sali przez dwa dni. Czego w dwa dni nauczyć się nie da i kto powinien odpuścić.

Czym różni się od zwykłego szkolenia z AI

Kurs promptowania uczy narzędzia. Ktoś pokazuje okno czatu, kilka dobrych wzorców promptu i triki na dłuższy kontekst. Po takim kursie ludzie piszą lepsze prompty i na tym zmiana się kończy. Jako pierwszy krok dla całej firmy ma to sens.

Warsztat z agentów dotyka czegoś innego. Zespół oddaje część pracy procesowi, który działa sam. Agent czyta repozytorium, uruchamia komendy, zmienia pliki i otwiera pull requesta. Każda z tych czynności wymaga decyzji inżynierskiej: gdzie postawić granicę, jak sprawdzić wynik i kto bierze go na siebie.

Zmienia to skład sali. Na kurs o promptach wysyła się chętne osoby z różnych działów. Na warsztat z agentów przychodzi zespół, który dzieli jedno repozytorium, bo decyzje z drugiego dnia zostaną w tym repozytorium na długo. Jeśli połowa sali nie ma dostępu do kodu, ćwiczenia rozjeżdżają się już przed obiadem.

Dlatego program takiego warsztatu przypomina raczej przegląd architektury niż kurs obsługi. Największy spór na sali dotyczy zwykle granic. Ile agent może zrobić sam. Kiedy musi się zatrzymać i kto klika akceptację. Warto to sobie przemyśleć jeszcze przed warsztatem. Dwa dni to za mało, żeby dojść do tego od zera. Opisałem osobno, jak ustalić granice agenta, zanim ruszy na produkcję.

Kryteria gotowości zespołu

Przed warsztatem sprawdzam pięć rzeczy. Żadna nie jest wygórowana. Wszystkie są minimalne.

Zespół, który spełnia cztery warunki z pięciu, spokojnie wchodzi na warsztat i nadrabia brakujący punkt w trakcie. Zespół, który spełnia jeden, dostaje ode mnie inną propozycję. Najpierw porządek w procesie, potem agenci. Taka odmowa kosztuje mnie kontrakt, a klientowi oszczędza dwa stracone dni.

Bywa też, że zespół spełnia kryteria na papierze, a na sali wychodzi, że testy chodzą tylko lokalnie u jednej osoby. Widać to w pierwszej godzinie i wtedy zmieniam plan dnia. Lepiej poświęcić przedpołudnie i uruchomić pipeline, niż udawać, że reszta ćwiczeń ma sens bez niego.

Jak wygląda dwudniowy warsztat dla zespołu

Sala pracuje na repozytorium zespołu. Ludzie siedzą przy swoich maszynach, z własnym stackiem i własnym długiem technicznym. Prowadzący chodzi między nimi i patrzy na ekrany.

Pierwszego dnia zespół używa agentów w codziennej robocie z kodem. Każdy odpala agenta na swoim zadaniu i po godzinie trafia na ścianę. Agent robi połowę dobrze, a w drugiej połowie wymyśla nazwę funkcji, której w projekcie nie ma. Wtedy zaczyna się najważniejsza część dnia. Jak sprawdzić wynik szybciej, niż zajęłoby napisanie go ręcznie. Zespół uczy się czytać diff zamiast czytać opis zmian.

Po południu wraca pytanie, na ile agentowi ufać. Ktoś zawsze mówi, że szybciej napisze to sam. Czasem ma rację i trzeba to nazwać głośno. Dzielimy więc robotę na dwie listy: tam, gdzie agent daje przewagę, i tam, gdzie generuje wyłącznie pracę do weryfikacji. Ta lista zaskakuje zespół bardziej niż cała reszta dnia.

Drugiego dnia budujemy. Projektujemy architekturę, nadajemy dostępy, domykamy bezpieczeństwo i planujemy, jak to wjedzie na produkcję. Tu zaczynają się kłótnie, bo każdy inaczej patrzy na to, ile swobody dać agentowi i gdzie postawić twardą blokadę. Większość tych sporów rozstrzyga ta sama garstka reguł, którą zebrałem w zestaw dwunastu decyzji projektowych, przy każdej z zieloną radą i czerwoną pułapką.

Dzień kończy się czymś, co da się odpalić w poniedziałek. Zespół wychodzi z agentem zbudowanym na własnym przypadku, z repozytorium ćwiczeń i z checklistą, którą sprawdza wyniki. Trzy rzeczy zamiast wrażeń.

Format jest wąski celowo. Dwa dni i praca na waszym kodzie, cena od 18 000 zł netto online albo od 24 000 zł netto on-site z dojazdem w cenie, za zespół do dwunastu osób za dwa dni. Terminy ustalam indywidualnie. Stack i cel opisujecie wcześniej, a formularz i pełny zakres warsztatu znajdziecie na stronie szkolenia.

Czego nie da się nauczyć w dwa dni

Warsztat daje umiejętności i punkt startu. Osądu nie daje, bo osąd bierze się z nieudanych prób.

Pierwsza rzecz spoza zasięgu dwóch dni to ocena, który problem w ogóle zasługuje na agenta. Pokażę kilka kryteriów i dwa przypadki z własnej praktyki. Wybór dla waszej domeny zrobicie sami, po kilku tygodniach. Świeżo po szkoleniu najczęściej ktoś wpina agenta tam, gdzie w zupełności wystarczyłby skrypt.

Podobnie jest wtedy, gdy zespół dzieli pracę między kilka agentów. Świeżo po warsztacie ludzie chętnie stawiają trzech agentów tam, gdzie wystarczy jeden z porządnym zestawem narzędzi. Zanim rozbijecie system na role, sprawdźcie, kiedy jeden agent wystarcza i co realnie kupuje podział na role.

Druga rzecz to zbiór ewaluacyjny dla waszej domeny. Kilkadziesiąt przypadków z poprawnymi odpowiedziami, na których mierzycie każdą zmianę promptu. Na sali zbudujemy szkielet i pierwsze przypadki. Reszta rośnie tam, gdzie agent się myli, czyli już na produkcji. Zbiór ewaluacyjny mierzy przy tym model, a nie kod, który go pilnuje. Ten drugi mierzy się inaczej: psuje się go w jednym miejscu i sprawdza, czy testy to wyłapią.

Trzecia to nawyki operacyjne. Kto patrzy na logi w poniedziałek rano, co robicie z serią cichych porażek i kiedy wyłączacie agenta. Tego nie da się przećwiczyć na sali, bo potrzeba tygodni prawdziwego ruchu. Warsztat ustawi najwyżej pierwszy dyżur i pierwszy alert.

Dla kogo to nie jest

Trzem typom zespołów odmawiam i wolę powiedzieć to przed fakturą.

Pierwszy: zespół, który nie ma kodu na produkcji. Agenci pokazują, ile są warte, dopiero na istniejącym systemie, z historią commitów, testami i długiem technicznym. Na pustym repozytorium warsztat zamienia się w pokaz możliwości. Pokaz nie zmienia tego, jak ludzie pracują.

Drugi: firma, która chce usłyszeć o trendach. To sensowna potrzeba, tylko obsługuje ją inny format. Godzinny wykład dla całego działu daje więcej niż dwa dni pracy inżynierów przy komputerach, bo trafia do ludzi, którzy podejmują decyzje o budżecie. Podobnie jest z salą, w której nikt nie pisze kodu. Program układam wtedy od innej strony i zostawiam ludziom jedną czynność do wykonania w poniedziałek, co rozpisałem w tekście o szkoleniu dla sali bez inżynierów.

Trzeci: organizacja, w której nikt nie weźmie wyniku na siebie. Jeśli repozytorium z warsztatu nie ma właściciela, a wdrożenie nie ma miejsca w planie kwartału, wiedza rozejdzie się w tydzień. Pytam o to na rozmowie wstępnej i czasem sam proponuję, żeby przesunąć termin o kwartał.

Jest jeszcze czwarty przypadek, rzadszy i przyjemniejszy. Zespół, który ma już agentów na produkcji i szuka odpowiedzi na jeden konkretny problem. Wtedy dwa dni programu to za dużo. Kilka godzin nad ich architekturą załatwia sprawę lepiej.

Najprostszy test gotowości zajmuje pięć minut. Zapytaj trzy osoby z zespołu, jak zadanie idzie od zgłoszenia na produkcję. Trzy różne odpowiedzi znaczą, że zaczynacie od procesu, a warsztat planujecie na kolejny kwartał.

Najczęstsze pytania