Jak AI sprawdza nasz kod przed człowiekiem

Gdy kod pisze AI, wąskim gardłem przestaje być pisanie. Staje się nim czytanie. Pull request z kilkuset liniami powstaje w kwadrans, a jego uważne przejrzenie zajmuje człowiekowi godzinę. Przy kilkunastu takich zmianach dziennie nikt by za tym nie nadążył.

Postawiliśmy więc prostą zasadę: człowiek nie musi czytać każdej linii. Ma oceniać decyzje - jak ułożone są dane, gdzie trzyma się stan, jak zachowuje się interfejs. Nazwy zmiennych i podział na pliki, których nie opisuje żaden standard, nie są warte jego czasu. Resztę sprawdza AI pre-check.

Jak to działa

Pre-check to wspólny workflow GitHub Actions w publicznym repozytorium gi-org-pl/frontend-workflows. Korzystają z niego dziś aplikacja myPolitics i nasza biblioteka komponentów Athena. Przejdź przez kolejne kroki:

Najważniejsze są dwie rzeczy. Po pierwsze, recenzent pracuje w izolacji: może tylko czytać pliki (narzędzia Read, Glob i Grep). Nie ma powłoki, nie edytuje, nie wychodzi do internetu, niczego nie wypycha. Po drugie, o wyniku nie decyduje model. Decyduje kod: to reguły w pliku contracts.py mówią, kiedy zmiana zawsze wymaga człowieka - na przykład gdy dotyka CI, zależności albo konfiguracji builda.

Jak to wygląda w praktyce

Tak wygląda prawdziwy komentarz pre-checku pod jednym z naszych pull requestów:

Fragment komentarza pre-checku pod pull requestem #239 w repozytorium mypolitics-app.

Recenzent oznaczył zmianę jako wymagającą poprawek: dotyka CI, a nie wskazuje zadania, które by o nią prosiło. Wypisał też cztery decyzje warte uwagi i cztery kroki do ręcznego sprawdzenia. Człowiek przeczytał, ocenił i zmianę scalił. Stopka komentarza mówi to wprost: „advisory, not an approval” - to podpowiedź, nie zgoda.

Cztery wydania w trzy dni

Pierwsza wersja pre-checku powstała jako pull request w repozytorium naszych standardów. Przeszła trzy przeglądy bezpieczeństwa i jeden przegląd struktury, a potem przenieśliśmy ją do osobnego repozytorium razem z historią: 32 commitami, z których każdy tłumaczy jakąś poprawkę.

• v1.0.0 (21.10) - pierwsze wydanie, 68 testów jednostkowych i 24 testy skryptów.

• v1.1.0 (21.10) - po pierwszym prawdziwym użyciu na 19 pull requestach aż 16 skończyło się wynikiem „potrzebny człowiek”. Nie przez kod, tylko przez kontekst: za dużo powiązanych zadań, brakujące dokumenty. Rozdzieliliśmy te dwie sytuacje. Brak części kontekstu daje teraz wynik „advisory”, a nie blokadę. 99 testów.

• v2.0.0 (22.10) - nowy, zwięzły komentarz: nagłówek z wynikiem, jedno zdanie podsumowania, tabela znalezisk, najwyżej pięć decyzji i pięć kroków do QA. Typowy komentarz mieści się w 3 000 znaków przed rozwinięciem szczegółów. Wynik „potrzebny człowiek” przestał być czerwony tam, gdzie gałąź i tak wymaga zatwierdzenia bieżącego commita przez człowieka. 119 testów.

• v2.1.0 (23.10) - zatwierdzenie bieżącego commita przez osobę z prawem zapisu (nie autora i nie bota) zmienia check na zielony. Po recenzji wynik przelicza się bez ponownego uruchamiania modelu.

Co poszło nie tak

Za dużo alarmów. Narzędzie, które w 16 przypadkach na 19 woła człowieka, niczego nie oszczędza. Wersja 1.1 rozdzieliła braki w samej zmianie od braków w jej otoczeniu.

Za długie komentarze. Pełna lista wszystkiego, co model sprawdził, była rzetelna i zupełnie nieczytelna. Teraz najważniejsze jest na górze, a szczegóły czekają pod rozwijanymi sekcjami.

Kolor wzięty za numer zadania. W opisie jednej zmiany pojawił się kolor #004554. Pre-check uznał go za odnośnik do zadania 4554, nie mógł go otworzyć i zawołał człowieka. Od wersji 2.0 kolory, kod i liczby z zerem na początku nie są brane za odnośniki.

Zatwierdzony, a wciąż czerwony. W pull requestach ułożonych jeden na drugim gałąź bazowa nie miała reguły wymagającej zatwierdzenia. Zatwierdzona zmiana dalej świeciła na czerwono. Wersja 2.1 sprawdza więc samo zatwierdzenie, a nie tylko reguły gałęzi.

Czego się nauczyliśmy

• Model podpowiada, reguły rozstrzygają. Wszystko, co decyduje o wyniku, jest w kodzie i ma testy.

• Bezpieczeństwo od pierwszego dnia: tekst modelu trafia do komentarza jako zwykły tekst, linki składa wyłącznie skrypt, a wynik przechodzi skan pod kątem danych uwierzytelniających.

• Narzędzie jest dobre dopiero wtedy, gdy ludzie chcą czytać to, co pisze. Krótszy komentarz zmienił więcej niż kolejne reguły.

Na dziś etykietę pre-checku ma 34 pull requesty w mypolitics-app i Athenie. Cały kod, instrukcje recenzenta i opis procesu są publiczne w repozytorium gi-org-pl/frontend-workflows.