Zbudowałem agenta AI, który naprawia błędy w nocy. Oto jak działa Agent Yoda

Jestem w fireup.pro od trzech miesięcy. Połowę tego czasu poświęciłem na zbudowanie systemu, który dziś automatyzuje część mojej codziennej pracy developerskiej.

Czym jest agent Yoda i dlaczego go zbudowałem?

Agent Yoda zamienia alert o błędzie na produkcji w gotową propozycję poprawki. Czyta logi, ustala przyczynę, pisze test odtwarzający błąd, naprawia kod i otwiera pull request w wersji roboczej, do przejrzenia przez człowieka.

Zbudowałem go, bo triażowanie bugów pochłania nieproporcjonalnie dużo czasu deweloperskiego w stosunku do wartości, którą wytwarza. To nie jest praca nad featurami, tylko maintenance. Według raportu Stripe Developer Coefficient  developerzy spędzają około 33% czasu pracy na obsłudze długu technicznego, zamiast tworzyć nowe funkcje. A maintenance, z definicji, chcesz prowadzić przy jak najniższym koszcie czasu, skupienia i pieniędzy.

Zakład, który postawiliśmy: jeśli AI potrafi coraz lepiej pisać kod produkcyjny  to pewnie poradzi sobie z dużą częścią bugów w dobrze zorganizowanym repozytorium.

Cztery tygodnie na produkcji  – zakład trzyma.

Znasz to?

Każdy developer zna ten rytuał. Przychodzisz rano, sprawdzasz Slacka, widzisz alert z Grafany sprzed nocy. Siadasz, czytasz logi, odtwarzasz błąd, piszesz fix, otwierasz PR, czekasz na CI, prosisz o review. I tak w kółko. To nie jest trudna praca, tylko wolna praca, która blokuje właściwą – trudną pracę.

Dokładnie ten problem miał rozwiązać Agent Yoda.

Przez półtora miesiąca budowałem go na naszym wewnętrznym produkcie FinPilot. Agent wykrywa błędy produkcyjne, analizuje logi, pisze fix i otwiera draft pull request. Żadnego człowieka w pętli,  aż do etapu review.

Oto co robi, jak jest zbudowany i czego nauczyłem się przy okazji.

Pięcioetapowa architektura: od alertu do draft PR

Agent Yoda przechodzi przez pięć kolejnych faz za każdym razem, gdy podejmuje nowy błąd. Zasada projektowa, którą przyjąłem od początku: minimalny footprint. Agent powinien robić tylko tyle, ile potrzeba, żeby dobrze wykonać zadanie.

Faza 1: Analiza (tylko odczyt)

Gdy Grafana odpali alert, n8n go przechwytuje, porządkuje treść i dokłada zgłoszenie do własnej listy zadań, a logi z incydentu odkłada w magazynie plików w AWS. Agent pobiera je stamtąd i, jeśli to nie wystarcza, sam dopytuje monitoring o dodatkowe logi. Określa, jak rozległy jest błąd. Repozytorium, w którym trzeba szukać, dostaje z n8n – wynika z tego, który serwis zgłosił alert. Ta faza, podobnie jak następna, jest ściśle tylko do odczytu. Zero zapisów, zero efektów ubocznych.

Faza 2: Planowanie (tylko odczyt)

Na podstawie analizy Agent Yoda buduje plan naprawy. Decyduje, co trzeba zmienić, gdzie i jak. Plan jest wejściem fazy naprawy. Gdy planowanie się nie uda, naprawa pracuje z samej analizy i sama ustala minimalny zakres zmiany.

Dwie fazy tylko do odczytu zanim cokolwiek zostanie zapisane są celowe. Utrzymuje agenta bezpiecznym i audytowalnym. Możesz sprawdzić, co zrozumiał o błędzie, zanim dotknął kodu.

Faza 3: Fix

Faza naprawy wykonuje zmiany zgodnie z planem. Kopia repozytorium powstaje wcześniej, razem z kontenerem, jeszcze przed analizą. Sama naprawa zaczyna się od testu: Agent Yoda najpierw pisze test, który odtwarza błąd i musi być czerwony, a dopiero potem poprawia kod, aż test przechodzi.

Zanim cokolwiek dotrze do modelu, z logów incydentu usuwane są dane osobowe.

Agent Yoda ma dostęp wyłącznie do repozytoriów z jawnej allow-listy, jeśli błąd pochodzi z serwisu spoza listy, run jest odrzucany, a na Slacka idzie informacja dlaczego. Pierwsza bramka jest jeszcze wcześniej: zgłoszenie z repozytorium poza listą w ogóle nie dojdzie do agenta.

Faza 4: Weryfikacja

Agent sam, u siebie w kontenerze, uruchamia jeszcze raz pakiet testów repozytorium i tym pomiarem nadpisuje to, co model twierdził o testach. Jeśli jedno nie zgadza się z drugim, run to odnotowuje. Osobno, już na otwartym draft PR, odpala się normalne CI projektu – to bramka dla człowieka, nie dla agenta. Agent nic nie merguje i nie może: PR zostaje w drafcie.

Faza 5: Review

Agent Yoda robi przegląd własnych zmian przed przekazaniem PR-ki do oceny człowieka. Drobne, mechaniczne uwagi na przykład formatowanie czy ostrzeżenie od lintera poprawia sam, osobnym commitem, i po tej poprawce jeszcze raz uruchamia testy. Poważniejsze wątpliwości, na przykład co do zakresu zmiany, zapisuje w komentarzu do PR. Niczego nie ukrywa. Niezależny przegląd robi człowiek.

Warstwa orkiestracji: n8n, AWS Fargate i Slack

Agent Yoda działa na trzech komponentach infrastrukturalnych:

n8n jest orkiestratorem. Obsługuje cztery workflowy: trigger (dziś Grafana, Jira w trakcie developmentu), dispatcher (co pięć minut sprawdza, czy jest wolne miejsce, i sam uruchamia kontener w AWS przy okazji sprząta runy, które utknęły po trzech godzinach oznacza je jako porzucone i zwalnia miejsce) oraz after-run reporter (który wysyła powiadomienia na Slacku ze statusem i linkiem do PR).

Naraz mogą działać maksymalnie dwa runy.

AWS Fargate dostarcza efemeryczne kontenery: gdy przychodzi zadanie, kontener się odpala, robi robotę i znika. Sam Agent Yoda nie ma więc żadnego serwera, dostaje jeden procesor i dwa gigabajty pamięci na jeden incydent, z twardym limitem trzech godzin. Infrastruktura wokół, między innymi serwer z n8n, stoi na tanich instancjach spot. Koszt samych kontenerów jest pomijalny, prawdziwym kosztem runu są zapytania do modelu (o tym niżej).

Slack utrzymuje człowieka w pętli bez konieczności aktywnego monitorowania. Agent Yoda wysyła wiadomość, gdy podejmuje buga, gdy wchodzi w każdą fazę i gdy PR jest gotowy. Możesz obserwować run krokowo albo zignorować wszystko do ostatniego powiadomienia.

Deduplikacja, kolejkowanie i kill switch

3 funkcje warte wyróżnienia, bo mają znaczenie na produkcji:

Deduplikacja. n8n wyciąga sygnaturę alertu, hashuje ją i sprawdza duplikat jeszcze przed uruchomieniem agenta. Jedna sygnatura opisuje cały alert, nie każdy błąd w nim osobno. Jeśli ten sam alert wróci – niezależnie od tego, na jakim etapie jest poprzednie zgłoszenie – n8n podbija licznik wystąpień i dokleja komentarz do istniejącego ticketu w Jirze. Bez nowego ticketu i bez nowego runu.

Kolejkowanie. Dispatcher sprawdza dostępne sloty co pięć minut. Jeśli wszystkie są zajęte, bo poprzednie taski wciąż działają, nowe czekają. To mechanizm kontroli kosztów równie ważny jak mechanizm bezpieczeństwa. Nie chcesz, żeby storm błędów generował nieograniczoną liczbę kontenerów Fargate.

Kill switch. Wyłączenie workflowu w n8n natychmiast zatrzymuje agenta od tworzenia nowych tasków. Żadnej skomplikowanej procedury shutdown, żadnego stanu do czyszczenia. Po prostu przestaje.

Realny incydent produkcyjny

Pierwszy prawdziwy incydent przyszedł dzień po uruchomieniu na produkcji.

Dzień później, 17 lipca, serwisowi skończyły się wolne połączenia do bazy danych. Agent Yoda przeczytał logi, ustalił przyczynę, napisał test odtwarzający problem, naprawił kod, uruchomił testy zielone  i otworzył draft pull request. Ticket w Jirze sam przeszedł do kolumny „In Review”. Cały run: 21 minut i około 2,75 dolara.

Ten sam incydent pokazał też granicę. Gdy alert rośnie w czasie, bo dochodzą kolejne komunikaty o błędach, Agent Yoda widzi go jako inny alert i potrafi otworzyć dwa tickety na jedną przyczynę. Wiemy o tym i to naprawiamy.

Czego agent nie potrafi i dlaczego to jest feature, nie bug

Agent Yoda nie deployuje. Nie merguje PR-ek. Do bazy danych domyślnie w ogóle się nie łączy. Jeśli dostanie dostęp, to tylko do bazy tego jednego środowiska, którego dotyczy błąd, i tylko do czytania – pilnuje tego sama baza, nie ustawienie w agencie. Brak wskazanego środowiska oznacza brak dostępu do bazy. Pracuje wyłącznie w trybie draft.

To nie jest ograniczenie, które planuję usunąć. Human-in-the-loop to zasada projektowa, nie placeholder. Moim celem było wyeliminowanie pracy dochodzeniowej i wstępnej tej, która zjada najwięcej czasu bez wytwarzania wartości biznesowej przy jednoczesnym zachowaniu ludzkiego osądu tam, gdzie naprawdę ma znaczenie: przy decyzji, czy proponowana zmiana trafia na produkcję.

Model kosztowy i dobór modeli

Agent Yoda działa na API Anthropica z dedykowanym kluczem API, oddzielonym od użycia całego zespołu. To daje czystą atrybucję kosztów per run.

Trzy fazy: analiza, planowanie i przegląd działają na modelu Claude Sonnet 4.6. Najdroższa faza, czyli sama naprawa kodu, na Claude Opus 4.8. Haiku, czyli najtańszy i najszybszy model, sprawdziliśmy i odrzuciliśmy: zamiast dojść do wniosku, kręcił się w kółko po narzędziach. Każda faza ma dodatkowo limit liczby kroków, żeby żaden run nie mógł się zapętlić.

Koszt jest mierzony co do fazy: każda zapisuje, ile tokenów zużyła, ile kosztowała i jak długo trwała. Wszystko widać na dashboardzie w Grafanie. Zmierzone pełne runy to około 2,75–3,59 dolara i 20–30 minut, czyli wyraźnie mniej niż godzina pracy developera. Czego jeszcze nie mam, to sensownego kosztu miesięcznego: system jest młody, a FinPilot nie generuje tyle błędów, żeby naprężyć ekonomię.

Co budujemy dalej?

Dwa kierunki są w toku:

Ścieżka Jira-triggered. Zamiast reagować na alerty Grafany, Agent Yoda podejmuje tickety przypisane przez developera i przez nie przechodzi. To rozszerza model z reaktywnego naprawiania bugów na proaktywne wsparcie developmentu.

Automatyczny code review. W miarę jak kod generowany przez AI staje się coraz bardziej powszechny w repozytorium (pisaliśmy już o tym, jak podejść do review kodu wytwarzanego przez agentów: https://fireup.pro/pl/blog/przeglad-kodu-generowanego-przez-ai), bottleneck przy review narasta. Dedykowany agent code review, odpalający się na każdym PR niezależnie od tego, czy kod napisał człowiek czy inny agent, to logiczny następny krok.

Architektura to wspiera. Dodanie nowego workflowu to kwestia napisania folderu z promptami i skonfigurowania workflow w n8n. Harness jest modularny z założenia.

🚀 Jeśli myślisz o budowaniu czegoś podobnego dla swojego zespołu albo oceniasz, czy agentowe narzędzia mają sens dla Twojego produktu  chętnie porozmawiamy o tym, czego się nauczyliśmy. Regularnie piszemy też o tym, jak organizujemy pracę inżynieryjną w fireup.pro i jak wygląda budowanie oprogramowania w regulowanych branżach 👉 czytaj bloga!