AI to nie nowa warstwa tortu, tylko polewa

„Kto używa AI codziennie w pracy?”

Ręce podniosła prawie cała sala.

„Nie opuszczajcie! A teraz: kto, oddając wynik pracy AI kolejnej osobie w procesie, potrafi ocenić, czy jest on dobry jakościowo, i mógłby tu przyjść i mi o tym opowiedzieć?”

Została jedna ręka.

Tak Kamil Reszka z Benefit Systems pokazał na konferencji „Analityk / Architekt w erze AI”, gdzie leży problem. Z AI korzystają prawie wszyscy. Ale mało kto wie, co się dzieje z jego wynikiem, kiedy trafia do kolejnej osoby.

„To trochę jakbyście poszli do lodziarni i przez szybę patrzyli, jak inni jedzą. Dobrze, że jesteście”.

Zapamiętajcie KOP

Kamil zaczął od tego, że każda firma ma jakiś proces wytwarzania oprogramowania (SDLC). Często nawet dwa: ten opisany w procedurach i ten, który naprawdę działa w cieniu. A on przyszedł sprawę jeszcze bardziej skomplikować, bo dochodzi do tego nowa, jeszcze niezdefiniowana warstwa: AI.

Na wypadek, gdyby prezentacja kogoś rozczarowała, poprosił o zapamiętanie chociaż trzech słów, które składają się w skrót KOP:

• Kontekst: kto go odtworzy?
• Osąd: kto oceni wynik?
• Przepływ: kto będzie mógł go użyć dalej?

„Jak to zapamiętacie, to już będę was bardzo kochał. Cała reszta jest wtórna”.

Kamil ma za sobą przeszłość programisty, od kilku lat jest architektem, a do tego kieruje zespołem. Patrzy więc na proces z dwóch stron naraz: menedżera i architekta. Uprzedził, że nie pokaże wielkich wdrożeń jak przedmówcy, tylko „intymne spojrzenie na pracę jednego zespołu”.

Polewa, nie biszkopt

Żeby wyjaśnić, jak widzi AI w procesie, Kamil pokazał dwa torty, które sam zaprojektował.

Pierwszy to klasyczny proces: warstwy analizy, projektowania, implementacji, testów, wdrożenia i utrzymania, ułożone jedna na drugiej. Warstwy, które nie leżą obok siebie, nigdy się nie spotykają. Nawet nie wiedzą o swoim istnieniu.

Na drugim torcie AI nie jest kolejnym biszkoptem ani dekoracją na górze. Jest polewą, która wnika w tort i łączy warstwy. Dzięki niej mogą „zagadać” do siebie role, które wcześniej się nie spotykały. Na przykład tester z analitykiem, co w zespole Kamila wcześniej było, jak mówi, nie do pomyślenia.

Dlatego warto patrzeć na styki między fazami, a nie tylko na pojedyncze fazy. Dziś często optymalizujemy jedną fazę i ułatwiamy sobie własną pracę. Kamil uważa, że to za mało.

Jeden zespół

Zespół Kamila to osiem osób w IT i Product Ownerka po stronie biznesu: dwóch analityków biznesowo-systemowych, architekt i tech lead w jednej osobie, czterech programistów full-stack i tester automatyzujący.

Najważniejsza myśl tej części:

„AI w SDLC nie unieważnia kompetencji. Ono sprawia, że przesuwa się środek ciężkości pracy”.

Trzeba więc ustalić, co wnosi człowiek, co AI, kto ocenia wynik i dokąd on trafia dalej. Kamil dodał przestrogę: nie licytujmy się na liczbę narzędzi. Często te potrzebne już mamy, na przykład Jirę i Confluence.

Umowa przed oddaniem pracy

Zanim zleci się zadanie AI, trzeba ustalić warunki odbioru. Zadanie dla AI jest częścią współpracy, a nie osobnym światem. Kamil rozpisał to na cztery obszary:

• Kontekst: jakie dane i źródła, jakiej jakości, z jakimi uprawnieniami, jakie ustalenia z biznesem i dobre praktyki.
• Odbiorca: kto oceni wynik, kto podejmie decyzję, jak wygląda odbiór.
• Kryteria: co musi być poprawne, czego nie wolno zmienić, jak traktować błędy.
• Ślad: jak odtworzyć ocenę, skąd pochodzi wniosek, jak śledzić koszt, czy wszystko jest zgodne z zasadami.

Bramki jakości zostają, a odpowiedzialność jest po stronie ludzi. Kamil podkreślił, że przekazujemy znaczenie, a znaczenie ma sens tylko wtedy, gdy razem z nim idą dane i dowód. „W przeciwnym razie to ma wartość horoskopu”.

Historia pierwsza: nie co, tylko po co

Do zespołu przyszedł kierownik z biznesu, który rozlicza zespół z prowizji. Chciał, żeby w aplikacji był dowód wyliczenia prowizji. Pierwsze skojarzenie: kalkulator z wielką formułą.

Analityczka mogła po prostu zamienić prośbę w historyjkę dla programistów. Zamiast tego zapytała nie „co”, tylko „po co”. Z pomocą AI przygotowała serię pytań, między innymi: „Co kierownik sprawdza podczas akceptacji?”. Potem zrobiła z nim warsztat.

Okazało się, że kalkulator nie jest potrzebny. Kierownik chce zatwierdzić prowizję, a do tego wystarczy, że zobaczy jej składniki i kwotę końcową. Kontrolowanie formuły nie jest jego zadaniem.

W języku KOP: kontekst wnieśli analityczka i Product Owner, AI zaproponowało pytania, osąd należał do analityczki, a do programistów trafiło poprawione wymaganie. Zmiana zaszła na samym początku procesu, czyli w najtańszym możliwym miejscu.

Historia druga: architekt i jego sparingpartner

Projekty wysokiego poziomu (HLD) w zespole przygotowuje głównie Kamil. Korzysta przy tym z dwóch narzędzi:

• Asystent to jego sparingpartner. Kamil daje mu kontekst, business case, kryteria, zasady i dobre praktyki. Dyskutują, asystent proponuje, Kamil ocenia.
• Agent w Jirze (oparty na Rovo) wchodzi do gry, gdy zakres zmian jest już uzgodniony. Bierze zatwierdzony projekt i tworzy z niego robocze zadania, które architekt potem przegląda.

Z projektu wynikają zadania technologiczne i makiety, a do tego kontekst dla kolejnych osób i agentów.

Delegujemy przygotowanie, nie odbiór

Jeden z programistów, senior Grzesiek, którego Kamil nazwał ambasadorem AI w zespole, przygotował trzy osobne zastosowania:

• Makiety: z opisu zmiany powstaje makieta do rozmowy. Człowiek ocenia, czy dobrze zrozumieliśmy potrzebę i przepływ. Jak mówi Kamil, makieta wyraża więcej niż kilkanaście stron wymagań.
• Historyjki: z opisu i wymagań powstają zadania do pracy. Człowiek ocenia, czy zakres jest kompletny.
• Przegląd kodu: z kodu i praktyk zespołu powstają uwagi. Człowiek ocenia, czy zmiana spełnia dobre praktyki.

Zasada jest jedna: wynik pracy AI jest początkiem kolejnej oceny, rozmowy albo działania. Delegujemy przygotowanie materiału, nigdy jego ostateczny odbiór.

Historia trzecia: agent, który poprawiał umowy

Zespół ma kilkadziesiąt szablonów ofert i umów. Tworzenie i zmiana warunków logicznych w szablonach zajmowały analitykowi dwa, trzy tygodnie.

Powstał więc agent w M365 Copilot, który na podstawie dokumentacji z Confluence zamieniał warunki biznesowe na znaczniki sterujące dokumentem. Zajmowało mu to kilka minut.

Kłopot pojawił się przy bardziej złożonej logice: koniunkcjach, negacjach i operatorach. Zamiast wstawiać znaczniki, agent zaczął zmieniać słowa w tekście prawnym umowy.

Zespół nie poprawił tylko jednego promptu. Dodał przykłady poprawnych przekształceń i listę błędów, których agent ma unikać, a całą tę wiedzę zapisał w Confluence. Zasada brzmi: korekta eksperta wraca do wiedzy agenta.

Zielony test to jeszcze nie zgoda

Szybką wygraną okazały się testy jednostkowe i integracyjne, które zespół generuje z pomocą asystentów. Żeby wejść na szybką ścieżkę wydania, trzeba mieć 60% pokrycia kodu testami.

Kamil ostrzegał jednak, żeby oddzielić powstanie testu od jego wartości. To, że test powstał i świeci na zielono, nie znaczy, że jest dobry. Zgłoszenie do release managera w stylu „mamy 60%, wjeżdżamy na produkcję jak Intercity w ciężarówkę” nie przejdzie. Dopuszczenie do wydania nadal wymaga ludzkiej oceny.

Do tego dochodzi testowanie samego AI, które zachowuje się w sposób trudny do przewidzenia. To „nie jest hop-siup”. Wymaga testów statystycznych, automatycznych (na przykład w Promptfoo), zapisywania źródeł i śledzenia, skąd pochodzi wynik. A i tak, jak podkreślił Kamil, nie mamy gwarancji, jak model zachowa się pod spodem. Wiemy tylko, jak go użyliśmy.

Co mierzyć

Na pewno nie liczbę wygenerowanych linii kodu ani zadań. Kamil proponuje cztery inne miary:

• czas do odbioru, czyli ile trwa droga do zaakceptowanego wyniku,
• nakład eksperta, czyli ile czasu człowiek spędza na sprawdzaniu i poprawkach,
• opóźnienie kontekstu, czyli jak późno pełny kontekst trafia do osoby albo agenta, który ma wykonać pracę,
• koszt użycia, czyli tokeny i licencje.

O koszcie Kamil opowiedział anegdotę. Kiedy firma obniżyła limity kredytów na AI, w zespole zawrzało. Dla programisty odebranie asystenta to jak przesiadka z rakiety na furmankę.

Trzy lekcje i jeden eksperyment

Kamil podsumował wystąpienie trzema lekcjami:

1. Zacznij od potrzeby. AI pomaga zadawać pytania, ale to ludzie ustalają, czego naprawdę potrzebują.
2. Daj kontekst i granice. Źródła, reguły i zakres dopuszczalnej zmiany wyznaczają ramy pracy maszyny.
3. Zaprojektuj odbiór wyniku. Ocena człowieka i bramki jakości decydują, czy wynik pójdzie dalej.

Efektywność całego procesu jest ważniejsza niż przyspieszenie jednego kroku. Chodzi o krótszą drogę między fazami i rzadsze odtwarzanie kontekstu od zera.

Na koniec zostawił salę z eksperymentem:

„Z kim sprawdzę jedną zmianę na jednym zadaniu w moim procesie i jaki będzie miernik?”

Trzeba ustalić kontekst i kryteria odbioru, a potem zmierzyć czas i liczbę poprawek. Jeśli okaże się, że w danym miejscu AI wcale nie pomaga, to też jest cenna wiedza.

Pytania z sali

Zapytałem, jak zespół dba o to, żeby wszyscy korzystali z asystentów w spójny sposób. Czy mają wspólne repozytorium promptów i instrukcji, czy każdy robi po swojemu?

Kamil odpowiedział „poprawnie" czyli "hybrydowo”. W każdym repozytorium kodu są pliki z instrukcjami i konwencjami dla asystentów, ale ludzie mają też swoje własne techniki. Ujednolicanie praktyk to ciągła praca.

Andrzej Sobczak zapytał o koszty. W kuluarach słychać, że wiele firm obcina budżety na tokeny. Jak zespół śledzi wydatki na AI i porównuje je z wartością, jaką dają analitycy i architekci?

Po pierwszym zamieszaniu limity trochę podniesiono, ale zespół uczy się korzystać z AI rozsądnie. Model dobiera się do wagi zadania, bo nie do wszystkiego potrzeba najdroższych modeli. Koszty licencji i API są śledzone, a wartość biznesowa jest oceniana na poziomie całego cyklu życia produktu: każda inicjatywa jest wyceniana i sprawdzana, czy przyniosła realny zwrot.