Adaptacja AI metodą „na drugiego”

Kupione licencje łatwo policzyć. Zużyte tokeny też. Znacznie trudniej ustalić, czy dzięki nim zespół lepiej rozumie system, szybciej rozwiązuje problemy i rzadziej oddaje klientowi coś, co trzeba za chwilę poprawiać. Dlatego przy rozmowach o wdrażaniu AI interesuje mnie przede wszystkim, co organizacja potrafi zrobić po zakupie narzędzia, czego wcześniej nie potrafiła. Sam dostęp do modelu jeszcze niewiele mówi.

Nie mam też przekonania, że trzeba być pierwszym. Pionier finansuje eksperymenty, również te nieudane. Wchodząc później, można zobaczyć, które zastosowania mają sens, gdzie koszt weryfikacji zjada oszczędność i które obietnice dobrze wyglądały wyłącznie na prezentacji. To rozsądna pozycja, o ile w czasie oczekiwania człowiek czegoś się uczy. W przeciwnym razie zostaje mu obserwowanie, jak inni odjeżdżają.

Bezwładność nie jest jeszcze strategią

Duża organizacja potrafi miesiącami uzgadniać zakup, który mały zespół załatwia jedną decyzją. Bezpieczeństwo, budżet, zakupy, kolejne akceptacje. Zwykle to przeszkadza. Przy technologii, której zastosowania dopiero rozpoznajemy, taki poślizg może jednak oszczędzić kosztownego błędu. Nie wynika z tego, że każda powolna firma właśnie realizuje wyrafinowaną strategię wejścia „na drugiego”. Część po prostu nie umie podjąć decyzji.

Różnicę widać po tym, co dzieje się w międzyczasie. Można prowadzić małe eksperymenty w zatwierdzonym środowisku, na danych, których wolno używać. Sprawdzać konkretne zadania, porównywać czas wykonania razem z poprawkami, zapisywać ograniczenia. Ustalić, kto oceni wynik i po czym poznamy, że warto rozszerzyć zastosowanie. Do tego nie jest potrzebna wielka transformacja całej organizacji.

Wyniki cudzych wdrożeń pomagają wybrać kierunek, ale nie załatwią sprawdzenia własnego systemu. Narzędzie przydatne przy tworzeniu nowej aplikacji może znacznie gorzej radzić sobie z kilkunastoletnim kodem i wyjątkami znanymi trzem osobom. Prezentacja dostawcy nie odpowie też na pytanie, ile czasu nasz zespół poświęci na przegląd wygenerowanych zmian.

Strategia „na drugiego” powinna więc mieć warunki wejścia i termin ponownej oceny. Bez nich łatwo zamienić ostrożność w wygodne alibi. Zawsze znajdzie się następny model, na który warto poczekać, i kolejny raport, który trzeba przeczytać przed decyzją.

Od zachwytu do kodu, który trzeba utrzymać

Stosunek programisty do AI może się kilka razy zmienić. Ktoś zaczyna od nieufności, bo widzi błędne odpowiedzi i nie chce po nich sprzątać. Potem znajduje zastosowanie, które rzeczywiście oszczędza mu pracę. W końcu próbuje oddać modelowi większe zadanie i przekonuje się, ile kosztuje sprawdzenie całości. Nie każdy przechodzi tę drogę w tej samej kolejności. Można też rozsądnie używać narzędzia od początku, bez etapu nawrócenia i późniejszego rozczarowania.

Pokusa jest jednak zrozumiała. Skoro w krótkim czasie powstaje działający prototyp, chce się zrobić następny krok. Dopisać integrację, przebudować moduł, od razu wygenerować testy. Dopiero później trzeba rozstrzygnąć, czy testy sprawdzają wymagania, czy tylko potwierdzają założenia przyjęte podczas generowania kodu. Zielony wynik nie odpowie na to za nas.

Przy utrzymaniu wychodzą rzeczy, których nie było w poleceniu. Nietypowe dane, zależność od innego systemu, ograniczenie wydajności, powód, dla którego poprzedni autor zrobił coś pozornie bez sensu. Model może pomóc je rozpoznać. Nie bierze jednak dyżuru po wdrożeniu i nie odpowiada za skutki decyzji, którą zaakceptowaliśmy.

Do tego potrzebny jest własny osąd. Podobny problem opisywałem przy redagowaniu tekstów z pomocą AI: łatwo otrzymać przekonujący materiał, trudniej ocenić, co zasługuje na zachowanie. W kodzie koszt pomyłki bywa po prostu mniej widoczny w chwili odbioru. Funkcja działa na pokazanych przykładach, więc można mieć poczucie, że temat jest zamknięty.

Skąd weźmiemy następnych seniorów

Bardziej od wyboru modelu interesuje mnie jednak to, jak będziemy rozwijać ludzi, którzy mają oceniać jego pracę. Senior nie powstaje przez samo odczekanie odpowiedniej liczby lat. Musi zetknąć się z problemami, nauczyć się odróżniać przyczynę od objawu i zobaczyć konsekwencje własnych decyzji. Część tej nauki wymaga czasu, którego nie da się odzyskać samym wygenerowaniem poprawnej odpowiedzi.

W biurze wiedza mogła przechodzić przy okazji. Junior słyszał, jak senior klnie nad błędem, odrzuca kolejną hipotezę i tłumaczy komuś, dlaczego pozornie prosta poprawka jest ryzykowna. Obserwował negocjowanie wymagań, rozmowę po awarii, spór o rozwiązanie. Dostawał dostęp do rozumowania, którego w gotowym kodzie już nie widać.

Nie idealizuję tego modelu. Można siedzieć obok świetnego specjalisty i niczego się od niego nie nauczyć, jeśli ten nie ma czasu albo ochoty tłumaczyć. Zespół zdalny może przekazywać wiedzę znacznie lepiej od zespołu siedzącego w jednym pokoju. Tyle że przypadkowego kontaktu jest w nim mniej i trzeba świadomie zorganizować to, co wcześniej czasem wydarzało się samo.

AI dokłada następny powód, żeby nie pytać kolegi. Odpowiedź przychodzi natychmiast, można dopytywać bez skrępowania, nikt nie wzdycha, że znowu tłumaczy podstawy. To ogromna zaleta dla uczącego się człowieka. Ten sam mechanizm pozwala jednak ominąć naukę: wkleić poprawkę, zobaczyć, że działa, i przejść do kolejnego zgłoszenia. Różnica zależy między innymi od tego, czy zespół wymaga zrozumienia, czy rozlicza wyłącznie zamknięte zadania.

Nie potrafię na podstawie samej liczby dostarczonych zmian stwierdzić, z którym przypadkiem mam do czynienia. Chcę zobaczyć, czy autor wyjaśni przyjęte założenia, rozpozna ograniczenia rozwiązania i poradzi sobie, kiedy zmienimy warunki. Powtórzenie wyjaśnienia z czatu jest łatwe. Zastosowanie go do innego przypadku mówi już więcej.

Przekazywanie wiedzy trzeba zaplanować w pracy

Jeżeli firma utrzymuje ważny system dzięki kilku osobom, szybsze pisanie kodu przez resztę zespołu nie musi zmniejszać tej zależności. Może nawet zwiększyć kolejkę zmian do sprawdzenia przez tych samych ekspertów. To kolejny wariant uzależnienia organizacji od niezastępowalnych specjalistów. Produkcja przyspiesza, a zdolność oceny nadal mieści się w kalendarzu jednej osoby.

Dlatego przy przeglądzie zmiany chciałbym czasem usłyszeć, jakie inne rozwiązanie autor rozważał i dlaczego je odrzucił. Przy analizie awarii młodszy członek zespołu powinien mieć możliwość zaproponowania hipotezy, wskazania danych do sprawdzenia i zobaczenia, gdzie się pomylił. Senior może go przez to przeprowadzić. Jeśli od razu poda wynik, będzie szybciej, ale kolejny podobny problem znowu trafi do seniora.

Wspólna praca ma sens także wtedy, gdy obie osoby korzystają z AI. Można porównać odpowiedzi modelu z zachowaniem systemu, szukać brakującego warunku, sprawdzić, dlaczego zaproponowany test niczego nie wykrywa. Nie ma powodu robić z ręcznego pisania każdej linijki rytuału inicjacyjnego. Potrzebujemy ludzi umiejących sprawdzić rozwiązanie, a nie ludzi, którzy potrafią udowodnić, że wystarczająco się przy nim namęczyli.

To wymaga czasu w planie zespołu. Manager, który wymaga mentoringu, a później pyta seniora, dlaczego dostarczył mniej własnych zadań, sam podcina tę pracę. Podobnie działa nagradzanie juniora wyłącznie za tempo. Jeśli wyjaśnienie decyzji jest traktowane jak zbędne opóźnienie, trudno oczekiwać, że ludzie będą się przy nim zatrzymywać.

Po czym poznam, że wdrożenie miało sens

Chciałbym po roku zobaczyć, że więcej osób potrafi samodzielnie przeprowadzić zmianę i ocenić jej ryzyko. Że mniej spraw musi czekać na jednego eksperta. Że młodsi pracownicy rozumieją obszary, przy których pracują, a czas zaoszczędzony przy pisaniu kodu nie wrócił w postaci poprawek i trudniejszych przeglądów. Takie efekty trzeba oceniać na konkretnych zadaniach, z uwzględnieniem ich trudności. Sam licznik aktywnych kont niczego tu nie rozstrzygnie.

Samodzielność nie oznacza przy tym pracy bez narzędzi. Programista może potrzebować dokumentacji, debuggera i modelu. Ważne, żeby potrafił zauważyć, że odpowiedź nie pasuje do problemu, zebrać dowody i zdecydować, co sprawdzić dalej. W przeciwnym razie zależność od podpowiedzi łatwo pomylić z kompetencją.

Wchodzenie „na drugiego” ma dla mnie sens wtedy, gdy ograniczamy koszt nietrafionych zakupów, a jednocześnie przygotowujemy ludzi do rozsądnego używania technologii. Możemy poczekać z dużym wydatkiem. Nie odkładałbym nauki ani sprawdzenia, kto będzie odpowiadał za wyniki. Jeśli przez ten czas zespół nauczy się tylko szybciej oddawać kod, którego nie umie ocenić, trudno będzie uznać to za dobrze wykorzystane opóźnienie.