Błąd na produkcji wraca do zespołu jako gotowa poprawka, nie jako zgłoszenie

Kto to był i co go bolało

To nasz własny produkt, zbudowany dla siebie i używany codziennie. Wyszedł z prostej obserwacji: znaczna część awarii, które lądują na produkcji, to nie są ciekawe problemy. To drobiazgi. Zewnętrzna usługa zmienia format odpowiedzi, strona, z której pobieramy dane, przestawia układ, jakiś warunek brzegowy przestaje się zgadzać. Naprawa zajmuje kilkanaście minut, ale zanim się do niej siądzie, trzeba przeczytać zgłoszenie, odtworzyć sytuację, znaleźć miejsce w kodzie i przypomnieć sobie kontekst. Te kilkanaście minut robi się godziną, a takich godzin w tygodniu zbiera się kilka.

Naturalny pomysł, czyli niech model napisze poprawkę sam, ma jedną poważną wadę. Model potrafi napisać poprawkę i do niej dopasowany test, który przechodzi, mimo że pierwotny błąd wcale nie został naprawiony. Sam sobie wystawia świadectwo. Potrzebny był dowód niezależny od tego, kto pisał kod.

Druga sprawa to bezpieczeństwo. Nie każda zmiana może wejść bez człowieka. Poprawka w miejscu, które dotyka płatności albo uprawnień, to zupełnie inna kategoria niż dopasowanie się do zmienionego formatu danych. Trzecia: nie każda awaria da się naprawić kodem. Część to blokady po stronie zewnętrznych usług i wygasłe dostępy. Agent miał je rozpoznawać i milczeć, zamiast produkować zgłoszenia, których nikt nie zamknie.

Co zrobiliśmy

Zbudowaliśmy pętlę, w której naprawa i jej weryfikacja są rozdzielone między dwóch niezależnych agentów, a decyzja o wejściu zmiany należy do reguły, nie do modelu.

Wszystko zaczyna się od zdarzenia. Aplikacja, w której coś padło, wysyła sygnał z diagnozą i odciskiem błędu, dzięki czemu ta sama awaria nie uruchamia procesu dziesięć razy. Pętla działa jako gotowy, wielokrotnego użytku element w GitHub Actions, więc podpięcie kolejnego projektu to kilka linijek konfiguracji, a nie osobne wdrożenie.

Pierwszy agent, oparty o Claude Code, zaczyna od napisania testu odtwarzającego błąd, a dopiero potem pisze możliwie małą poprawkę. Kolejność jest tu istotna: najpierw dowód, że problem istnieje, potem rozwiązanie. Efekt trafia do zwykłej propozycji zmiany, dokładnie takiej, jaką otworzyłby człowiek.

Drugi agent, uruchamiany osobno i bez wiedzy o tym, jak myślał pierwszy, sprawdza jedną rzecz: czy test faktycznie nie przechodzi na starym kodzie i przechodzi na nowym. To jest ten obiektywny dowód, którego brakuje, gdy poprawkę ocenia jej autor.

Na końcu stoi bramka, która nie jest agentem. To zwykła reguła: jeżeli zmiana jest w kategorii niskiego ryzyka, cały zestaw testów świeci na zielono i dowód niezależnej weryfikacji jest na miejscu, poprawka wchodzi sama. W każdym innym przypadku czeka na człowieka. Panel z takimi przypadkami oraz historia całej pętli siedzą w Supabase.

Jak to działa dzisiaj

Pętla jest częścią naszego codziennego procesu. Kiedy coś się psuje, zespół nie dostaje zgłoszenia do rozgrzebania, tylko gotową propozycję zmiany z testem, który udowadnia, że problem faktycznie występował i faktycznie zniknął.

Drobne, powtarzalne awarie znikają bez niczyjego udziału - rano widać po prostu, że wczoraj coś się zepsuło i zostało naprawione. Poprawki oznaczone jako wrażliwe czekają w panelu na decyzję człowieka i to jest jedyna rzecz, którą trzeba zrobić ręcznie. Awarie, których nie da się naprawić kodem, są rozpoznawane i odkładane, zamiast zapychać kolejkę.

Co z tego wyszło

Za naprawę odpowiadają dwa niezależne agenty: jeden pisze, drugi sprawdza. Poprawki niskiego ryzyka wchodzą samodzielnie, ryzykowne czekają na człowieka. Każda zmiana ma twardy dowód w postaci testu, który był czerwony przed poprawką i zielony po niej.

Co zrobilibyśmy inaczej

Pierwsza wersja miała jednego agenta, który pisał poprawkę i sam ją oceniał. Wyglądało to świetnie do momentu, w którym zaczęliśmy sprawdzać, co dokładnie zostało naprawione. Rozdzielenie ról na dwa niezależne przebiegi było jedyną zmianą, która naprawdę rozwiązała problem zmyślonych sukcesów, i powinno być w projekcie od pierwszego dnia.

Niedoszacowaliśmy też, jak duża część zgłoszeń to sprawy nienaprawialne kodem: wygasłe dostępy, blokady po stronie zewnętrznych usług, przerwy w działaniu cudzych systemów. Zanim dołożyliśmy ich rozpoznawanie, pętla generowała szum, przez który przestawało się patrzeć na wyniki. Klasyfikacja przyczyny powinna stać przed agentem naprawiającym, a nie za nim.