05 · Rozwinięcie
Mierzymy.Cztery liczby pracy z agentami AI
O pracy z AI łatwo mieć zdanie i trudno mieć dane. My zbieramy cztery liczby od pierwszego zadania. Są proste, nie wymagają nowych narzędzi i po kilku tygodniach mówią więcej niż jakakolwiek dyskusja.
Dlaczego mierzymy
Obaj mogą mieć rację, bo pracują na innych zadaniach i inaczej je opisują. Liczby pokazują, gdzie naprawdę leży różnica, i co poprawić.
Mierzenie ma jeszcze jeden skutek: zespół zaczyna świadomie przygotowywać zadania, bo widzi, jak to wpływa na wynik. Sama obserwacja poprawia proces.
Cztery liczby
Najszybciej reaguje
Poprawki po pierwszym podejściu
Ile razy trzeba było wrócić do agenta z uwagą, zanim zmiana nadawała się do scalenia. Zero znaczy, że opis i kontekst były kompletne. Trzy i więcej znaczy, że czegoś zabrakło na wejściu.
Dopisaliście jedno zdanie o konwencji nazw i poprawek jest mniej? Znaczy, że to zdanie było potrzebne. Liczymy ją na każdym pull requeście, ręcznie albo z komentarzy.
Spada najszybciej
Czas od opisu do wdrożenia
Od chwili, gdy opis zadania jest gotowy, do scalenia z główną gałęzią. Wliczamy czas pracy agenta, czas oczekiwania na odbiór i poprawki.
Nie wliczamy czasu pisania opisu, bo ten mierzymy osobno: jeśli rośnie, znaczy, że zadania są za duże.
Widać w rachunku
Koszt na funkcję
Ile tokenów, a więc ile pieniędzy, poszło na jedną funkcję od opisu do scalenia, razem z poprawkami. Większość narzędzi pokazuje zużycie na sesję, wystarczy je zapisać przy zadaniu.
Koszt rośnie, gdy agent błądzi: czyta za dużo plików, próbuje wielu podejść, poprawia się w kółko. To zwykle sygnał, że kontekst nie prowadzi go do właściwego miejsca w kodzie.
Pilnuje pozostałych
Błędy po scaleniu
Ile zgłoszeń wróciło do zmiany po tym, jak trafiła do głównej gałęzi. Liczymy je przez kilka tygodni od scalenia i przypisujemy do konkretnego pull requestu.
Można mieć zero poprawek, krótki czas i niski koszt, bo nikt nie czyta kodu. Błędy po scaleniu pokażą to po miesiącu. Dlatego porównujemy je z tym, jak było przed agentami.
Jak zbieramy dane
Bez nowych systemów. Etykieta na pull requeście z liczbą poprawek, daty utworzenia i scalenia, koszt zapisany w opisie zadania, zgłoszenia błędów powiązane z pull requestem. Raz w tygodniu jedna osoba spina to w arkusz. Zajmuje to kwadrans.
Gdy zespół ma już kilkadziesiąt zadań w arkuszu, warto to zautomatyzować. Wcześniej nie, bo ręczne zbieranie zmusza do patrzenia na dane, a o to chodzi.
Co robimy z wynikami
- Dużo poprawek na tym samym typie zadań: uzupełniamy kontekst albo dopisujemy umiejętność.
- Rosnący czas pisania opisów: dzielimy zadania inaczej, zwykle na mniejsze.
- Wysoki koszt na prostych zadaniach: tańszy model albo lepsze wskazanie miejsca w kodzie.
- Błędy po scaleniu: zmiana zasad odbioru, częściej testy przed oddaniem zadania.
Każda zmiana w procesie to hipoteza, którą sprawdzamy na kolejnych zadaniach. Po kilku tygodniach zespół ma własne, udokumentowane zasady, a nie cudze dobre rady.
Czego nie mierzymy
- Linii kodu
- Liczby promptów
- Procentu kodu „napisanego przez AI”
Co liczy się naprawdę
- Ile trwa
- Ile kosztuje
- Ile wraca
Te pierwsze łatwo policzyć i nic z nich nie wynika. Więcej kodu to nie więcej wartości, a więcej promptów to nie więcej pracy. Interesuje nas tylko to, co widzi firma.