Jak ocenić kod generowany przez agentów AI – od niepewności do metody

Agent potrafi w jednym zadaniu zmienić kilkanaście plików, dopisać testy i przygotować pull request. Problemem nie jest już samo tempo tworzenia kodu, lecz możliwość rzetelnej oceny zmiany, zanim trafi ona na produkcję. W Inero rozwiązujemy to przez review całego brancha oraz dobór kontroli do konsekwencji potencjalnego błędu.

Sama szybkość nie jest jednak wartością, jeżeli jej efektem staje się AI slop: duża ilość wiarygodnie wyglądającego kodu, który działa w prostym scenariuszu, ale nie uwzględnia kontekstu systemu, reguł biznesowych i skutków błędów.

W Inero nie próbujemy rozwiązać tego problemu przez rezygnację z AI ani przez obciążenie każdej zmiany jednakowo ciężkim procesem. Łączymy możliwości agentów AI z inżynierską kontrolą jakości opartą na ryzyku. Dzięki temu AI rzeczywiście skraca czas realizacji, a uwaga specjalistów trafia tam, gdzie ma największe znaczenie.

Produktywność AI wymaga innego modelu jakości

Kod napisany przez człowieka również zawiera błędy. Nie traktujemy więc pochodzenia kodu jako kryterium dopuszczenia go do produkcji. Sprawdzamy, czy zmiana została zweryfikowana adekwatnie do tego, co może się wydarzyć, gdy okaże się niepoprawna.

To rozróżnienie pozwala wykorzystać przewagę AI bez tworzenia sztucznego wąskiego gardła. Zmiana tekstu, wyglądu lub filtra może przejść szybko, jeżeli build i testy są poprawne, diff jest czytelny, a wdrożenie można łatwo wycofać. Migracja danych, autoryzacja, naliczanie opłat czy automatyczna komunikacja wymagają innego poziomu kontroli. Podobne rozdzielenie szybkiego prototypowania od gotowości produkcyjnej opisujemy w materiale Twoje demo AI działa. Co dalej?.

Naszym punktem odniesienia jest zatem nie liczba wygenerowanych linii ani liczba użytkowników systemu, lecz konsekwencja błędu i możliwość jej odwrócenia.

AI obniża koszt poprawki, ale nie cały koszt błędu

Agent często potrafi naprawić usterkę równie szybko, jak przygotował pierwszą wersję. Sama implementacja poprawki jest jednak tylko częścią kosztu.

Najpierw ktoś musi zauważyć problem i ustalić jego przyczynę. W tym czasie błąd może wpływać na użytkowników, dane lub systemy zewnętrzne. Po wdrożeniu poprawki może pozostać potrzeba odtworzenia danych, skorygowania dokumentów albo wyjaśnienia sytuacji klientowi. AI skraca tworzenie rozwiązania i pomaga w diagnozie, ale nie cofa szkody, która już wystąpiła.

Dlatego podczas planowania kontroli odpowiadamy na kilka praktycznych pytań:

• czy skutek błędu można całkowicie odwrócić;
• czy system zapisuje, usuwa lub przekazuje dane;
• czy zmiana dotyczy pieniędzy, uprawnień albo zobowiązań;
• jak szybko zauważymy nieprawidłowość;
• czy mamy działający rollback i sprawdzoną możliwość odtworzenia danych.

Kilkanaście osób podejmujących decyzje operacyjne na podstawie systemu może wymagać większej ostrożności niż tysiące użytkowników prostej aplikacji informacyjnej. Skala ruchu jest istotna, ale nie zastępuje analizy rzeczywistego wpływu.

Traktujemy agenta jak sprawnego autora bez pełnego kontekstu

Kod z modelu językowego często jest uporządkowany, dobrze nazwany i opatrzony przekonującymi komentarzami. To ułatwia pracę, ale może obniżać czujność recenzenta. Najważniejsze problemy rzadko wyglądają jak oczywiste błędy składni.

Agent może zbyt dosłownie zrealizować polecenie i pominąć regułę biznesową, której nie było w opisie. Może zastosować cichy fallback, który ukryje problem, albo przygotować testy powtarzające to samo błędne założenie co implementacja. Może również rozszerzyć zakres zadania lub odwołać się do nieistniejącej opcji konfiguracji czy biblioteki.

Dlatego nie oceniamy wyłącznie tego, czy kod wygląda poprawnie. Sprawdzamy, czy rozwiązuje właściwy problem, zachowuje istniejące reguły, pasuje do architektury i nie maskuje niepowodzeń. Agent przyspiesza wykonanie pracy, ale odpowiedzialność za rezultat pozostaje po stronie zespołu.

Review obejmuje cały branch

Zmianę przygotowaną przez agenta analizujemy jako jeden zestaw, od wspólnej bazy do końca brancha. Sam podgląd ostatniego commita może nie pokazać, że wcześniejsza decyzja została później częściowo cofnięta, test osłabiono, a konfigurację dodano bez bezpiecznej wartości domyślnej.

Nasz proces obejmuje:

1. ustalenie pełnego zakresu zmiany względem wspólnej bazy brancha;
2. odczytanie historii commitów i intencji zadania;
3. przejrzenie każdego zmienionego pliku w jego szerszym kontekście, nie tylko w obrębie diffu;
4. sprawdzenie poprawności, przypadków brzegowych, bezpieczeństwa i obsługi błędów;
5. wykrycie brakujących testów, migracji, wartości domyślnych lub monitoringu;
6. ocenę ryzyka każdego obszaru i zapisanie konkretnych punktów do ręcznej weryfikacji.

Mały i czytelny zakres jest częścią zapewnienia jakości. Jeżeli branch jest zbyt duży, aby rzetelnie go zrozumieć, dzielimy zmianę zamiast akceptować review, które istnieje tylko formalnie.

Repozytorium, osobny branch, pull request i podgląd przed publikacją tworzą również podstawę pracy naszych agentów wykonujących zadania obejmujące wiele narzędzi. Praktyczny przykład tego przepływu pokazujemy w artykule Od polecenia do podglądu: jak agent AI aktualizuje stronę.

Cztery poziomy kontroli zamiast jednej ciężkiej procedury

Klasyfikujemy zmianę według konsekwencji błędu, a nie rozszerzenia pliku czy użytej technologii. Kod pomocniczy zasilający obszar wysokiego ryzyka dziedziczy jego poziom. Jeżeli jeden plik dotyka kilku poziomów, przyjmujemy najsurowszy.

Taki podział tworzy szybką ścieżkę dla zmian odwracalnych i ostrożniejszą ścieżkę dla operacji, których skutki mogą pozostać po wdrożeniu poprawki. Nie tracimy wydajności AI na rutynowych zmianach, ale nie przenosimy tej samej swobody na obszary danych, dostępu czy pieniędzy.

Automatyczne bramki są podstawą, nie substytutem review

Każda zmiana przechodzi dostępne kontrole projektu: build, typy, lint, testy, skanowanie bezpieczeństwa i sprawdzenie zależności. Są szybkie, powtarzalne i odporne na przekonujący styl wygenerowanego kodu.

W ważnych obszarach dokładamy scenariusze pochodzące spoza rozumowania agenta, który napisał implementację. Ten sam agent może zbudować kod i testy wokół jednego błędnego założenia. Oczekiwane zachowanie weryfikujemy więc na podstawie procesu biznesowego, reprezentatywnych danych i znanych wyjątków.

Korzystamy również z agentów w roli dodatkowych reviewerów. Osobny przebieg może szybko przejrzeć cały branch, wykryć sprzeczności i przygotować listę elementów do ręcznej kontroli. AI review nie zastępuje wiedzy domenowej, ale zwiększa pokrycie i pozwala ekspertowi skupić się na decyzjach, których nie można sprowadzić do automatycznej reguły.

Wynik review ma prowadzić do decyzji

Nie wystarcza nam ogólna ocena, że kod „wygląda dobrze”. Wynik review rozdzielamy na dwie części.

Pierwsza to znalezione problemy: lokalizacja w kodzie, opis błędu i konkretny scenariusz, w którym wystąpi. Dzięki temu zespół odróżnia rzeczywistą wadę od stylistycznej preferencji recenzenta.

Druga to elementy wymagające weryfikacji człowieka. Trafiają tu wszystkie obszary wysokiego ryzyka, również wtedy, gdy automatyczny reviewer nie znalazł błędu. Każdy punkt wskazuje:

• plik, fragment albo commit;
• powód ryzyka i możliwy nieodwracalny skutek;
• jedno konkretne sprawdzenie do wykonania.

Może to być uruchomienie migracji na kopii danych produkcyjnych i porównanie liczby rekordów, niezależne przeliczenie faktury albo potwierdzenie, że użytkownik z innej organizacji nie może odczytać danych. Review kończy się jasną decyzją: zmiana jest gotowa, gotowa po wskazanych kontrolach albo wymaga poprawek.

Człowiek pozostaje właścicielem rezultatu

Osoba zatwierdzająca zmianę nie przenosi odpowiedzialności na model ani dostawcę narzędzia. Obszary wysokiego ryzyka ocenia reviewer znający domenę, a agent nie ma samodzielnej drogi do produkcji.

To podejście jest spójne z zasadą kontrolowanej autonomii. Agent może przygotować zmianę, uruchomić kontrole i opisać ryzyko, ale decyzja o nieodwracalnym działaniu pozostaje po stronie człowieka. Szerzej opisujemy ten model w artykule Ile autonomii powinien dostać agent AI?.

Więcej kodu nie jest naszym celem

Celem wykorzystania AI w Inero nie jest maksymalizacja liczby commitów ani zastępowanie inżynierskiego osądu. Chcemy szybciej przechodzić od dobrze zdefiniowanego problemu do działającego, utrzymywalnego rozwiązania.

Dlatego mierzymy wartość agentów nie tylko czasem generowania kodu. Liczą się także czytelność zmiany, poprawność względem procesu biznesowego, możliwość testowania, bezpieczeństwo wdrożenia i koszt dalszego utrzymania.

Nasza zasada jest prosta: reviewujemy według skutków błędu, nie według autora kodu. W ten sposób AI staje się elementem wydajnego procesu inżynierskiego, a nie źródłem szybko rosnącego długu ukrytego pod warstwą poprawnie wyglądającego kodu.