GitLab 19.2 wysyła agenty tam, gdzie zrobiło się wąskie gardło: do przeglądu i bezpieczeństwa

Agenty do pisania kodu zadziałały aż za dobrze. Manav Khurana, szef produktu i marketingu w GitLabie, mówi w komunikacie o wydaniu 19.2 z 16 lipca coś, czego od dostawcy narzędzi nie słyszy się często: "Agenty kodujące pozwoliły wygenerować znacznie więcej kodu i przesunęły wąskie gardło w dół, na przegląd i bezpieczeństwo". Innymi słowy, kod przestał być tym, czego brakuje. Brakuje rąk do jego sprawdzenia. GitLab 19.2 odpowiada na to w sposób, który brzmi zarazem logicznie i niepokojąco: skoro agenty wygenerowały zator, do jego rozładowania firma wysyła kolejne agenty. Diagnoza jest trafna. Pytanie, które zostaje otwarte, brzmi tak: czy człowiek zatwierdzający to, co trafia na produkcję, jest tu realną kontrolą, czy pieczątką w kształcie wąskiego gardła.

Najkonkretniej widać to na funkcji Dependency Scanning Auto-Remediation, na razie w becie publicznej. Kiedy skan wykryje podatną paczkę wśród zależności, GitLab sam otwiera merge requesta z gotową poprawką. Jeśli podniesienie wersji psuje kompilację, agent iteruje i poprawia dalej w tym samym merge requeście, aż uszkodzenie zniknie. To jest dokładnie ta robota, której nikt nie lubi. Według przywołanego w komunikacie badania ekosystemu Mavena podatność wciągnięta przez zależność przechodnią, czyli taką, której nikt świadomie nie dodał, dociera do mniej więcej 63% najnowszych wydań, a mniej więcej co ósma aktualizacja zależności wprowadza zmianę niekompatybilną wstecz. Ktoś to musi przeklikać ręcznie, zwykle pod presją terminów zgodności w rodzaju PCI DSS. Tu ten ktoś dostaje gotowca do zatwierdzenia, a każda zmiana i tak zatrzymuje się na istniejących bramkach akceptacji i zostawia pełny zapis w dzienniku.

Druga funkcja, Security Review Flow, również w becie publicznej, celuje w to, czego klasyczne skanery zrobić nie potrafią. Skaner oparty na wzorcach wychwyci lukę, która pasuje do znanego szablonu, ale jest ślepy na błędy w samej logice aplikacji: zepsutą autoryzację, przez którą użytkownik sięga po cudze dane, brak sprawdzenia uprawnień przy operacji zmieniającej stan, czy race condition, gdy o wynik walczą dwie równoległe operacje. GitLab twierdzi, że nowy przepływ rozumuje o tym, co kod ma robić, zamiast tylko dopasowywać wzorce, i przy każdym merge requeście podpowiada, co jest nie tak i jak to naprawić. Sam niczego nie akceptuje. Ostatnie słowo zawsze należy do człowieka, co GitLab powtarza przy każdej z tych funkcji jak mantrę.