Masz aplikację napisaną z pomocą AI i zastanawiasz się, kto odpowiada za kolejne zmiany? W Awakast część tej pracy wykonują agenci AI działający na Hermes Agent — agencie open source od Nous Research. Simon pisze kod, Eryk sprawdza go w code review, a programista z zespołu decyduje, czy gotowy etap trafia dalej. Poniżej pokazujemy to na jednej prawdziwej zmianie: Eryk cztery razy odesłał ją do poprawy, a do gałęzi etapu trafiła po nieco ponad dwóch godzinach.
Jak każdy w zespole, Simon i Eryk mają firmowe maile, konta w narzędziach i własne uprawnienia, a w code review potrafią się spierać. Kiedy nie mogą się dogadać, wołają Kaspra, założyciela Awakast.
Obaj są agentami AI.
Nie zastąpiliśmy nimi programistów. Włączyliśmy ich do zespołu, w którym wiadomo, kto wykonuje zadanie, kto je sprawdza i kto podejmuje ostateczną decyzję. Dla foundera to różnica między „AI coś dopisało” a zmianą, którą ktoś może przyjąć albo odrzucić. Dla CTO — możliwość prześledzenia, jak ta zmiana powstała.
Dlaczego agenci dostali konta zamiast kolejnego okna czatu
Nie wymyślaliśmy osobnego procesu tylko dlatego, że część pracy wykonuje AI. Agenci dostali to, co dostaje nowy programista: konto, zakres uprawnień, tablicę z zadaniami i osobę, do której można się zwrócić, gdy sprawa utknie.
Zadania są w YouTracku — tablicy z zadaniami, podobnej do Jiry. Kod i rozmowy o zmianach są w Gitea, czyli naszym własnym odpowiedniku GitHuba. Nie trzeba znać tych narzędzi, żeby zrozumieć zasadę: zadanie, wykonanie i ocena mają swoje miejsce, zamiast ginąć w historii rozmowy z chatbotem.
To ważne również dla osoby, która zamawia aplikację. „Zrobione” może znaczyć, że agent skończył pisać, że drugi agent zaakceptował zmianę albo że programista ją przetestował. U nas to trzy osobne momenty i decyzji o przyjęciu etapu nie zostawiamy samym agentom.
A konfiguracja? Nikt nie ustawiał Hermesa ręcznie. Wystarczyło powiedzieć innemu AI, że Hermes jest zainstalowany, i Hermes skonfigurował się sam.
Kto jest kim: Hermes Agent w dwóch rolach
Simon jest developerem. Eryk jest reviewerem, czyli sprawdza proponowane zmiany. To role z różnymi uprawnieniami, a nie dwa imiona dla tego samego wykonawcy.
Simon może napisać kod i zgłosić go do oceny. Eryk nie może pisać kodu. Może go ocenić, poprosić o poprawki, a po akceptacji połączyć zmianę z gałęzią etapu — osobną wersją kodu przeznaczoną na dany etap prac.
Kasper rozstrzyga spory, których agenci nie potrafią zamknąć. Nie zastępuje to odbioru pracy przez programistę z zespołu: to on sprawdza gotowy etap, testuje go i decyduje o przeniesieniu do wspólnej gałęzi rozwojowej aplikacji.
Jedno zadanie: od tablicy do sprawdzonego etapu
Pracę zaczyna programista z zespołu. Wybiera etap, na którym mają pracować agenci, i zakłada dla niego gałąź etapu.
- Simon bierze dostępne zadanie. Gdy nie pracuje nad niczym innym, sam wybiera kolejne zadanie z YouTracka — tylko takie, które można już zacząć.
- Simon pisze kod na własnej gałęzi i otwiera pull request: propozycję zmiany, którą druga strona może obejrzeć i skomentować.
- Eryk zaczyna review automatycznie, gdy tylko pojawi się pull request. Zostawia komentarze, Simon odpowiada i poprawia. Rozmowa toczy się przy konkretnej zmianie, nie w czacie, którego trzeba potem szukać.
- Spór bez rozstrzygnięcia trafia do Kaspra. Jeśli po pięciu rundach nie ma porozumienia, agenci wołają go na Slacku.
- Eryk łączy zmianę z gałęzią etapu, a Simon aktualizuje status zadania.
- Programista odbiera etap. Robi własne review i testy, a potem decyduje, czy etap trafi do dev, czyli wspólnej gałęzi rozwojowej. Akceptacja Eryka nie zastępuje tej decyzji — i z perspektywy klienta właśnie ten punkt ma największe znaczenie.
Jak to wygląda na prawdziwej zmianie
Przykład z naszego własnego produktu rekrutacyjnego. Zadanie: nowy widok wyników wyszukiwania i karty kandydata, w którym rekruter widzi, na jakiej podstawie kandydat znalazł się na liście, może dopisać notatkę i poprawić dane kontaktowe.
Pierwsza wersja powstała 26 października o 22:57. Eryk cztery razy odesłał ją do poprawy, w pull requeście zebrało się 11 komentarzy, a za piątym razem zmiana została zaakceptowana. Między pierwszą wersją a połączeniem zmiany Simon wprowadził pięć poprawek:
- Mniej objaśnień. Tego wieczoru do naszych zasad projektowych doszła reguła: interfejs ma być zrozumiały bez tekstów objaśniających. Simon zastosował ją w swoim widoku i usunął zdanie z objaśnieniem pod tytułem oraz dymek z podpowiedzią.
- Dwie zmiany zapisane naraz. Gdy rekruter jednocześnie zapisywał notatkę i poprawiał dane kandydata, zapis, który kończył się później, mógł nadpisać drugą zmianę. Po poprawce obie zostają, a test sprawdza obie kolejności.
- Filtry, które mówią prawdę. Podsumowanie wyszukiwania pokazywało słowa kluczowe jako zastosowane także wtedy, gdy ten filtr był wyłączony. Teraz widać je tylko wtedy, gdy faktycznie działają.
- Szkic, który nie znika. Wpisany, ale jeszcze niezapisany adres kontaktowy przepadał, gdy rekruter zapisał niezwiązaną notatkę. Po poprawce zostaje, a rekruter może go potem zapisać, ponowić zapis po błędzie albo anulować i wrócić do zapisanego adresu.
- Teksty w czterech językach. Po połączeniu zmian jeden zestaw napisów interfejsu nadpisywał drugi. Teraz oba działają we wszystkich czterech wersjach językowych, a sprawdza to test.
Zmiana trafiła do gałęzi etapu 27 października o 1:06 — nieco ponad dwie godziny po pierwszej wersji, w nocy, bez czekania na kogokolwiek. Reguła eskalacji się nie uruchomiła: cztery rundy mieszczą się w limicie pięciu.
Trzy z tych pięciu poprawek usuwają błędy, których demo nie pokaże: wychodzą dopiero wtedy, gdy prawdziwy rekruter zapisuje dwie rzeczy naraz albo wyłącza filtr. Wszystkie naprawiono jeszcze w review agentów, zanim etap trafi do programisty.
Co dają osobne konta i uprawnienia
Osobne konta pozwalają prześledzić w Gitea, kto zgłosił zmianę, kto ją oceniał i kto ją przyjął. Kiedy zapytasz, skąd coś wzięło się w kodzie, wskażemy konkretne konto i komentarz, które za tym stoją.
Reviewer bez prawa pisania kodu i człowiek jako jedyna droga do dev to ta sama zasada najmniejszych uprawnień, którą stosuje się wobec ludzi: każdy może wykonać swoją część pracy, a nie wszystkie kolejne kroki.
Gdzie współpraca wymagała docierania
Agenci potrafią przekombinować proste rozwiązanie. Prośba o drobną poprawkę może skończyć się propozycją przebudowy architektury — z uzasadnieniem, które też trzeba przeczytać.
Drugi problem to rozwlekłość. Komentarz w review potrafi być dłuższy niż zmiana, której dotyczy. Trzeba oddzielić uwagę, która naprawdę wpływa na kod, od rozważań, które nie pomagają zamknąć zadania.
Musieliśmy dopracować instrukcje i nauczyć się pracy w takim składzie. Część docierania dotyczyła samych agentów, a część tego, jak my przygotowujemy dla nich zadania i oceniamy wynik. Najważniejsza lekcja: oddzielić zadanie „wykonaj tę zmianę” od decyzji „czy ta zmiana jest nam potrzebna”. Simon sam bierze zadanie z kolejki, ale nie wyznacza kierunku produktu.
Co to zmienia, gdy przynosisz aplikację napisaną z pomocą AI
Działające MVP jest początkiem rozmowy, nie powodem, żeby budować wszystko od nowa. Potrzebna jest decyzja, co zachować, co poprawić i kto odpowiada za dalszy rozwój.
W Awakast tę pracę wykonują doświadczeni programiści wspierani przez agentów. Agenci wykonują zadania i sprawdzają nawzajem swoją pracę, a ludzie wybierają etap, odbierają wynik i podejmują decyzje ważne dla produktu i biznesu.
Jeśli masz dopiero pomysł, pierwsza rozmowa dotyczy tego, co produkt ma zmienić w Twoim biznesie. Jeśli masz już aplikację, zaczynamy od tego, co działa i gdzie pojawiają się problemy — tak sprawdzamy, czy aplikacja napisana z pomocą AI jest gotowa do wdrożenia. W obu przypadkach nie musisz umieć czytać pull requestów.
Jest jakiś powód, żeby nie sprawdzić, jak my byśmy to zrobili? Pokaż nam, co już masz albo opowiedz nam o swoim pomyśle. Po kilku zdaniach dowiesz się, jak byśmy się do tego zabrali.