Te cztery liczby opisują najważniejszą zmianę, jaką AI wprowadziło do mojej pracy. Nie chodzi o to, że maszyna pisze szybciej. Chodzi o to, że wąskie gardło projektu przesunęło się z produkcji na jakość źródła prawdy.
Agent wykonuje. Nie interpretuje.
Krótkie wyjaśnienie dla porządku. Agent AI to program, który dostaje zadanie i sam je wykonuje: czyta dokumenty, pisze kod, sprawdza wyniki. Nie czeka, aż ktoś kliknie. Od dwóch projektów pracuję metodą Spec-Driven Development, w skrócie SDD, w której kolejność jest odwrócona względem tego, co znam z dwudziestu lat projektów. Najpierw powstaje specyfikacja, czyli spisana, weryfikowalna prawda o tym, co system ma robić, dlaczego i po czym poznamy poprawny wynik. Dopiero potem agent zamienia ją na kod.
Najbliższa analogia to budowa domu. Agent jest ekipą, która pracuje szybko, tanio i bez marudzenia. Specyfikacja jest projektem budowlanym. A ja jestem kimś między projektantem a inspektorem nadzoru. Ustalam, co jest prawdą, i sprawdzam, czy ekipa się jej trzyma.
Ekipa jest znakomita, ale ma jedną cechę, o której trzeba wiedzieć. Wykonuje projekt dosłownie. Jak w rysunku brakuje wymiaru, dopowie go sobie i wymuruje ścianę tam, gdzie jej pewnie chcieliście. Pewnie. To słowo kosztuje najwięcej. Z agentem bywa trochę jak z dżinem: źle sformułowane życzenie zostanie spełnione co do joty. A każde życzenie kosztuje, bo tokeny, czyli moc obliczeniowa modeli, to realne pieniądze. Kto każe maszynie zgadywać, płaci dwa razy: za wygenerowanie błędu i za jego sprzątanie.
Co się zmieniło w mojej pracy
Przez lata wyglądało to tak: analityk pisze wymagania, programista je czyta, a po drodze jest kilkanaście spotkań, na których obie strony docierają, o co właściwie chodziło. Luki w dokumencie łatał człowiek, zadając pytania. Ten mechanizm bywał powolny, ale dawał wymaganiom drugą szansę.
Agent pytań zadaje mało. Luki łata domysłem i robi to bardzo pewnym tonem.
Ciężar przesuwa się więc w jedno miejsce, na jakość źródła prawdy. Moja praca przestała polegać na pisaniu dokumentów, które ktoś potem zinterpretuje. Polega na budowaniu materiału, od którego maszyna nie ma prawa odejść. Każde wymaganie musi mieć źródło. Każda reguła musi mieć test. Każda dziura musi być opisana jako dziura, a nie zamalowana. W tym układzie najważniejszym dokumentem projektu nie jest sprytny prompt, tylko komplet: źródła, reguły, kryteria akceptacji, scenariusze testowe i rejestr decyzji.
Jak to wygląda w praktyce
Przykład z mojego biurka. Zbudowałem macierz wymagań regulacyjnych dla systemów kasowo-magazynowych aptek w Polsce. W liczbach: 361 reguł, 1083 scenariusze testowe, 122 karty źródłowe z odesłaniem do konkretnych artykułów ustaw, rozporządzeń i dokumentów. Każda reguła ma trzy testy spisane zanim powstanie jakikolwiek kod. Przypadek typowy, graniczny i negatywny.
Automatyczne kontrole spójności całości kończą się zerem błędów. To ważny wynik, ale nie przypisuję mu więcej, niż znaczy: potwierdza spójność zdefiniowanego materiału, nie jest certyfikatem kompletności prawnej ani zwolnieniem z przeglądu eksperta.
Zrobiłem to bez zespołu programistów, pracując z agentami. Równolegle prowadzę migrację systemu kasowego w dużej sieci detalicznej i buduję drugą macierz, tym razem procesową. Nie od strony prawa, tylko od strony codziennej pracy apteki: jak naprawdę wygląda przyjęcie towaru, realizacja recepty, zamknięcie dnia.
Jest jeden szczegół, z którego jestem przewrotnie dumny. Ta macierz ma status roboczy, „szkic z luką”. Jedna luka wisi otwarta, bo potrzebny dokument techniczny instytucji publicznej jest po prostu niedostępny. Mogłem zgadnąć, co zawiera, i mieć „gotowe”. Zamiast tego luka jest wpisana do rejestru z opisem, czego brakuje, które wymagania od niej zależą i co trzeba sprawdzić przed wdrożeniem.
Gdzie to boli
Najdroższa lekcja: weryfikacja kosztuje więcej niż generowanie. Agent wyprodukuje sto stron w godzinę. Sprawdzenie, czy te sto stron zgadza się z ustawą, procesem i intencją biznesową, zajmuje dni albo tygodnie. To nie jest wada metody, tylko nowa ekonomia projektu: produkcja tanieje, wartość przenosi się do selekcji źródeł i kontroli jakości. Kto pomija ten etap, dostaje bardzo elegancko opisane błędy.
Druga lekcja jest mniej oczywista. Zakaz zgadywania nie może być prośbą w stylu „nie wymyślaj”. Musi być mechanizmem. U mnie działa to tak, że agent, któremu brakuje danych, ma obowiązek dopisać lukę do rejestru, a wymagania powiązanego z luką nie wolno oznaczyć jako sprawdzonego, dopóki luka wisi. Bez takiego mechanizmu każdy raport wygląda na skończony, a połowa z niego jest zgadywana.
Nie spodziewałem się za to, że uczciwy status dokumentu stanie się przewagą. „Szkic z luką” brzmi gorzej niż „gotowe”. Ale ludzie, którzy mają z tego materiału korzystać, ufają mu bardziej, bo wiedzą, gdzie są granice.
Model kupisz. Pytań nie.
Skąd w ogóle wiedziałem, które przepisy dotykają systemu kasowego w aptece? Przykład. W Polsce apteka nie może się reklamować. Zwykła funkcja rabatowa albo moduł wiadomości do klienta, standard w każdym sklepie, w aptece potrafi być naruszeniem prawa. Agent sam z siebie tego nie wie i żaden model tego nie wie. Ja wiem, bo jestem farmaceutą, od 2000 roku prowadzę własną aptekę, a wcześniej zarządzałem sieciami od 120 do 3800 placówek.
Dostęp do coraz lepszych modeli będzie się upowszechniał i dla wszystkich będą one takie same. Różnicę zrobi ten, kto wie, jakie pytania zadać, zanim maszyna zacznie odpowiadać.
