Weryfikacja kodu generowanego przez agentów wymaga niezależnych kryteriów
Agent może zmienić całe repozytorium, dopisać testy i zakończyć pracę zielonym buildem. Taki wynik potwierdza jedynie, że implementacja spełnia kryteria zakodowane w aktualnym potoku CI. Nie potwierdza, że agent wykonał pełną migrację, usunął starą zależność ani poprawił czas wykonania poza scenariuszami testowymi.
Proces akceptacji powinien więc sprawdzać oddzielnie kompletność zmiany, zgodność zachowania, własności niefunkcjonalne oraz metryki z wdrożenia. Kryteria muszą być definiowane niezależnie od modelu, który wygenerował implementację.
Testy regresyjne nie potwierdzają wykonania migracji
W badaniu migracji obejmujących całe repozytoria przygotowano 20 zadań związanych z czterema rodzajami długu technicznego. Każde rozwiązanie przechodziło audyt potwierdzający wykonanie migracji, stałe testy zachowania oraz dodatkowe testy generowane przez sześć niezależnych agentów.
Spośród 520 uruchomień wszystkie trzy warstwy przeszło tylko 28, czyli 5,4%. W trzynastu zadaniach nie zaakceptowano żadnego rozwiązania. Część implementacji zachowywała oczekiwane działanie przez skopiowanie starego kodu albo ominięcie warstwy objętej migracją. Testy regresyjne przechodziły, mimo że wymagana zmiana architektoniczna nie została wykonana.
Specyfikacja migracji powinna rozdzielać dwa zestawy kryteriów:
- kryteria zachowania określają wyniki operacji i kontrakty, które muszą pozostać bez zmian;
- kryteria strukturalne określają zależności, moduły, ścieżki wywołań albo wzorce, które mają zostać usunięte lub zastąpione.
Drugą grupę można egzekwować przez reguły analizy statycznej, testy architektury, kontrolę grafu zależności lub sprawdzenie nieobecności zakazanych symboli. Ocena nie powinna zależeć od opisu zmiany wygenerowanego przez agenta.
Weryfikator oparty na tym samym LLM może powielać błędy implementacji
Model przeglądający kod wygenerowany przez podobny model może zastosować te same błędne założenia. Forge rozdziela te role: LLM generuje kod w Javie, a kod jest przekształcany do reprezentacji sprawdzanych przez Dafny, FDR4 i Isabelle. Komunikaty z tych narzędzi wracają do modelu jako dane wejściowe do kolejnej poprawki.
W tym układzie o akceptacji decydują własności sprawdzane przez deterministyczne narzędzia, a nie ocena wygenerowana przez LLM. Ograniczeniem pozostają transformacje pomiędzy kodem a modelami formalnymi. Błąd transformacji może dać poprawny dowód dla reprezentacji, która nie odpowiada rzeczywistemu programowi, dlatego te transformacje również wymagają testów i kontroli wersji.
GitHub zastosował inny niezależny mechanizm przy sprawdzaniu niedeterministycznego zachowania agentów. System buduje graf poprawnych wykonań i wyznacza stany, przez które musi przejść każda akceptowalna ścieżka. Dzięki temu może dopuścić różne sekwencje działań, zachowując wymagania dotyczące stanu końcowego.
W opisanym eksperymencie kontrola oparta na grafie osiągnęła 100% trafności wobec 82,2% dla samooceny agenta. GitHub nie podał pełnego rozmiaru zbioru, więc wynik nie pozwala ocenić uogólnienia metody. Mechanizm pokazuje jednak, jak oddzielić zmienną ścieżkę wykonania od obowiązkowych efektów operacji.
Pomiary wydajności JVM wymagają kontroli środowiska i kryterium statystycznego
JETO-Bench powstał na podstawie analizy niemal 1,8 mln commitów ze 174 projektów Java. Z 660 kandydatów autorzy uzyskali 91 ręcznie zweryfikowanych i wykonywalnych przypadków poprawek czasu wykonania. OpenHands z GPT-5-mini rozwiązał 13 z nich, czyli 14,3%.
W badanych projektach zwykle brakowało testów, które wiarygodnie wykazywały poprawę czasu wykonania. Sam fakt ukończenia benchmarku nie określa, czy różnica wynika ze zmiany kodu, kompilacji JIT, pracy GC, rozgrzewki procesu czy zmienności maszyny wykonawczej.
Brama akceptująca optymalizację powinna definiować liczbę rozgrzewek i iteracji pomiarowych, kontrolować konfigurację JVM i zasoby hosta, stosować kryterium statystyczne oraz uruchamiać oddzielne testy poprawności funkcjonalnej. Bez tych warunków agent może zoptymalizować pojedynczy pomiar zamiast stabilnej charakterystyki programu.
Nierównomierny ruch między usługami tworzy hotspoty niewidoczne w średnich metrykach
Netflix opisał system budowania topologii usług, w którym węzły obsługujące popularne usługi otrzymywały nawet sto razy więcej rekordów przepływu niż pozostałe. Rosła liczba alokacji, GC zużywał coraz więcej CPU, a awaria przeciążonego węzła przenosiła dodatkowy ruch na kolejne instancje.
System zmieniono przez dodanie lokalnej agregacji, ponowne partycjonowanie danych i ograniczenie alokacji na często wykonywanej ścieżce. Według Netflixa alokacja sterty spadła o ponad 50%, a pauzy GC skróciły się z setek do dziesiątek milisekund.
Testy repozytorium nie odtwarzają rzeczywistej popularności kluczy, korelacji awarii ani zmian natężenia ruchu. Akceptacja zmian wpływających na przepływ danych powinna więc obejmować metryki obciążenia poszczególnych partycji, alokacji, czasu GC i opóźnień ogonowych. Wdrożenie etapowe musi mieć zdefiniowane progi zatrzymania oraz wycofania zmiany.
Potok akceptacji powinien sprawdzać cztery własności zmiany
Dla kodu generowanego przez agentów potrzebne są oddzielne bramki:
- Kompletność zmiany — analiza strukturalna potwierdza usunięcie lub zastąpienie wskazanych zależności i ścieżek.
- Zgodność zachowania — testy regresyjne, kontraktowe i integracyjne sprawdzają wymagane wyniki operacji.
- Własności niefunkcjonalne — kontrolowane pomiary weryfikują limity czasu wykonania, alokacji, zużycia pamięci i opóźnień.
- Zachowanie po wdrożeniu — telemetria z wdrożenia etapowego sprawdza założenia dotyczące ruchu, partycji i awarii.
Model może generować implementację oraz propozycje testów, ale nie powinien samodzielnie definiować wszystkich czterech kryteriów akceptacji. W przeciwnym razie ten sam błąd założenia może znaleźć się jednocześnie w kodzie, testach i ocenie wyniku.
Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.