Jak nadążamy z review PR-ów w erze AI?

1. Ogranicz każdy PR do jednej rzeczy

Najszybszy sposób, żeby zabić impet review, to PR, który robi trzy rzeczy naraz. Reviewerzy nie powinni musieć w głowie rozplątywać, które zmiany należą do poprawki błędu, a które do refaktoru, który po cichu dorzuciłeś.

• Jedna poprawka błędu, jedno pole, jedna funkcja — nie wszystkie trzy w tym samym PR-ze.

• Skupiony PR na ~1 000 linii, który rozwiązuje jeden jasny problem, jest w porządku. PR na 300 linii z trzema kwestiami już nie. Jeśli dawno przebiłeś 1 000 linii, to mocny sygnał, żeby to rozdzielić.

• Przy większych zmianach używaj stacked PR-ów.

• Zanim otworzysz: czy ktoś może to zreviewować za jednym posiedzeniem? Czy robi dokładnie jedną rzecz? Czy sam byś to zmerge’ował?

2. Nie proś o review, dopóki to naprawdę nie jest gotowe

Drafy są po coś. Wyjęcie PR-a z draftu to sygnał dla zespołu, że zrobiłeś swoją pracę i to jest warte czyjegoś czasu. Jeśli ten sygnał jest niewiarygodny, cały system review się rozpada.

Wycofaj draft tylko jeśli możesz odpowiedzieć „tak” na wszystko:

• Zrobiłeś self-review

• Wszystkie testy przechodzą, w tym e2e

• Zero nierozwiązanych komentarzy (w tym Devinowych)

• Przetestowałeś to lokalnie przy zmianach UI/UX

• W przypadku zmian, które da się pokryć automatycznymi testami, potwierdziłeś, że są w 100% pokryte

• Wszystkie joby CI są zielone (poza upierdliwymi podglądami Vercel)

Jeśli choć jedna odpowiedź brzmi „nie”, zostaw to jako draft. Drafty proszące o review zaśmiecają kolejkę i opóźniają PR-y, które naprawdę są gotowe.

3. Ogranicz liczbę otwartych PR-ów do 5 (drafty też się liczą)

Otwarte PR-y to zapas. Niosą koszt przełączania kontekstu, ryzyko konfliktów przy merge’u i dług review. Jeśli masz ich jednocześnie więcej niż pięć, matematyka się nie zgadza. Produkujesz szybciej, niż zespół jest w stanie to wchłonąć.

Jeśli masz 5 otwartych PR-ów łącznie, drafty i niedrafty razem, nie zaczynaj nic nowego. Zamiast tego zreviewuj PR-y swoich teammate’ów albo dokończ starszą pracę.

4. Dodaj ludzki głos do opisu PR-a

Opis nie musi być w pełni napisany przez Ciebie. AI jest OK do szkicu i podsumowania diffu. Problemem z tym, co widzimy teraz, są masywne opisy wygenerowane przez AI, które czytają się jak generyczna checklista, z którą nikt się nie zmierzył. Brakuje w nich ludzkiego elementu, którego reviewer naprawdę potrzebuje.

• Jednozdaniowa notatka autora o kompromisie, który wybrałeś, albo o tym, dlaczego ta poprawka ma znaczenie teraz, daje więcej niż długi blok „Key Review Points” / „Human Review Checklist”.

• Jeśli wysyłasz kod, który jeszcze nigdzie nie jest używany, napisz dlaczego.

• Jeśli AI napisała opis, skróć go i dodaj tylko ten kontekst, który znasz Ty.

5. Udowodnij, że poprawka działa

PR, który mówi „naprawia błąd X” bez dowodu, prosi reviewera o wiarę na słowo. Nie zmuszaj go do tego.

• Zrzuty ekranu, nagrania ekranu, dashboardy przed/po — cokolwiek, co pokazuje, że błąd nie żyje i nic innego się nie zepsuło.

• Funkcjonalne QA jest obowiązkowe przy zmianach UX/UI, a nie opcjonalne.

6. Zmiany SQL i wydajności wymagają prawdziwej walidacji

Samo code review nie potwierdzi, że przepisane zapytanie wytrzyma obciążenie produkcyjne. Przeczytanie diffu zapytania i powiedzenie „wygląda dobrze” nie jest walidacją. Dla PR-ów dotykających ścieżek zapytań albo ich przepisywania:

• EXPLAIN ANALYZE na zbiorze danych podobnym do produkcyjnego

• Pomiary opóźnienia przed/po albo zrzuty ekranu z dashboardu

• Wdrażanie z feature flagą dla ryzykownych zmian

7. AI to przyspieszacz, nie mózg

AI potrafi szybko generować kod. Nie potrafi zdecydować, czy ten kod powinien istnieć. Myślenie nadal musi wyjść od Ciebie.

• Najpierw projekt. Naszkicuj podejście, przemyśl edge case’y, napisz krótką notatkę, a potem daj prompt.

• Po wygenerowaniu przez agenta naprawdę to przeczytaj. Self-review wyłapuje wywołania Prisma w złym miejscu, zignorowane wytyczne agenta, kruchą strukturę itd.

• Przed otwarciem zapytaj: czego to dotyka? Jaki ma wpływ na użytkownika? Jakie są konsekwencje dla wydajności albo bezpieczeństwa? Jak duży będzie obszar rażenia, jeśli to jest błędne?

8. Zweryfikuj PR-y bezpieczeństwa, zanim je otworzysz

Potwierdź, że podatność naprawdę dotyczy tego, jak używamy tego kodu. PR-y typu „fix vulnerability X”, które dotykają wrażliwych ścieżek, mogą wprowadzić większe ryzyko niż sam oryginalny raport.

9. Kieruj PR-y do właściwego reviewera

Zły reviewer marnuje czas dwóch osób: reviewera, który nie może dać sensownego feedbacku, i autora, który musi czekać na drugą rundę z właściwą osobą.

• PR-y mocno domenowe (routing Salesforce/CRM, migracje profili zespołów itd.) należą do właściciela domeny, a nie do Foundation, który tylko odhacza test suite wygenerowany przez AI.

• Zmiany w kluczowych ścieżkach foundation (query infra, hasTeamAccess itd.) zasługują na szybkie uzgodnienie z właścicielskim zespołem, zanim PR zostanie otwarty.

10. Rozmowy o architekturze dzieją się wcześnie

Łatanie tego samego obszaru trzy razy to sygnał, a nie przypadek. Jeśli znowu obchodzisz to samo ograniczenie, właściwy ruch to rozmowa i potencjalny rewrite, a nie kolejna łatka.

Porozmawiaj z Foundation / Head of Engineering, zanim zaczniesz implementację. Tak właśnie powstały moduły infra, a spójność się kumuluje.

11. Lżejsza ścieżka dla drobnych poprawek

Nie wszystko wymaga review Foundation. Powinniśmy wydawać bandwidth review tam, gdzie ma to największe znaczenie.

Poprawki toastów, rozmiaru przycisków, mechaniczne zmiany nazw, zmiany copy, funkcje głównej linii - to może przejść przez review AI i/lub review na poziomie zespołu. Zostaw review Foundation dla zmian, które naprawdę go potrzebują.

12. Nie otwieraj PR-ów w imieniu innych

Jeśli inżynier X wykonuje pracę, to inżynier X otwiera PR. Inaczej komentarze trafiają do złej osoby, pytania zostają bez odpowiedzi, a PR staje w miejscu.