Od jakiegoś czasu korzystam z agentów AI przy kilku swoich projektach. Najczęściej wyglądało to dość prosto: opisywałem zadanie, pozwalałem agentowi nad nim pracować, przeglądałem zmiany i decydowałem, co dalej.
Przy zadaniach z jasno określonym rezultatem sprawdzało się to całkiem dobrze.
Zacząłem się jednak zastanawiać, jak dużo mogę bezpiecznie przekazać agentowi. Nie tylko samo pisanie kodu, ale również sprawdzanie efektów, znajdowanie problemów i decydowanie, czy warto spróbować niewielkiej poprawki.
Mała gra logiczna okazała się dobrym miejscem, żeby to sprawdzić.
Zaczęło się od małej gry
One Shot Chaos to niewielka gra oparta na prostym pomyśle: gracz ma jeden strzał, którym próbuje uruchomić reakcję łańcuchową i zniszczyć wystarczająco dużo celów, żeby ukończyć etap.
Ten projekt różnił się trochę od mojej zwykłej pracy z .NET.
Nadal było w nim sporo zwykłego programowania: stan aplikacji, wykrywanie kolizji, walidacja czy testy. Ale o końcowym rezultacie decydowały też rzeczy, które znacznie trudniej sprawdzić automatycznie.
Czy gra daje satysfakcję? Czy ekran jest czytelny? Czy reakcje na działania gracza wyglądają właściwie?
Test mógł sprawdzić, czy pocisk trafił we właściwy cel. Nie potrafił powiedzieć mi, czy samo trafienie daje dobre wrażenie.
Ta różnica stawała się coraz ważniejsza, kiedy zacząłem powierzać agentowi coraz więcej pracy.
Agent musiał zobaczyć efekt swojej pracy
Na początku agent mógł zmieniać grę i uruchamiać techniczne sprawdzenia, ale efekt wizualny nadal musiałem oceniać sam.
Czegoś tutaj brakowało.
Kod mógł działać. Walidacja mogła przechodzić. A mimo to zmiana interfejsu albo animacji mogła wyglądać źle po uruchomieniu gry.
Chciałem sprawdzić, czy agent może obserwować działającą aplikację, zamiast opierać się wyłącznie na kodzie, który właśnie zmienił.
Pierwszy eksperyment był celowo niewielki.
Dodałem możliwość deterministycznego przechwycenia znanego stanu uruchomionej gry. Dla tego samego stanu mogłem uzyskać zrzut ekranu i porównać go między kolejnymi uruchomieniami.
Nie oznaczało to, że agent nagle potrafił oceniać jakość wizualną. Dostał jednak coś konkretnego, co mógł sprawdzić.
Kolejny eksperyment poszedł trochę dalej: znaleźć znany, lokalny problem z wyglądem, wprowadzić poprawkę i ponownie zobaczyć rezultat.
Przy tak małej zmianie nie musiałem już za każdym razem sam uruchamiać gry i sprawdzać efektu.
Trochę więcej odpowiedzialności
Kiedy obserwowanie rezultatu zaczęło działać, spróbowałem pójść krok dalej.
Zamiast za każdym razem dokładnie wskazywać poprawkę, chciałem sprawdzić, czy agent potrafi przyjrzeć się niewielkiemu obszarowi, znaleźć kilka możliwych usprawnień i wybrać jedną małą zmianę do wypróbowania.
Zakres celowo pozostał niewielki.
Agent mógł zbadać lokalny problem z wyglądem, wprowadzić jedną odwracalną zmianę, uruchomić odpowiednie sprawdzenia i porównać rezultat.
Nie mógł przeprojektować gry, zmieniać jej zasad ani uznać, że pozytywny wynik technicznego sprawdzenia oznacza, że efekt wygląda dobrze.
Z czasem proces zaczął wyglądać mniej więcej tak:
Zbadaj
↓
Zaproponuj
↓
Wypróbuj jedną małą zmianę
↓
Obserwuj i sprawdź
↓
Zostaw, popraw albo zrezygnuj
Kolejne eksperymenty rozszerzyły obserwację na różne stany gry, między innymi celowanie, reakcje, postęp i ukończenie etapu.
Dzięki temu agent stawał się bardziej użyteczny, ale jednocześnie coraz wyraźniej widziałem granice jego odpowiedzialności.
Powtarzalny zrzut ekranu pozwalał sprawdzić, czy dwa uruchomienia dały ten sam obraz. Nie mógł powiedzieć mi, czy ten obraz wygląda dobrze ani czy gracz będzie dobrze się bawił.
Takie decyzje nadal wymagały innego rodzaju oceny.
Kiedy kolejne poprawki nie były rozwiązaniem
Osobną lekcję dała mi praca nad wyglądem One Shot Chaos.
Kilka pierwszych eksperymentów poprawiło poszczególne elementy gry. Cele stały się bardziej wyraziste, reakcje dostały dodatkowe efekty, a interfejs stał się bardziej spójny.
Zmiany działały, ale nadal nie byłem zadowolony z całości.
Dalsze poprawianie pojedynczych elementów nie wyglądało na drogę, która pozwoli osiągnąć efekt, do którego dążyłem.
Spróbowałem więc bardziej kompletnego podejścia do jednego reprezentatywnego ekranu. Różnica była znacznie większa, ale rezultat nadal pozostawał dość daleko od poziomu, do którego chciałem się zbliżyć.
Dopiero inny kierunek, wykorzystujący ilustrowane grafiki rastrowe, przyniósł znacznie lepszy efekt.
Najważniejsze nie było jednak to, że agent w końcu znalazł właściwą odpowiedź.
Eksperymenty pomogły mi zauważyć moment, w którym dalsza praca w danym kierunku zaczynała przynosić coraz mniej.
To, że coś udało się poprawnie zaimplementować, nie oznaczało jeszcze, że warto dalej rozwijać ten sam pomysł.
Czasami wartościowym wynikiem eksperymentu była decyzja, żeby go zakończyć.
Co nadal musiałem decydować sam
Wraz z kolejnymi eksperymentami coraz swobodniej przekazywałem agentowi małe fragmenty pracy.
Nie chciałem jednak dawać mu nieograniczonej swobody tylko dlatego, że wcześniej poprawnie wykonał kilka zadań.
Zakres autonomii, na który zapracował, był konkretny.
Mógł obserwować znane stany gry, zbadać lokalny problem, wprowadzić małą i odwracalną poprawkę oraz sprawdzić, czy odpowiednie zachowanie nadal działa.
Jeżeli problem nie był jasny, któreś ze sprawdzeń nie przeszło albo proponowana zmiana wpływała na mechanikę gry lub szerszy kierunek wizualny, agent miał się zatrzymać i zapytać.
Nauczyłem się też rozróżniać różne rodzaje pozytywnych wyników.
Pozytywny wynik technicznej weryfikacji był jednym z nich.
Powtarzalny wynik porównania wizualnego był kolejnym.
Moja ocena tego, jak gra wygląda i jakie daje wrażenie, była jeszcze czymś innym.
Wszystkie były przydatne, ale nie oznaczały tego samego.
Dzięki temu łatwiej było mi zdecydować, co mogę przekazać agentowi w następnej kolejności, bez traktowania każdego udanego zadania jako dowodu, że jest już gotowy na znacznie większą odpowiedzialność.
To nadal eksperyment
One Shot Chaos nadal jest w trakcie tworzenia.
Nie pokazałem, że agent potrafi samodzielnie zaprojektować, zbudować i wydać kompletną grę. Nie wiem też, czy takie samo podejście sprawdziłoby się równie dobrze w innym projekcie.
Zobaczyłem natomiast, że autonomia może rosnąć małymi krokami, których rezultaty da się sprawdzić.
Najpierw agent potrzebował niezawodnego sposobu obserwowania efektów swojej pracy. Później mógł wprowadzić ograniczoną poprawkę i ją sprawdzić. Dopiero wtedy miało sens pozwolić mu wybierać między niewielkimi alternatywami.
Zacząłem myśleć o tym jako o autonomii, na którą agent zapracowuje wynikami, zamiast dostawać ją z góry.
Nie zdjęło to ze mnie odpowiedzialności za rezultat. Zmieniło natomiast to, na czym mogę skupiać część swojej uwagi.
Czasami mogę zostawić agentowi małą, dobrze określoną zmianę, a sam skupić się na decyzjach, których dostępne sprawdzenia nie są w stanie podjąć za mnie.
Nadal uczę się, gdzie powinna przebiegać ta granica.